Problemi Import Pavia

[IlBano]

Ciao e grazie per l’iniziativa.

@ivanbranco

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à).

Per capire meglio con un esempio. Prendiamo nella foto in basso a sinistra di questa immagine Pavia - Wikipedia l’edificio bianco al centro. Questo è rappresentato dalle way Way: 149305986 | OpenStreetMap per la parte di portico e Way: 149305985 | OpenStreetMap per l’edificio. La proposta è

1. fondere le due way in una con tag building , oppure
2. 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… ?

@ivanbranco

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?

Sono d’accordo con la correzione che proponi

@ivanbranco

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.

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.

@ivanbranco

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?

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