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....@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. > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
