User talk:PhQ
Multipolygone
![]() |
Description |
---|
La relation multipolygon est utilisé pour représenter des surfaces de toutes sortes. Ce type de donnée caractérise les surfaces dans OpenStreetMap. ![]() ![]() |
Groupe: Propriétés |
Membres |
|
Statut : de fait |
Outils pour cet attribut |
|
Les Relations de type multipolygon sont utilisées pour représenter les surfaces de toutes sortes. La relation multipolygon est une donnée caractérisant les surfaces dans OpenStreetMap.
Pour mémoire, les surfaces peuvent aussi être matérialisées en créant un segment circulaire (fermé) et étiqueté avec quelque chose qui représente une surface plutôt qu'un chemin circulaire. Par exemple, un segment circulaire avec l'étiquette landuse=forest sera supposé être une surface, alors que l'étiquette junction=roundabout ne le sera pas tout à fait. Cependant, ce type de codage fonctionne pour des surfaces simples constituées d'une limite d'un seul tenant et sans trou.
Pour toutes surfaces plus complexes que cela, (c'est à dire parce que la limite consiste en plusieurs segments jointifs, ou parce que la surface est constituée de plusieurs parties disjointes, ou en présence de trous) il est nécessaire d'utiliser la relation multipolygon.
Le wiki anglais suggère d'utiliser le type=multipolygon à la place de type=boundary pour les descriptions de frontières administratives ou autres, mais j'ai un doute concernant le consensus sur ce conseil.
It is suggested to also use type=multipolygon (and not type=boundary) for boundary relations if you want applications to use area-building rules (i.e., connecting outers to form rings, excluding enclaves, etc.) A boundary relation is easily spotted by its boundary=* tag; no need to use type=boundary.
En bref, une relation multipolygon peut avoir autant de segments de rôle outer (l'extérieur) que nécessaire ainsi que de segments de rôles inner (les trous) de manière à former les limites intérieurs et extérieures du multipolygone.
Étiquettes
clé | Valeur | Explication |
---|---|---|
type | multipolygon | Instructions pour que les logiciels appliquent les règles de construction de surface aux membres de la relation. |
Membres
Usage
Mode d'emploi d'une relation multipolygone:
- Les étiquettes décrivant le multipolygon (p.e landuse=forest) doivent figurer sur la relation. Le ou les segments extérieurs ne doivent pas être renseigné(s) à moins de décrire quelque chose de spécifique à ce(s) segment(s). (Par exemple, une foret peut être délimité par quatre routes, auquel cas les quatre segments représentants la route seront renseignés avec l'étiquette highway correspondante, mais utilisés dans la relation comme membre avec le rôle "outer".
- Si vous avez un seul chemin fermé représentant la limite extérieure, et qui n'a pas d'autre caractéristique propre, vous pouvez aussi laisser les étiquettes décrivant la nature du multipolygon sur le segment extérieur en laissant la relation non renseignée. Si vous avez plus d'un chemin extérieur pour décrire la surface (Voir Caractéristiques Avancées d'un multipolygone ci dessous), alors cela n'a pas de sens. De ce fait, il est suggéré, par soucis de cohérence, de toujours mettre l'étiquetage du multipolygone sur la relation elle même.
- Si un segment intérieur existe et qu'il représente quelque chose (Par exemple un lac à l'intérieur d'une foret), alors le segment intérieur de rôle inner peut être renseigné en tant que tel. - natural=water -)
- Sinon, le segment intérieur doit rester sans étiquette.
- Le sens des segments n'a pas d'importance.
- L'ordonnancement des différents membres de la relation n'a pas, en principe, d'influence sur le bon déroulement du traitement de l'information par les logiciels de restitution, mais une relation avec des membres correctement mis à leur place aide les contributeurs à vérifier la fermeture des chemins dans les cas complexes.
- Généralement, la relation de type multipolygon est utilisé pour créer des multipolygones en accord avec les prescriptions du standard OGC (OGC Simple Feature standard (http://www.opengeospatial.org/standards/sfs)). Tout ce qui n'est pas conforme à ce standard ne pourra être considéré comme un multipolygone valide, à la notable exception près des trous jointifs (Voir ci dessous).
Exemples
Une limite intérieure et extérieure
L'ancienne formule, largement utilisé, de la relation multipolygon n'autorisait qu'une et seulement une limite extérieure et un nombre quelconque de limites intérieures. La limite externe consistait en un seul chemin fermé. ce type de polygone, peut encore exister, mais c'est juste un cas spécial simplifié de la relation multipolygon actuelle.
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> </relation> |
Une limite extérieure et deux limites intérieures
<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> |
Segments multiples formant une limite fermée
Le principe de la relation multipolygon avancée permet aux limites internes ou externes d'être constituées d'autant de segments jointifs que nécessaire. Ceci est utilisé pour le codage des très grandes surfaces où il serait impraticable d'avoir un seul segment fermé pour les englober.
<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> |
Une relation, deux surfaces disjointes
Contrairement au vieux modèle de multipolygone, le nouveau permet d'avoir aussi un nombre quelconque de limites extérieures et d'être un vrai multipolygone.
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="outer" /> </relation> Toute tentative volontaire ou involontaire de rejoindre des surfaces disjointes par un point ou un segment n'est pas conforme au standard de l'OGC, ne conduit pas nécessairement à des avertissements en phase d'édition, et peut se traduire par des différences de rendus entre les divers moteurs appliqués à la base de donnée. |
Deux surfaces distinctes avec de multiples segments les constituants
La capacité à agréger une limite avec de multiples segments n'est pas réservée aux limites extérieures. On peut aussi le faire pour les trous.
<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> |
Combinaison complexes avec toutes les fonctionnalités
cette exemple présente toutes les fonctionnalités réunis: trois limites externes, deux avec un ou plusieurs trous, avec la plupart d'entre elles constitués de plusieurs segments.
<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> |
Ile à l'intérieur d'un trou
De la possibilité d'avoir de multiples limites externes dans une même relation. Il s'en suit que l'on peut créer une ile dans un trou:
<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> Une construction de ce type aurait requis précédemment plusieurs relations multipolygones, une avec la limite 1 externe et la limite 2 interne, et une autre avec la limite 2 avec le rôle outer ( externe) et la limite 3 interne. Une telle organisation en cascade est toujours recommandée quand l'ile du milieu est d'un type différent de la surface extérieure, mais dans le cas contraire, on peut se contenter de faire un trou dans un trou ! |
Limites intérieures jointives
Some mappers use the current "multipolygon" relation for combining touching inner or outer rings: | certains contributeurs utilisent la relation "multipolygone" avec des limites intérieurs (ou extérieurs) jointives:
<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> Une implémentation de la relation multipolygone avancée essaye de ramener ce cas de figure au cas d'une limite intérieure unique. C'est le seul cas ou OpenStreetMap utilise une version dérivée (déviante ?) du standard "fonctions simples d'OGC" (OGC Simple Features). Dans la norme stricte, les limites intérieures jointives ne sont pas supportées car elles ne sont pas nécessaires. Dans OpenStreetMap il arrive parfois qu'on étiquette de façon séparée, par exemple une forêt avec une clairière qui est composée en partie d'un lac, et d'autre part d'un terrain agricole. Vous aurez alors deux trous dans la forêt, l'un composé d'une étiquette "natural=water" et un autre avec "landuse=farmland". C'est une pratique rapide et commode. Demander aux contributeurs de créer un seul trou dans la foret, avec la création de deux polygones (relation) spécifiques, un pour le lac, un autre pour le terrain pourrait leur demander trop de travail |
Des trous dans les trous (dans des trous)
Il est possible d'avoir des trous dans les trous (pensez à une forêt avec une clairière au milieu de laquelle se trouve un bouquet d'arbres).
Exemple à venir. Ceci est réalisé, en accord avec la spécification simplifié de l'OGC, en créant alternativement des limites extérieures et intérieures; dans notre exemple, l'extérieur de la forêt et le groupe d'arbres constituent chacun une limites extérieure, et la clairière est constituée dans la limite intérieure; ceci peut continuer sans limitation, mais il est préférable de se limiter à une "complexité" raisonnable, aux bénéfices de l'ensemble des autres contributeurs. Avoir des trous dans les trous peut aussi ne pas plaire à tous les éditeurs, ainsi qu'aux moteurs de rendu. Illustration à faire. |
Exemples pour contributeurs, du plus simple au plus complexe, pas à pas
Note: Ceci et le chapitre suivant sont nouveau. Commentaires, corrections, améliorations et suggestions sont les bienvenus.
Dans ce chapitre on passe d'un exemple simple pas à pas vers une structure complexe.
Conventions utilisés pour décrire les exemples:
Relation Étiquette pour la Relation ... Membres de la Relation >Nouveau membre de la Relation ...
|
Forêt (Un chemin fermé unique)
Closed way 1 is drawn and tagged with landuse=forest describing forest A. Tagging a closed way with a tag indicating an area results in drawing an area. This kind of shortcut works for simple areas the outline of which consists of one single way, and which do not have holes. The same could be done with a multipolygon but this would just complicate a simple case. |
Forest with lake (One outer and one inner ring)
Closed way 2 is added within forest A and tagged with natural=water describing lake B. Closed way 1 is now untagged because there are no map features for the whole enclosed area. It doesn't represent something on its own. Forest A which is tagged with landuse=forest is the green ring: the area enclosed by way 1 minus the lake B.
Multipolygon A describes the case. Relation A: type=multipolygon landuse=forest outer 1 inner 2 |
Forest with two lakes (One outer and two inner rings)
Closed way 3 is added within forest A and tagged with natural=water describing lake C. Forest A which is tagged with landuse=forest isn't a simple ring anymore. It's now the area enclosed by way 1 minus lakes B and C.
inner 3 is added to multipolygon A: Relation A: type=multipolygon landuse=forest outer 1 inner 2 >inner 3 |
Forest with two lakes and an island (Nested multipolygons)
Closed way 4 is added within lake B and tagged with natural=scrub describing island D.
Forest A and thus multipolygon A stay unchanged: Relation A: type=multipolygon landuse=forest outer 1 inner 2 inner 3 Closed way 2 is now also untagged because there are no map features for the whole enclosed area anymore. Lake B which is tagged with natural=water is now the blue ring: the area enclosed by way 2 minus the island D. This is described by a second multipolygon B: Relation B: type=multipolygon natural=water outer 2 inner 4 |
Forest with 2 lakes, island, boundary and highway (Multiple ways forming nested multipolygons)
Way 1 used to be the whole boundary of forest A now gets splitted and partially replaced: The linear ways 5, 6, 7 and 8 are added and tagged with boundary=administrative. Further the linear ways 9, 10 and 11 are added and tagged with highway=unclassified.
Way 2 used to be the whole boundary of lake B is also splitted. The ways 12, 13, 14 and 15 are added and tagged with highway=track. There are own map features for ways 5 to 15 and thus they are tagged with them regardless whether they are members of multipolygons because they aren't areas. The "remaining" way 1 and the ways 6 and 10 are now forming the boundary of forest A. outer 6, outer 10 and inner 13 are added to multipolygon A: Relation A: type=multipolygon landuse=forest outer 1 >outer 6 >outer 10 inner 2 >inner 13 inner 3 The ways 2 and 13 are forming the boundary of lake B. outer 13 is added to multipolygon B: Relation B: type=multipolygon natural=water outer 2 >outer 13 inner 4 |
Remarks:
- When a highway is chosen as boundary of an area than the roadside and not the (imaginary) center line of the road is the boundary.
- Some mappers prefer to use ways as boundaries of areas as in this example, some prefer drawing separate lines and some use both depending on the situation.
- This sequence of examples started with areas. In practise it's more likely to have linear features like highways before areas are added.
Farmland adjacent to forest and farmyard adjacent to lake (Adjacent multipolygons and adjacent inner areas)
The former way 1 gets splitted again into a new short way 1 and a new way 16 which is tagged with barrier=fence. Way 17 is added and tagged with barrier=fence. Way 18 is added and not tagged. Ways 7, 16, 17 and 18 are forming the boundary of farmland E which is adjacent to forest A. They share the way 16. Closed way 19 is added by creating two new nodes on way 7 and drawing a short duplicate way on top of way 7. Way 19 is tagged with landuse=farmyard describing farmyard G. Closed way 20 is added by using the two northern nodes of way 19 and drawing a duplicate way on top of the northern boundary of farmyard G. Way 20 is tagged with natural=water describing a third lake F.
outer 16 is added to multipolygon A: Relation A: type=multipolygon landuse=forest outer 1 >outer 16 outer 6 outer 10 inner 2 inner 13 inner 3 Multipolygon B stays unchanged: Relation B: type=multipolygon natural=water outer 2 outer 13 inner 4 Farmland E is described by a new multipolygon E: Relation E: type=multipolygon landuse=farmland outer 7 outer 16 outer 17 outer 18 inner 19 inner 20 |
Remarks:
- Duplicate ways, i.e. ways on top of each other, are acceptable, duplicate nodes, i.e. nodes on each other, not.
- Duplicate ways can be avoided by using multipolygons. But in this example it would just complicate a simple case.
Three separated farmland (Disjunct outer rings)
Way 21 is added and not tagged. Way 22 is added and tagged with barrier=fence. Way 21 and 22 are forming farmland E2 which is separated from but belongs to farmland E.
Way 23 is added and not tagged. Way 24 is added and tagged with barrier=fence. Way 23 and 24 are forming farmland E3 which is separated from but belongs to farmland E. Closed way 25 is added within farmland E3 and tagged with natural=water describing lake H. Multipolygon A stays unchanged: Relation A: type=multipolygon landuse=forest outer 1 outer 16 outer 6 outer 10 inner 2 inner 13 inner 3 Multipolygon B stays unchanged: Relation B: type=multipolygon natural=water outer 2 outer 13 inner 4 outer 21, outer 22, outer 23, outer 24 and inner 25 are added to multipolygon E: Relation E: type=multipolygon landuse=farmland outer 7 outer 16 outer 17 outer 18 inner 19 inner 20 >outer 21 >outer 22 >outer 23 >outer 24 >inner 25 |
Examples for mappers
Meadow with farmland with two forest with scrub (Polygons nested 4 levels)
Rule: When polygons are nested over several levels it's the safest way to
- tag only the most inner closed ways with tags describing an area and
- tag the other closed ways only in such a way that no area is described and
- use multiple multipolygons each describing two adjacent levels.
This example originated from the discussion Verschachtelte Multipolygone in the forum Germany.
Closed ways 1 and 2 enclose areas with holes. Thus multipolygons are needed and the ways aren't tagged. Ways 3 and 4 as well as 5 and 6 are multiple ways enclosing areas. Thus multipolygons are needed. Ways 3 and 6 are tagged with their own map features. Ways 4 and 5 have no map features and thus are untagged. Closed way 7 doesn't have holes and it is tagged with a map feature which describes an area. Thus no multipolygon is needed.
Multipolygon A describes the meadow A, multipolygon B the farmland B, multipolygon C the forest C and multipolygon D the forest D: Relation A: type=multipolygon landuse=meadow outer 1 inner 2 Relation B: type=multipolygon landuse=farmland outer 2 inner 3 inner 4 inner 5 inner 6 Relation C: type=multipolygon landuse=forest outer 3 outer 4 Relation D: type=multipolygon landuse=forest outer 5 outer 6 inner 7 |
Forest with three wood
This example originated from the discussion Multipolygone, z.B. See oder Gebäude in Waldfläche in the forum Germany. It demonstrates how current deficiencies of the renderers in processing multipolygons can be circumvented while still tagging correctly according to the reality. No Tagging for the renderer.
Theory:
A big forest of mixed wood which has three holes with coniferious, deciduous and mixed wood can be described correctly by Relation A in theory. But the renderers including editor JOSM currently don't process it correctly. Closed ways 1, 2, 3 and 4 are tagged as shown in the figure. Closed way 1 is tagged with the name "Big forest" of the whole area enclosed by way 1.
Relation A: type=multipolygon landuse=forest wood=mixed outer 1 inner 2 inner 3 inner 4 |
Practice:
The following description is correct too, but uses four multipolygons to circumvent the current deficiencies of the renderers. Way 1 and relation A stay unchanged. The tags of the ways 2, 3 and 4 are moved from the ways to new relations B, C, D. Relation A: type=multipolygon landuse=forest wood=mixed outer 1 inner 2 inner 3 inner 4 Relation B: type=multipolygon landuse=forest wood=coniferious name=Coniferous outer 2 Relation C: type=multipolygon landuse=forest wood=deciduous name=Deciduous outer 3 Relation D: type=multipolygon landuse=forest wood=mixed name=Mixed outer 4 |
Tagging
- It is suggested to apply all tags which describe the area to the relation, and not to the ways. In many cases this may result in completely untagged ways.
- Implementation for compatibility:
- Drawing style is taken from the tagging of the relation itself.
- If relation is not tagged, the drawing style of outer ways is used.
- If the outer styles mismatch or no style is found it is considered an error.
- Inner tagging leads to inner drawing. If inner tagging style equals outer style (an old method) the inner style should be handled as empty.
Detailed tagging
The tagging for this multipolygon relation can be done in quite a few ways. Here is a list of cases, problems and proposed solutions:
- There is more than one outer way:
- The relation has tags
- Use the relation tagging. Ignore anything on the ways.
- The relation has no tags, but one or more constituting outer ways have an identical set of tags
- Valid data, take the tags from the tagged segments and apply them to the complete outer way.
- The relation has no tags, and constituting outer ways are tagged differently
- This is a problem situation with undefined results.
- There is more than one inner way:
- One closed way (consisting of one or more segments) has no tags but another one has tags.
- The way without tags is rendered as a hole, the way with tags according to its tags.
- Different closed ways with different tags.
- Each hole is rendered on its own according to its tags.
- One closed way (consisting of two or more segments) where the segments have different tags.
- If some segments have no tags at all just use the tags from the other segments. If the segments have different behaviour is undefined (as for "outer" ways).
Rendering
- JOSM is able to render these advanced multipolygons since revision 1203
- Osmarender (T@H) supports advanced multipolygons
- The mapnik rendering configuration at www.openstreetmap.org does not fully support "advanced multipolygons" (But mostly)
- Fully supported by mkgmap since revision 1497
- [GpsMid] supports at least a great majority of advanced multipolygon features
- There is a suggested Algorithm for processing multipolygons.
Potlatch example
In Potlatch, roles for a multipolygon relation should be assigned to the relation member itself, and not as separate tags. When in edit mode, select the relation member and put inner or outer in the box on the same line as where it says multipolygon.
Step-by-step guide
Please write me.
Helping Tools
Attribution
Hello! And sorry for bothering you, but descriptions of files you uploaded need to be improved.
You have uploaded files which are licensed as requiring attribution. But right now attribution is not specified properly.
Please, ask for help if something is confusing or unclear in this message.
Please, fix that problem with this uploads - note that images with unclear licensing situation may be deleted.
Attribution may be missing completely or just be specified in nonstandard way, in either case it needs to be improved. Note that using CC-BY files without specifying attribution is a copyright violation, which is often unethical and unwanted. So clearly specifying required attribution is needed if license which makes attribution mandatory was used.
If it is applying to your own work which not based on work by others - then you can select own user name or some other preferred attribution or even change license to for example {{CC0-self}}
For your own work: ensure that it is clearly stated at file page that you created image/took the photo/etc
For works by others - please ensure that there is link to the original source which confirms license and that you used proper attribution, or that source is clearly stated in some other way.
Especially for old OSM-baded maps, made from data before license change on 12 September 2012 you should use "map data © OpenStreetMap contributors" as at least part of attribution
For old OSM Carto maps, which predate license change on 12 September 2012 you can use a special template {{OSM Carto screenshot||old_license}}