IT:Relation:multipolygon
multipolygon |
Descrizione |
---|
La relazione multipolygon si usa per rappresentare aree complesse. |
Gruppo: proprietà |
Membri |
|
Stato: de facto |
Strumenti |
|
Le relazioni di tipo multipolygon (multipoligono) sono usate per rappresentare aree complesse.
In OSM le aree semplici vengono mappate tramite un percorso chiuso etichettato con qualcosa che faccia pensare ad una superficie invece che ad una linea chiusa. Per esempio, un percorso circolare etichettato con landuse=forest
verrà interpretato come un'area, lo stesso percorso etichettato con junction=roundabout
invece no.
Tuttavia, questo schema funziona solamente per aree prive di buchi, e il cui contorno è costituito da un solo percorso. Qualsiasi area più complessa (per esempio perché il contorno è composto da più percorsi concatenati, o perché ha dei fori, o perché l'area è costituita da più parti disgiunte) richiede una relazione multipolygon.
Si raccomanda di usare type=multipolygon (e non type=boundary) anche per le relazioni che descrivono i confini, così che le applicazioni possano usare le regole per la costruzione delle aree (come la concatenazione di percorsi esterni per formare gli anelli, l'esclusione delle enclavi, ecc.). Una relazione che descrive i confini si riconosce facilmente dall'etichetta boundary=*, non è necessario usare type=boundary.
In sintesi, una relazione multipolygon può avere come membri un qualunque numero di percorsi con ruolo outer (il contorno esterno) e un qualunque numero di percorsi con ruolo inner (i buchi), purché formino degli anelli validi per la costruzione di un multipoligono.
Etichette
Chiave | Valore | Spiegazione |
---|---|---|
type | multipolygon | Istruisce le applicazioni affinché applichino ai membri le regole di costruzione delle aree. |
Non usare (sconsigliato). Usa invece type=boundary (si tratta di relazioni simili ma con in più membri non-way e ruoli specifici). | ||
natural | * | Almeno una etichetta che descrive il tipo di elemento (ad esempio un elementi naturali, di uso del suolo, relativi a edificio, costruiti dall'uomo, che forniscono beni o servizi, per il tempo libero, aree pedonali, etc.) che risiede in quell'area. La maggior parte di queste etichette sono mutualmente esclusive (nel caso, usa multipoligoni separati: la regola base è Una caratteristica fisica, un elemento su OSM, perché l'aggiunta di ulteriori etichette potrebbe portare a conflitti d'interpretazione. |
landuse | * | |
building | * | |
man_made | * | |
amenity | * | |
leisure | * | |
highway | pedestrian | |
waterway | * | |
… | … | |
layer | * | ulteriori etichette facoltative per le proprietà (ad esempio sotto-tipi, livelli, nomi, numeri di rifermento, note, etc.). Alcune di queste potrebbero essere interpretate differentemente in base al tipo di elemento indicato più sopra. |
name | * | |
ref | * | |
note | * | |
… | … |
Membri
Percorso o nodo | Ruolo | Quantità | Spiegazione |
---|---|---|---|
o | outer | uno o più | I percorsi che costituiscono l'anello esterno (o gli anelli esterni) dell'area. |
o | inner | zero o più | I percorsi che costituiscono l'anello interno (o gli anelli interni) dell'area. |
o | nessuno | zero | Nella maggioranza dei casi una relazione può venire interpretata correttamente anche senza specificare i ruoli inner e outer. Tuttavia si raccomanda di specificare i ruoli per aiutare gli altri mappatori a comprendere la relazione. |
qualsiasi | zero | Non usare. | |
qualsiasi | zero | Non usare. |
Modo d'uso
I multipoligoni andrebbero usati come segue:
- Le etichette che descrivono il multipoligono (ad esempio landuse=forest) devono essere applicate alla relazione. I percorsi che costituiscono il contorno esterno (o i contorni esterni) devono essere lasciati non etichettati, a meno che non descrivano di per se stessi qualche cosa. Per esempio, una foresta può essere delimitata da delle strade, ciascuna delle quali avrà pertanto la sua etichetta di tipo "highway", e nello stesso tempo sarà membro della relazione multipoligono della foresta con il ruolo "outer".
- Se il bordo esterno della superficie in questione è costituito da un solo percorso chiuso, ed esso non descrive di per se stesso qualche cosa, allora si potrebbe mettere le etichette descrittive su di esso invece che sulla relazione. Ma se il bordo esterno è composto da più percorsi (vedi gli esempi più sotto) questo non ha più senso. Pertanto si suggerisce (per coerenza) di mettere le etichette del multipoligono sempre sulla relazione.
- Se l'anello interno (membro della relazione con ruolo "inner") costituisce di per se stesso qualche cosa (ad esempio un lago contenuto in una foresta), allora l'anello interno può essere etichettato come tale.
- Altrimenti i percorsi degli anelli interni devono restare privi di etichette.
- La direzione dei percorsi è ininfluente.
- L'ordine dei membri nella relazione è ininfluente (tuttavia, liste i cui membri sono ordinati in maniera appropriata aiutano i redattori a verificarne la completezza).
- In generale, la relazione multipolygon può essere usata per costruire poligoni complessi in accordo con lo standard "OGC Simple Feature Standard". Tutto ciò che non è un multipoligono valido secondo tale standard (ad esempio poligoni con percorsi che si intersecano) dovrebbe essere considerato non valido anche nella relazione multipolygon. Fanno eccezione gli anelli interni che si toccano (vedi sotto).
Esempi
Un anello esterno e un anello interno
La vecchia versione di relazione multipolygon, molto usata, permetteva di avere un solo anello esterno e un numero qualunque di anelli interni. Inoltre, ogni anello doveva consistere di un singolo percorso chiuso. Questo tipo di poligono (non si tratta strettamente di un multipoligono, piuttosto di un poligono con più percorsi) è naturalmente ancora supportato, ma a causa dell'allentamento delle regole è diventato un caso particolare della più generica relazione multipolygon.
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> </relation> |
Un anello esterno e due anelli interni
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> <member type="way" id="3" role="inner" /> </relation> |
Anello formato da più percorsi
Lo schema dei multipoligoni avanzati permette che ogni anello interno o esterno sia costituito da più di un percorso. Questo è utile per i multipoligoni che coprono aree molto vaste, nel cui caso sarebbe poco pratico usare un solo percorso per il perimetro. Ha senso anche per i multipoligoni che descrivono aree il cui perimetro non può essere costruito con un solo percorso (ad esempio, i poligoni dei confini):
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="outer" /> <member type="way" id="3" role="inner" /> </relation> |
Due anelli esterni disgiunti
Diversamente dai multipoligoni vecchio stile, la relazione multipolygon permette un numero arbitrario di anelli esterni, così da poter rappresentare un vero multipoligono:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="outer" /> </relation> |
Anelli esterni disgiunti e un anello interno formato da più percorsi
Anche gli anelli interni possono essere costituiti da più percorsi:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> <member type="way" id="3" role="inner" /> <member type="way" id="4" role="outer" /> <member type="way" id="5" role="inner" /> </relation> |
Combinazione complessa di tutte le possibilità
Questo esempio mostra una combinazione complessa di tutte le possibilità: tre anelli esterni, di cui uno con un anello interno ed un altro con tre anelli interni, inoltre molti anelli sono costituiti da più di un percorso.
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="outer" /> <member type="way" id="3" role="outer" /> <member type="way" id="4" role="outer" /> <member type="way" id="5" role="inner" /> <member type="way" id="6" role="inner" /> <member type="way" id="7" role="inner" /> <member type="way" id="8" role="inner" /> <member type="way" id="9" role="inner" /> <member type="way" id="10" role="inner" /> <member type="way" id="11" role="inner" /> <member type="way" id="12" role="outer" /> <member type="way" id="13" role="outer" /> <member type="way" id="14" role="outer" /> <member type="way" id="15" role="outer" /> <member type="way" id="16" role="inner" /> <member type="way" id="17" role="inner" /> <member type="way" id="18" role="inner" /> <member type="way" id="19" role="inner" /> <member type="way" id="20" role="outer" /> </relation> |
Isola all'interno di un foro
Poiché è ammesso avere più anelli esterni, è possibile creare agevolmente delle "isole" all'interno di un foro:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> <member type="way" id="3" role="outer" /> </relation> Una caratteristica di questo tipo in precedenza avrebbe richiesto due relazioni multipolygon, una con il percorso 1 esterno ed il percorso 2 interno, e un'altra con il percorso 2 esterno ed il percorso 3 interno. Questa "cascata" è ancora raccomandabile quando l'"isola" al centro rappresenta qualcosa di diverso dall'area esterna. In caso contrario, si può semplicemente fare un foro nel foro. |
Anelli interni che si toccano
Alcuni cartografi usano la relazione multipolygon attuale per raggruppare anelli interni od esterni che si toccano:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> <member type="way" id="3" role="inner" /> </relation> Questo esempio mostra una foresta con una radura, occupate per metà da un lago e per metà da area agricola. In OSM, il cartografo può semplicemente disegnare i perimetri dei tre oggetti (foresta, lago, area agricola). Nella normativa "OGC Simple Feature Standard" questa possibilità non è prevista, gli anelli interni che si toccano non sono supportati. Sarebbe invece necessario disegnare dapprima un foro nella foresta, e poi all'interno di questo foro disegnare singolarmente i poligoni per il lago e per l'area agricola. |
Fori in fori (in fori...)
Si possono avere anche dei fori nei fori di un multipoligono. Per esempio una foresta con una radura, e un boschetto al centro della radura.
Esempio non disponibile. Secondo la normativa "OGC Simple Feature Standard", questa struttura si realizza con un'alternanza di anelli esterni ed interni. Nel nostro esempio, i perimetri della foresta e del boschetto sono anelli esterni, mentre la radura è un anello interno. Questo può in teoria continuare a piacere, ma si suggerisce di limitare la complessità nell'interesse degli altri cartografi. I fori nei fori potrebbero non essere supportati da tutti gli editor o renderer. Figura non disponibile. |
Altri esempi
- esempi di multipoligoni validi su IT:Multipolygon Examples e IT:Relation:multipolygon/Examples.
- vari esempi di configurazioni strane sia valide che errate
Esempi sbagliati
Alcuni esempi di relazioni multipoligono non valide per illustrare cosa NON andrebbe fatto
Poligoni non chiusi
È un esempio di multipoligono non valido perché il percorso #2 e #3 non sono collegati. |
Percorsi membro aventi lo stesso ruolo, aperti e che si incrociano fra loro
È un esempio di multipoligono non valido perché gli estremi del percorso #2 e #3 condividono più di due percorsi. |
Multipoligono costituito da un solo poligono
È un esempio di multipoligono non valido perché i nodi 4 e 5 sono riutilizzati come 10 e 11. Secondo le regole dell'OpenGIS Open Geospatial Consortium (OGC) (en), non è un poligono valido. Verrà segnalato come errore dallo strumento di controllo della qualità Osmose. |
Etichettatura
- Si suggerisce di aggiungere tutte le etichette che descrivono un'area alla relazione, e non ai percorsi. In molti casi ne risulteranno percorsi completamente privi di etichette.
- Per mantenere la compatibilità:
- Lo stile di raffigurazione viene ricavato dall'etichettatura della relazione stessa.
- Se la relazione è priva di etichettatura viene utilizzato lo stile di raffigurazione del percorso esterno.
- Se gli stili del percorso esterno non corrispondono a quelli della relazione, o se non è specificato alcuno stile, viene considerato un errore.
- l'etichettatura dei percorsi interni specifica la rappresentazione degli anelli interni. Qualora lo stile di rappresentazione dei percorsi interni coincida con quello dei percorsi esterni (vecchio metodo) si procede come se lo stile dei percorsi interni non fosse stato specificato.
Dettagli sull'etichettatura
Per i problemi che si possono presentare in vari casi vengono suggerite le seguenti soluzioni:
- Esiste più di un percorso esterno:
- La relazione è etichettata
- valgono le etichette della relazione. Le etichette sui percorsi vengono ignorate.
- La relazione non è etichettata, ma uno o più dei percorsi che formano il contorno esterno hanno etichette identiche e valide
- le etichette dei percorsi esterni etichettati vengono applicate all'intero contorno esterno.
- La relazione non è etichettata, e i percorsi esterni hanno etichettature differenti
- questa situazione crea problemi e l'interpretazione non è univocamente definita.
- Esiste più di un percorso interno:
- Un percorso chiuso (che può essere costituito da uno o più segmenti) non ha etichette, ma un altro è etichettato
- il percorso chiuso non etichettato viene rappresentato come un foro, il percorso etichettato viene rappresentato conformemente alle sue etichette.
- Più percorsi chiusi con etichette diverse.
- ogni foro viene rappresentato conformemente alle sue etichette.
- Un percorso chiuso (costituito da due o più segmenti), in cui i vari segmenti hanno etichette diverse
- se tutti i segmenti hanno le stesse etichette oppure ne sono completamente privi, semplicemente vengono usate le etichette dei segmenti etichettati. Se i vari segmenti hanno etichette diverse, l'interpretazione non è univocamente definita (analogamente al caso dei percorsi esterni).
Rendering
- JOSM è capace di disegnare i multipoligoni avanzati a partire dalla versione 1203
- Osmarender (T@H) supporta i multipoligoni avanzati.
- La configurazione di rendering di Mapnik usata per OpenStreetMap supporta i multipoligoni avanzati in larga misura.
- mkgmap supporta i multipoligoni avanzati a partire dalla versione 1497
- Esiste un algoritmo suggerito per processare i multipoligoni.
Esempio Potlatch 2
Qui c'è una radura in mezzo a un bosco:
Fai clic sulla way esterna (outer):
Control + Clic sulla way interna (inner):
Nota come sia comparsa l'icona "ciambella" nella toolbox:
Per vedere i tag che sono stati aggiunti clicca su "Advanced":
Il multipoligono è stato creato:
Strumenti di aiuto
Voci correlate
- Consulta The Future of Areas (en) per leggere alcune discussioni su come migliorare la gestione delle aree in OSM.