Ciao, sono stato a Pavia e ho notato dei problemi. Mi piacerebbe sistemare qualcosa ma prima vorrei dei feedback.
Tutti gli edifici della città sono stati importati 11 anni fa. I problemi che ho notato sono:
Le building:part=* sono mappate come building=*. Per esempio tutti i portici e building_passage sono mappati come edifici a parte. In ogni caso tutte le parti correlate hanno lo stesso it:pv:pavia:ID_EDIF quindi sono facilmente correggibili. Io eliminerei tutti questi tag con una sola occorrenza (che significa che sono già mappati correttamente) e terrei quelli con piu’ occorrenze fino a quando man mano non vengono corretti in un solo edificio (come sono nella realtà).
I valori di height=* sono stati copiati dai valori di it:pv:pavia:UN_VOL_AV=*. Questo però è vero solo quando it:pv:pavia:DELTA_Z (che sarebbe min_height=*) equivale a zero.
Per esempio un porticato con it:pv:pavia:DELTA_Z=4 + it:pv:pavia:UN_VOL_AV=12.3 è attualmente taggato come height=12.3, in realtà dovrebbe essere taggato come min_height=4 + height=16.3. Questo si potrebbe correggere automaticamente, e i tag dell’import eliminati (in quanto sarebbero la stessa informazione duplicata). Qualcuno è contrario?
I valori di start_date=* sono stati copiati dai valori di it:pv:pavia:ANNO_SOGLI. Di questo non sono sicuro, ma ho dei grossi dubbi che quella stringa identifichi effettivamente l’anno di costruzione o apertura, anche perché vorrebbe dire che un terzo degli edifici di Pavia è stato costruito tutto nel 1880. Ho preso una chiesa a caso mappata come start_date=1880 e Wikipedia dice che la facciata risale al XV secolo, quindi qualcosa non torna: Chiesa di San Giovanni Domnarum
Stessa cosa per la Torre degli Aquila, che risale all’XI-XII secolo.
Qualcuno sa cosa potrebbe identificare it:pv:pavia:ANNO_SOGLI? Se assodiamo che non è la start_date=* io procederei con un’eliminazione del tag da ogni elemento in cui il valore di start_date=* corrisponde al valore di it:pv:pavia:ANNO_SOGLI.
Qualcuno magari riesce a capire se qualcuno di questi valori ha un tag equivalente su OSM così da convertirli e quali possono essere cancellati senza problemi?
A giudicare dagli attributi, l’import è stato fatto da un db topografico.
Le specifiche di contenuto della Regione Lombardia del database, sostanzialmente conformi a quelle nazionali, sono qua [1], utili per ricostruire il reale significato degli attributi e porli eventualmente in relazione con i tag di OSM
fondere le due way in una con tag building , oppure
estendere la seconda al perimetro che comprende anche il portico e lasciare la prima come building:part ?
Io propenderei per 1. perchè il passaggio sottostante potrebbe essere mappato con gli opportuni tag per dire che è al coperto.
A riguardo della cancellazione non saprei: non vedo un’utilità diretta del tag, non mi risulta sia usato dagli enti locali così come avviene con il grafo strade di Milano, ma certezze non ne ho. Se lo riciclassimo in un tag ref tipo loc_ref, ref:IT:PV… ?
Sono d’accordo con la correzione che proponi
Facendo un po’ di statistica si trova che in it:pv:pavia:ANNO_SOGLI il 99% dei valori ricade su 7 distinti anni (1880,1975,1963,1935,1986,1913,2010). Ipotizzo che rappresenti l’anno in cui sicuramente quell’edificio era presente a catasto. Il dato quindi non è affatto preciso, ma probabilmente difficilmente ricostruibile in altro modo. Dove il tag ha un valore uguale a start_date proporrei:
per il valore 1880 start_date=before 1880 (soprassederei sul fatto che alcuni edifici possano essere stati costruiti esattamente nel 1880… se piace di più si può usare il valore before 1881)
per i rimanenti un range che abbia come valore massimo quello presente nel tag e valore minimo l’anno immediatamente precedente fra i possibili valori. Ad esempio nel caso di 1986 start_date=1975..1986. Il valore INDT non è usabile. I pochi altri sono da valutare
Alla fine del processo toglierei il tag.
facendo riferimento anche alle specifiche DBT linkate da @skampus
it:pv:pavia:FEATURE_ID tranne pochi casi è un valore univoco. Lo toglierei perchè penso che sia più significativo it:pv:pavia:ID_EDIF
it:pv:pavia:ID_ZRIL nel 99%+ dei casi ha un unico valore. Lo butterei
it:pv:pavia:STRATO, it:pv:pavia:CLASSE, it:pv:pavia:TEMA di fatto identificano il tipo di dato “edificio” nello schema del DBT. Li cancellerei
it:pv:pavia:UN_VOL_POR: questo sembra un dato interessante perchè da informazioni sul building. A parte il valore 301=“al suolo” troviamo 303=“soffitto di portico”, 302=“soffitto di sottopassaggio”, 305=“soffitto di loggia” e 308=“sotterranea”. Per me sono valori importanti per valutare se adattare opportunamente i tag dell’edificio. Posso farmi carico di quest’analisi
it:pv:pavia:SHAPE_Area, it:pv:pavia:SHAPE_Leng: dati calcolabili. Toglierei
it:pv:pavia:EDIFC_TY, it:pv:pavia:EDIFC_STAT, it:pv:pavia:EDIFC_USO: in base alle specifiche danno informazioni sul tipo e sulla destinazione d’uso, elementi che potrebbero aiutare a definire meglio il valore di building ad esempio. Mi ripropongo di analizzare i valori
it:pv:pavia:SHAPE_STAr, it:pv:pavia:SHAPE_STLe: 18 edifici con questi tag. A naso sembra che siano presenti quando mancano i tag it:pv:pavia:SHAPE_Area e it:pv:pavia:SHAPE_Leng. Toglierei
it:pv:pavia:ID_PATRIED: presente in 10 edifici. Il valore è di scarsa utilità. Toglierei
Nessuna delle due opzioni che hai proposto. Ho trasformato entrambe le parti in building:part e creato un nuovo edificio che le comprende entrambe come da specifiche di Simple 3D Buildings. Se si fonde tutto si perde dettaglio secondo me, se invece di estende solo una delle building:part si ottiene un buco, cito da Simple 3D Buildings:
The entire building outline should be filled with building:part=* areas
In pratica quello che faccio è:
trasformare tutto in building:part
creare un building che comprenda tutte le parti e dargli come height l’altezza della building:part piu’ alta (sempre come da specifiche Simple 3D Buildings)
spostare e poi cancellare al building principale TUTTI i tag che sono comuni a tutte le parti, lasciandogli solo quelli che sono univoci o comunque diversi.
Cancellare it:pv:pavia:DELTA_Z, it:pv:pavia:UN_VOL_AV una volta sistemata l’altezza delle singole parti come scritto qua:
in realtà dovrebbe essere taggato come min_height=4 + height=16.3
Eliminare it:pv:pavia:ID_EDIF, che mi è utile per capire quali edifici sono stand-alone (nel database c’è un solo risultato per quel value) e quali sono composti da piu’ parti (piu’ occorrenze per lo stesso value). Quindi se sono stand-alone lo cancello subito, se sono composti lo cancello dopo aver fatto questa procedura.
Non conosco come funziona il catasto, c’è la certezza assoluta che se un edificio è stato accatastato dopo il 1880 non potesse già esistere prima? Se sì sono d’accordo, anche se riempire di valori imprecisi un tag mi mette sempre la paura che qualcuno appassionato del tema un giorno faccia una ricerca di tutti gli edifici SENZA start_date=* e li ignori ignori quindi completamente. Però come ripeto sono d’accordo.
Come comportarci però nel caso di it:pv:pavia:EDIFC_STAT=0401 (che dovrebbe identificare gli edifici in costruzione da quello che ho capito)?
Grazie per l’analisi dei tag cancellabili. Li cancello senza remore quindi.
Andando sul SIT e selezionando il layer “Epoche storiche di costruzione” si nota che la legenda fornisce un’unico dato certo che collima con it:pv:pavia:ANNO_SOGLI ovvero quando questo ha il valore 1880
Si, sono quelli in costruzione o in ristrutturazione perchè ho trovato vecchie cascine marcate così e con data 1880. Diciamo che sarebbe comunque coerente con il significato del campo start_date, ma in linea generale it:pv:pavia:ANNO_SOGLI è effettivamente molto vago.
Ogni tanto mi metto ancora a sistemare i dati degli import di Pavia. Ora vorrei finalmente pulire il valore di it:pv:pavia:ANNO_SOGLI. Vorrei eliminare il tag completamente e sostituirlo con i seguenti valori di start_date=*:
Questo assumendo che it:pv:pavia:ANNO_SOGLI=2010 rappresenti tutti gli edifici accatastati entro il 31 dicembre 2010. Di questo non ho certezza quindi assumo che il tag it:pv:pavia:ANNO_SOGLI significhi “edificio accatastato durante il catasto del 2010”, che potrebbe essere anche stato effettuato a giugno (esempio). Quindi un edificio costruito ad ottobre 2010 apparirebbe nel catasto del 2013.
Ah ecco, pensavo fosse il “start_date” (data di fine costruzione / inizio utilizzo), ma se si tratta della data di accatastamento, significa che potrebbero essere molto più vecchi, giusto?
Si, motivo per cui hanno tutti come limite inferiore il catasto precedente, mentre per il primo catasto (1880) ho proposto “=before 1880” in quanto contiene dagli edifici medioevali fino agli edifici del 1879.
