[OSM-talk-fr] Automatisation des liens Wikipedia vers les communes

Philippe Verdy verdy_p at wanadoo.fr
Dim 11 Nov 20:44:32 UTC 2012


Pas forcément. Pouyr une carte qui n'afficherait pas les limites communales
ou si celles-ci ne sont pas visibles car elles sortent du cadre, on
s'attend à trouver le noeud visible qui affiche le nom de la commune donner
des infos sur celle-ci. Bien sûr une requête permettrait de savoir de
quelle(s) relation(s) elle est l'admin_center pour trouver ce lien
Wikipédia. Malgré tout cela se complique car un même noeud est souvent
admin_center de plein de choses, alors que le noeud lui-même porte pourtant
un nom qui lui est propre est est celui de la commune (mais il pourrait
n'être aussi que le nom d'une localité et pas une commune, donc on ne sait
pas vraiment où chercher l'info).

L'idéal serait que les noeuds indiquent que leur nom est attaché à un
niveau d'admin_centre bien défini, ce n'est pas simple car ce qui qualifie
nos noeuds ce sont des classifications en grandes villes, villes, villages,
hameaux, qui correspondent à des niveaux administratifs différents.

Le lien Wikipédia pourtant doit pouvoir pointer sur un article pertinent,
que ce soit un article sur la commune, ou l'agglomération entière, ou un
article sur un village ou quartier dans la commune.

Bref, il est difficile d'écrire une règle simple pour décrire corectement
ce que désigne le noeud seul, malgré ses attributs qui ne suffisent PAS à
indiquer qu'il s'agit du nœud d'une commune, mais seulement celui d'une
agglomération (petite ou grande),car l'article Wikipédia ne décrit pas ce
seul noeud mais l'entité plus grande (ou plusieurs) contenant ce nœud avec
ce nom.

Pour se contenter de mettre uniquement dans la relation il faudait donc
absolument qualifier les noeuds pour bien dire qu'ils représentent un point
central nommé d'après une entité plus grande (en principe la plus petite
d'entre elles s'il y en a plusieurs). Sinon l'autre solution est plus
complexe et consiste à chercher parmi les relations qui utilisent le noeud
celle qui a la valeur admin_level la plus élevée: ça marchera quand le
noeud est une entité administrative, mais pas s'i c'est autre chose (un
quartier par exemple).

Enfin ce n'est pas si simple : nombre de surfaces n'ont ni admi_centre, ni
de centroïde tombant **dans** la surface. Le libellé d'un rendu ne peut pas
toujours alors être positionné dans la surface, et si un rendu doit
afficher une icône clickable pour afficher les infos, on ne sait pas où la
mettre. Si de plus la surface comprend des exclaves, il n'y a plus rien où
cliquer. Si on cherche l'ensemble des relations couvrant un point cliquable
(ce qui serait en fin de compte la meilleure solution dans une interface
destinée à donner des infos sur un point cliqué), alors là on peut afficher
les infos relation par relation. Mais l'interface devient aussi nettement
plus lourde. Si l'interface ne peut supporter que les infos sur un seul
point, alors il ne nous reste que le nœud lui-même et les relations qui
contiennent le noeud doivent être ignorées.

Encore plus complexe: certaines zones administratives ne contiennent PAS
leur centre administratif qui est situé dans une zone voisine :
l'admin_centre est la seule façon de trouver ce centre administratif, car
on ne le trouve pas par une requête géométrique (donc chercher à afficher
toutes les relations qui incluent un noeud dans leur surface ne marchera
pas, sauf si on y inclue AUSSI les relations qui mentionnent le noeud
directement en tant que membre : l'interface doit alors savoir interprêter
les rôles utilisés dans la relation pour savoir à quoi correspond cet
attachement de nœud dans la relation définissant une surface donnée. De
plus des noeuds peuvent aussi être regroupés dans des relations qui ne
définissent PAS des surfaces, mais des ensembles de noeuds proches (par
exemple une liste des noeuds correspondant aux accès à une même station de
métro, ou une liste d'arrêts dans une ligne de transport).

Ce n'est pas toujours simple donc, et souvent il restrera utile de garder
un lien d'informations sur le noeud lu-même. L'idéal serait que le noeud
puisse avoir un attribut indiquant à laquelle des relations il doit être
relié : mais dans OSM on n'a QUE des attributs pour le faire et il n'y a
pas d'intégrité référentielle garantie (donc pas moyen d'indiquer un ID de
relation dans un attribut du noeud.

Moralité: faire comme en Espagne, et qualifier mieux les nœuds en indiquant
explicitement qu'ils sont admin_center d'une ou plusieurs relations, et en
indiquant le plus petit admin_level (relation la plus étendue en surface)
des relations référentes dans un attribut "capital=*" et le plus grand
admin_level (relation la plus petite en surface) dans "admin_level=*" du
noeud, afin d'indiquer explicitement qu'on doit chercher la plupart de ses
autres attributs dans une relation de surface administrative, et là où
c'est pertinent (noter que la relation administrative peut parfois avoir un
nom différent du noeud local, et mentionner plusieurs autres noeuds
admin_centre, voire parfois une surface désignée comme admin_centre, ce qui
complique largement les recherches purement géographiques : certaines infos
de la relation seront pertinentes aussi pour le noeud, certaines non).

En revanche les chifffres de population qu'on indique pour le noeud sont
souvent faux : on ne sait pas sur quelle surface cette population est
comptée et il arrive parfois qu'on indique la population municipale totale,
alors que la municipalité est plus large que le *seul* village qui n'en est
qu'une des agglomérations, et de plus l'admin_centre n'est pas toujours
*dans* une agglomération mais peut être en pleine campagne à mi-chemin
entre plusieurs agglomérations de la commune, voire dans une commune
voisine située entre les villages d'une commune possédant des exclaves, ou
bien dans une enclave dont la surface appartient à une autre commune. Mais
si on met la population de la commune sur le noeud, cela donne une fausse
idée de l'agglomération, et aussi le noeud porte un nom qui n'est pas celui
de la commune dans lequel il a été positionné (sans pour autant faire
aucune erreur).

Si on veut un attachement administratif clair en France, on devrait
utiliser sa référence administrative (ref:INSEE) et l'utiliser pour le
rapporochement avec la bonne relation, mais cela ne marchera qu'en France
(pas de ref:INSEE dans les autres pays, ou alors il faut savoir interpréter
les divers tags "ref:*". tout en étant conscient que la relation parente
trouvée n'aura pas forcément le bon nom et ne correspondra à aucun des noms
de membres admin_centre de la relation (ce cas arrive souvent dans les
communes issues d'une fusion : la commune porte le nom des deux anciennes
communes, mais a pourtant encore plusieurs agglomérations ayant chacune
leur propre nom, l'une avec une mairie principale, l'autre avec une mairie
annexe, mais on peut trouver des servces municipaux répartis dans les l'une
ou l'autre agglomération).

Arrrgh !


Le 11 novembre 2012 14:55, Ab_fab <gamma.gts at gmail.com> a écrit :

> Bonjour,
>
> C'est mieux de faire l'ajout de la balise wikipedia = fr:xxx sur les
> relations des limites administrative communales, plutôt que sur les noeuds
> de type place.
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121111/e5712062/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr