User talk:PhQ

From OpenStreetMap Wiki
Jump to navigation Jump to search

Multipolygone

v · d · e
Public-images-osm logo.svg multipolygon
Multipolygon Illustration 6.svg
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. Modifier cette description dans la page wiki. Modifier cette description dans l'élément.
Groupe: Propriétés
Membres

  • way - outer
  • way - inner
Statut : de fait
More details at taginfo
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

Chemin ou Nœud Rôle Occurrence Explication
way outer un ou plus Les segments constituants l'extérieur de la surface.
way inner zéro ou plus Les segments constituants l'intérieur de la surface.
way blanc Dans la grande majorité des cas, une relation peut être interprété correctement sans le recours aux rôles inner et outer. Mais il est recommandé de renseigner ces rôles pour aider les autres contributeurs à mieux comprendre la relation.

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>
Figure 1: Une limite outer et une inner

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>
Figure 2: Une limite extérieure et deux limites intérieures

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>
Figure 3: Segments multiples formant une limite fermée

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.

Figure 4: Deux surfaces disjointes

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>
Figure 5: Deux surfaces distinctes avec de multiples segments

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>
Figure 6: Combinaisons complexex des fonctions avancées

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 !

Figure 7: Ile à l'intérieur d'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

Figure 8: Limites intérieures jointives

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:
  • Les segments de chemin sont désignés avec des larges points noirs à leurs extrémités.
  • Les chemins sont identifiés avec des nombres 1, 2, 3 ....
  • Les surfaces sont désignées par des lettres capitales A, B, C, ....
  • Les nombres et lettres dans les figures sont suivis par les étiquettes des objets (segment ou surface)pour rendre les figures compréhensibles par elle même.
  • Dans le cadre des exemples, seuls les étiquettes indispensables sont indiquées.
  • Les étiquettes qui ne sont pas indispensables à la bonnes compréhension des exemples sont omis P.E. name=*, source=*.
  • Les relations sont décrites sous forme de texte pour les rendre plus lisible que la notation XML.
  • Les nouveaux membres ajoutés dans l'étape courante sont inscrites en >italique.

Relation 

   Étiquette pour la Relation
   ...
   Membres de la Relation
 >Nouveau membre de la Relation
   ...


Convention utilisé)

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 (One closed way)

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 lake (One outer and one inner ring)

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 (One outer and two inner rings)

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 two lakes and an island (Nested multipolygons)

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
Forest with 2 lakes, island, boundary and highway (Multiple ways forming nested multipolygons)

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
Farmland adjacent to forest and farmyard adjacent to lake (Touching outer and inner rings)

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
Three separated farmland (Disjunct outer rings)

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
Meadow with farmland with two forest with scrub (Polygons nested 4 levels)

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
Forest with three wood (Theory)

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
Forest with three wood (Practice)

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

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}}

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User_talk:PhQ&oldid=2374365"