Buongiorno,
ho notato recentemente che (quantomeno in Veneto) la chiave building:part è usata in modo improprio.
Ad es. qui (Way: 373629775 | OpenStreetMap) vedete che è usato con building:part=roof + layer=1.
Nella pagina wiki del tag (Key:building:part - OpenStreetMap Wiki) è scritto:
“Note that building:part=* are optional areas used in addition to a building=* area. building:part=* areas should always be within a separate building=* area representing the entire building.” mentre nei casi evidenziati il tag è applicato in modo isolato.
Il tagging è dovuto a un vecchio import e personalmente credo dovrebbe essere corretto semplicemente in building=roof (tenendo buona questa classificazione) e inoltre togliendo layer=1, visto che in Tag:building=roof - OpenStreetMap Wiki è scritto solo che " If there are already other features below or above the roof on the map, layer should be used to provide information about stacking of features."
A parte ho analizzato quali building:part sono all’interno di way di tipo building=*, quindi si potrebbe forse fare anche un bulk edit. Cosa ne dite?
Non commento questo preciso caso in particolare, ma conoscendo il 3d schema posso dire che =roof é uno dei valori di building:part che fa eccezione alla regola secondo cui le parti devono essere comprese all’interno dell’outline. In questi casi la parte che sporge deve essere aggiunta in una relazione type=building:
If at least one part of a building is hanging over the building footprint or if the building has a complex structure with lots of parts, a type=building relation can be used to group the building outline and all building parts together.
Quindi direi, se quella way é una parte di tetto dell’edificio principale che sporge dall’outline, lascerei building:part=*. Se invece é una tettoia separata e indipendente, si può cambiare in building.
Quindi personalmente eviterei bulk editing in quanto ogni caso andrebbe valutato a sé.
Grazie @ivanbranco per la precisazione.
Però nella pagina wiki non c’è nessuna eccezione esplicita per building:part=roof, da dove la desumeresti?
Solo per logica, essendo una delle poche parti insieme a building:part=balcony che può sporgere dall’outline di un edificio pur facendo parte dell’edificio stesso.
Ah ok, pensavo che ti riferissi a qualche altra sezione della wiki.
Se la motivazione del tuo ragionamento si basa su quella frase citata, presente qui, allora credo sia semplicemente un errore di interpretazione.
Quella frase dice che:
“Se almeno una parte di un edificio è sospesa oltre l’impronta dell’edificio o se l’edificio ha una struttura complessa con molte parti, è possibile utilizzare una relazione type=building per raggruppare la sagoma dell’edificio e tutte le parti dell’edificio. Altrimenti, non è necessario creare una relazione tipo=edificio, cioè è sufficiente posizionare tutte le parti dell’edificio all’interno della sagoma dell’edificio come descritto sopra.”
In sostanza dice: non create relazioni ogni volta che c’è una building:part da differenziare, ma potete farlo (e non è obbligatorio) solamente se ci sono elementi aggettanti o se la struttura è molto complessa.
Quindi si riferisce alla possibilità di fare anche relazioni, non al fatto che ci sia alcuna deroga dall’esigenza che tutte le parti dell’edificio (building:part) siano all’interno dell’intero edificio (building).
Estendo la risposta esplicitando dunque che la cosa migliore, in caso di tettoie e/o balconi, sarebbe creare almeno due way building:part ( una building:part=yes che identifica la struttura principale e la building:part=roof/balcony), disegnare il bordo di tutto l’edificio che include le parti con tag building=* e quindi creare una relazione di tipo type=building tra le parti che lo compongono.
Poiché non è obbligatorio creare la relazione, se si decide di disegnare le due parti separate ma si vuole semplificare, si può fare a meno della relazione ma bisogna cmq disegnare una way con building=* che include le due building:part.
Aggiungo che è chiaramente un comportamento dovuto a un import nella provincia di Padova e che questa modalità di tagging nel resto d’Italia è minimale e residua.
Avrei voluto vedere come si è arrivati a questo tagging.
Purtroppo la documentazione dell’import è un po’ sparsa e non si capisce bene cosa sia stato fatto, ma in nessuna di queste regole di traduzione compare bulding:part=roof:
https://wiki.openstreetmap.org/wiki/Veneto/File_delle_Regole_SHP-to-OSM
https://wiki.openstreetmap.org/wiki/Veneto/Guide_e_documentazione/Import:_dalla_CTRN_Veneto_a_OSM#File_delle_regole_in_formato_python
Hai provato a contattare l’autore?
Grazie Andrea, hai ragione provo a contattarlo. Come la vedi comunque? A me sembra chiaro che building:part=roof dovrebbe avere sempre un elemento building che lo include, quindi sarei per il cambiamento in building=roof. Per quanto riguarda il layer=1, in effetti non sono sicuro nemmeno io, forse val la pena lasciarlo in effetti.
Dalla documentazione che hai linkato sembra che il codice avrebbe dovuto usare building=roof per le tettoie
elif attrs['LIVCOD'] == '0104': #tettoia
tags['building'] = 'roof'
tags['layer'] = '1'
poi per qualche motivo è stato aggiunto part
Ora chiedo.
Sì, il roof è di layer=1 quando si trova sopra il terreno, mentre quando si trova sopra un edificio, il valore del layer aumenta. Diversi siti di QA li evidenziano quando si intersecano con altri elementi dell’edificio o con un edificio nell’edificio quando si trova all’interno della circonferenza. È meglio lasciare il valore/tag.
Se il building non è sopra a un altro elemento, è inutile e lo toglierei. Per il resto concordo con la tua analisi ma, per esserne sicuri, come dicevo, preferirei vedere i dati sorgente e le regole di traduzione applicate.
Probabilmente un bulk edit potrebbe incappare in tanti falsi positivi. Forse sarebbe meglio una task MapRoulette, in modo che possa essere fatta un po’ da chiunque e si può valutare meglio caso per caso.
Puoi fare un esempio di falso positivo che una query overpass non sia in grado di intercettare preventivamente?
Ad esempio se un edificio ha un tetto (building:part=roof) sopra una terrazza (e quindi magari l’edificio ha roof:levels=0 e roof:shape=flat) e viene intercettato quello è un falso positivo
Ma mi aspetto che in questo caso non ci sia layer=1, perche’ non si applica alle building:part:
Simple 3D Buildings - OpenStreetMap Wiki
Vero, ma aspettativa e realtà possono essere differenti. Trovo comunque che procedere alla cieca possa essere controproducente in alcuni casi.
Prima di dire di non fare un bulk import, mi piacerebbe avere dei controesempi (ovvero feature mappate) che con il bulk import sarebbero gestiti in modo errato.
Altrimenti stiamo escludendo a priori una cosa che invece potrebbe andare benissimo (oltre a far risparmiare un sacco di tempo).
I bulk edit in generale sono sempre problematici e in un caso come questo non parliamo di un semplice refuso nel tag. Se poi si vuole procedere comunque a me cambia poco, dico solo che potrebbero esserci delle modifiche che magari non vanno fatte.
Avevo già fatto alcuni test e mi pare che nell’area di interesse siano veramente tutti veri positivi 
Un’intersezione spaziale che selezioni i building:part=roof che sono all’interno di altre geometrie con qualche building=* potrebbero permettere di individuare eventuali elementi da escludere.
Per il resto, in questo caso, mi sembra proprio che un bulk edit aiuterebbe molto.