Bonjour, pour pouvoir construire des cartes sur wikipedia (ex cette page Frontière entre la France et le Suriname — Wikipédia) , j’ai besoin du tag type=boundary pour qu’un modèle wikipédia puisse interroger une relation OSM.
Or je suis réverté un peu vertement par un user OSM au motif que je devrais m’informer sur ce que c’est qu’une multilinestring et qu’il est interdit de mettre boundary même quand ça ressemble à une frontière 
Deux choses de ce que je comprends : m’est-il interdit de transformer un type=multilinestring en boundary ? Puis je créer une relation « copie » avec type type=boundary ?
La modif en question : Relation: France - Andorra (126410) | OpenStreetMap
type=boundary est utilisé uniquement pour définir l’ensemble des frontières, pas une partie entre deux zones (pays ou autres).
Ce seront donc les frontières de la France, toutes les frontières et au final on a un multipolygone, c’est clairement indiqué sur Relation:boundary - OpenStreetMap Wiki
Il y a aussi ceci qui est important à lire à propos des frontières: France boundary pyramidal construction - OpenStreetMap Wiki
Bonjour bouzinac,
pour tes questions:
Non, tu ne peux pas modifier le tag d’un objet pour qu’il correspond à ton projet .
Oui, tu peux créer une nouvelle relation boundary pour créer un objet réel manquant à la base de données OSM à partir de « ways » existant ou nouveaux .
OSMWiki : attention aux conflits avec les limites étatiques …
Pour la def de multilinestring :
https://wiki.openstreetmap.org/wiki/Relation:multilinestring
D’accord. Je reformule ce que je comprends :
- il ne faut pas modifier un type d’un objet qui existe déjà
- je peux rajouter une relation qui partage des traits communs en partant de la base (les chemins) et en les regroupants dans une relation qui liera d’une certaine façon ces chemins
- Et la nouvelle relation peut avoir le type=boundary
Cf ce que j’ai fait : Relation: 16105609 | OpenStreetMap est ce accepté ?
Si tu veux la frontière entre la France et le Luxembourg c’est Relation: France - Luxembourg / Luxemburg / Lëtzebuerg (90340) | OpenStreetMap. Un objet dans OpenStreetMap a une représentation, pas 36. Et là tu dupliques car mets le même wikidata.
Doc non ce que tu propose n’est pas bon. Explique plutôt pourquoi tu veux créer ce machin qui n’a pas de inner ou d’outer et n’est donc pas une relation de type boundary… mais une… multilinestring.
Ce que je comprends c’est que le modèle Wikipédia que tu veux utiliser n’est pas adapté. Soit tu en trouves un, soit tu demandes à quelqu’un côté Wikipedia de créer un tel modèle.
Ta tentative de créer un objet plus ou moins ex-nihilo est vouée à l’échec : ce sont les « vrais » objets qui sont maintenus.
Je comprends bien le fait qu’on évite des doublons. La frontière franco-luxembourgeoise est une chose réelle au sens où il y a des traités, des accords, etc.
Aujourd’hui, le modèle Kartographer que wikipédia utilise pour taper dans OSM n’accepte que des type=multipolygon, type=route, et type=boundary. Un phabricator (débogage wikipedia) existe depuis 2017 sans résolution du problème.
OSM ne veut pas d’une relation type=boundary (pour une raison qui m’échappe un peu mais bon passons, je ne suis pas spécialiste OSM), il n’existe pas de possibilité de dire simultanément multilinestring+boundary ou ce genre d’astuce.
En d’autres termes, vous êtes en train de dire que pas possible pour diverses raisons côté OSM et côté wikipedia.
Pourtant, l’intérêt que je vois est d’illustrer ce genre de carte Frontière entre la France et le Suriname — Wikipédia
Est-ce possible de laisser ou est ce que fatalement quelqu’un d’OSM va supprimer les trucs de type boundary ?
1 Like
Je vois que le wiki a assoupli la règle sur le typage des chemins, FR:Tag:boundary=administrative — OpenStreetMap Wiki, il n’empêche ce qui existe marche, pas de raison de la casser. En paticulier ici c’est composé de 44 chemins.
Je vois que sur la page du Surinametype=line (et trouve un chemin/way), mais ici le template ne sait lire/chercher le modèle multiline ? Étant donné que Kartographer sait gérer les type=route et type=boundary, l’étendre aux multilinestring ne devrait pas être trop compliqué (dans le sens où c’est le même style de données).
On n’a jamais dit que ça n’avait pas d’intérêt ! Simplement la logique c’est que c’est au client (ici Wikipédia) de s’adapter aux données du modèle (icic données OSM) et si le modèle est baroque de proposer une évolution. Ici les deux frontières ne sont pas comparables.
Apparemment, le bug est connu depuis 2017 côté wiki, cf https://phabricator.wikimedia.org/T156433 : uniquement quatre types sont acceptés en provenance d’OSM. Je suis bien d’accord que c’est au boulanger de s’adapter à ce que le meunier lui fournit comme matière première (uniquement de la farine de blé, mais pas au son par ex).
Contrairement à une idée reçue, les frontières bougent parfois (ex https://www.assemblee-nationale.fr/12/projets/pl3551.asp). Mais en gros zoom, ça devrait rester inaperçu. Je pense que je vais me contenter d’une bête capture écran… C’est moins interactif/cool mais tant pis.
Pour revenir un peu à la définition de type=multilinestring je crois comprendre que c’est un genre de trait sans surface avec possibilité de traits discontinus.
La frontière entre Lux et France étant continue du début jusqu’à la fin sans coupures ni trous, ne devrait-elle pas être de type=route ?
type=boundary comme type=multipolygon, l’objet est une surface, il faut que l’ensemble des chemins définissent un chemin fermé (il peut y avoir plusieurs chemins fermés).
type=route et type=multilinestring c’est pour un objet linéaire, par contre type=route s’applique à des objets linéaires bien spécifiques. une liste de ces type d’objets dont les frontières ne font pas parties : Key:route - OpenStreetMap Wiki.
En gros 2 types : les itinéraires réguliers de bus, tramways, métros… ou l’ensemble des tronçons faisant partie de, par exemple, l’autoroute A1 ou la Ligne à grande vitesse Atlantique.
Très clair sur les nuances de type entre ligne fermée, ligne ouverte, avec ou sans surface.
Dernière question, quel est l’impact technique de dire que ce truc est de type X et pas de type Y ? C’est juste une convention de catalogage ou ça a aussi des impacts techniques ?
Les relations dans OSM servent a deux choses:
- décrire des géométries complexes (multipolygon et multilinestring)
- des objets « logiques » un itinéraire, une ligne de bus
type=boundary rentre dans la seconde catégorie, car on va mettre dans la relation l’ensemble des frontières mais aussi un noeud qui représente le centre administratif et l’on peut aussi intégrer comme membres d’autres relations qui décrivent un sous découpage
Le bug est identifié côté kartographer, depuis 6 ans… inutile de tordre le modèle OSM ou d’utiliser des tags inadaptés pour le contourner.
Il est probable que ce soit l’import des données OSM qui soit en cause, les multilinestring ne sont par exemple pas pris en compte par défaut par osm2pgsql.
Dans une des bases OSM importées sur les serveurs d’OSM-FR, on avait ainsi modifié le fichier de config pour obtenir les géométries des rivières (relation type=waterway).
Je ne connais pas la stack logicielle utilisée par kartographer, mais il est très probable qu’une modif du fichier de config (simple) et un ré-import (long et impactant) soit la solution.