On constitue généralement une relation, qui est composée des ways formant la limite administrative et qui associe parfois un noeud "place" avec le rôle admin_centre. La description de la relation intègre la ref:INSEE, et on peut y ajouter la balise wikipedia
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Communes N'hésite pas à donner des exemples concrets pour des communes où tu considères que ce schéma ne fonctionnera pas Le 11 novembre 2012 21:44, Philippe Verdy <verd...@wanadoo.fr> a écrit : > 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 > > -- ab_fab <http://wiki.openstreetmap.org/wiki/User:Ab_fab> "Il n'y a pas de pas perdus", Nadja
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
