Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Bonjour, Désolé d'avoir mis tant de temps à réagir. Merci pour vos réponses. En fait, j'ai relu plusieurs fois le long message de Philippe (merci d'avoir pris le temps de décrire longtemps les différentes problématiques), et… je n'arrive pas à me faire d'avis (place ou relation?). Bref, je n'arrive plus trop à me motiver pour ça (le débat a pas mal enlevé le coté fun «je code, je teste, je soumets à revue et je lance le tout»). Fabien Le 11/11/2012 21:44, Philippe Verdy 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). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Merci pour ta réponse. Je ne connais pas «xapi/overpass», il faudra que je regarde comment ça marche. Mon idée à l'origine était d'utiliser les dumps non-pas comme base sur laquelle j'allais faire des modifications, mais pour lister les entités qui sont susceptibles d'être enrichies. Une fois leur liste dressée, je récupérais leur dernière version via l'API 0.6 (en donnant une liste d'ID), ou bien xapi/overpass si c'est plus adapté), je préparais des fichiers pour JOSM. Donc il n'y avait pas de risque de conflit (si ça devait arriver, je pouvais relancer la moulinette avec les entités non-mises à jour). Fabien Le 11/11/2012 20:07, sly (sylvain letuffe) a écrit : Si la question est êtes vous d'accord si je le fais comme indiqué ?, je réponds oui pour l'idée, mais comme dit par d'autres, je préfère que ça soit fait sur la relation qui porte la commune et pas sur le noeud place. Si la relation n'existe pas, je préfère alors que rien ne soit fait. La raison étant que tôt ou tard les limites de communes y seront, que ça va faire une édition de masse incohérente en méthode En gardant à l'esprit que l'opération pourra être relancée plus tard. Si la question sous-entends un pensez-vous qu'il y a moyen de faire mieux parce que tu rencontres une difficulté pour le faire ou juste pour confronter à une autre idée, je proposerais plutôt la méthode suivante : - téléchargement des relations communes par xapi/overpass par pack de x (~50) - ajout du tag wikipedia si non présent et conditions requises présentes - ré-upload de la nouvelle version du pack de x histoire de limiter le temps pendant lequel on pourrait créer un conflit de + en cas de panne à l'aide d'un log tu peux reprendre là où tu en étais plus simplement il me semble. Idéalement identifier tes changesets : http://wiki.openstreetmap.org/wiki/Proposed_features/changeset_tags Je peux comprendre toutefois que cette variante ne soit pas nécessairement réaliste dans ton cas, mais me semble intéressante pour limiter le risque de conflit par rapport à : dump france en retard temps traitement upload long conflit bloquant avec JOSM ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Les API étendues (XAPI et overpass) permettent d'interroger une base de données pour ne récupérer que les objets qui nous intéressent. Dans beaucoup de cas, c'est beaucoup plus efficace que de travailler sur un dump de la base, très volumineux, qui nécessite généralement de se recréer une base locale. On peut ainsi interroger l'overpass pour obtenir les objets qui correspondent à certains critères et son langage de requête permet de faire pas mal de choses. Autre avantage, si l'on interroge un serveur qui est en mise à jour à la minute, on a de très fortes chance d'avoir la dernière version des objets. http://wiki.openstreetmap.org/wiki/Overpass_API 2 serveurs overpass sont disponibles sur les serveurs d'OSM-FR: api.openstreetmap.fr et oapi-fr.openstreetmap.fr Le premier a une couverture monde, le second France métropolitaine (ce qui permet d'alléger les recherches quand on ne travaille que sur l'hexagone). Le 2 décembre 2012 15:11, Fabien SK fabie...@gmail.com a écrit : Merci pour ta réponse. Je ne connais pas «xapi/overpass», il faudra que je regarde comment ça marche. Mon idée à l'origine était d'utiliser les dumps non-pas comme base sur laquelle j'allais faire des modifications, mais pour lister les entités qui sont susceptibles d'être enrichies. Une fois leur liste dressée, je récupérais leur dernière version via l'API 0.6 (en donnant une liste d'ID), ou bien xapi/overpass si c'est plus adapté), je préparais des fichiers pour JOSM. Donc il n'y avait pas de risque de conflit (si ça devait arriver, je pouvais relancer la moulinette avec les entités non-mises à jour). Fabien Le 11/11/2012 20:07, sly (sylvain letuffe) a écrit : Si la question est êtes vous d'accord si je le fais comme indiqué ?, je réponds oui pour l'idée, mais comme dit par d'autres, je préfère que ça soit fait sur la relation qui porte la commune et pas sur le noeud place. Si la relation n'existe pas, je préfère alors que rien ne soit fait. La raison étant que tôt ou tard les limites de communes y seront, que ça va faire une édition de masse incohérente en méthode En gardant à l'esprit que l'opération pourra être relancée plus tard. Si la question sous-entends un pensez-vous qu'il y a moyen de faire mieux parce que tu rencontres une difficulté pour le faire ou juste pour confronter à une autre idée, je proposerais plutôt la méthode suivante : - téléchargement des relations communes par xapi/overpass par pack de x (~50) - ajout du tag wikipedia si non présent et conditions requises présentes - ré-upload de la nouvelle version du pack de x histoire de limiter le temps pendant lequel on pourrait créer un conflit de + en cas de panne à l'aide d'un log tu peux reprendre là où tu en étais plus simplement il me semble. Idéalement identifier tes changesets : http://wiki.openstreetmap.org/wiki/Proposed_features/changeset_tags Je peux comprendre toutefois que cette variante ne soit pas nécessairement réaliste dans ton cas, mais me semble intéressante pour limiter le risque de conflit par rapport à : dump france en retard temps traitement upload long conflit bloquant avec JOSM ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Je me demande (par curiosité, pas par besoin immédiat) quelle est la taille géographique raisonnable que je pourrais interroger avec Overpass, sans trop charger le serveur. La France entière? Par exemple si je demandais tous les nœuds «place» ayant un attribut «ref:INSEE» mais pas de «wikipedia», cela me retournerait un nombre raisonnable de nœuds. Par contre je ne sais pas quel travail cela demanderait au serveur et à sa base. Est-ce que la magie des index ferait que ça serait véloce, ou bien il devrait traiter un très grand nombre de nœuds et tout filtrer? De toute façon, je pense que si j'avais à nouveau un projet qui couvrait un pays, j'étalerais le tout (recherches et modifications) dans le temps, en découpant le territoire en zones, comme ceci: http://www.openstreetmap.org/user/JaTrainWikipedia/edits Fabien Le 02/12/2012 15:39, Christian Quest a écrit : Les API étendues (XAPI et overpass) permettent d'interroger une base de données pour ne récupérer que les objets qui nous intéressent. Dans beaucoup de cas, c'est beaucoup plus efficace que de travailler sur un dump de la base, très volumineux, qui nécessite généralement de se recréer une base locale. On peut ainsi interroger l'overpass pour obtenir les objets qui correspondent à certains critères et son langage de requête permet de faire pas mal de choses. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Le dimanche 02 décembre 2012 20:52:13, Fabien SK a écrit : Je me demande (par curiosité, pas par besoin immédiat) quelle est la taille géographique raisonnable que je pourrais interroger avec Overpass, sans trop charger le serveur. La France entière? Faut essayer ;-) Le logiciel installé est prévu pour parer à (presque) toutes les éventualités, donc si ça dépasse ses capacité, il renverra une message d'erreur qui en gros veut dire trop long à répondre. Par exemple si je demandais tous les nœuds «place» ayant un attribut «ref:INSEE» mais pas de «wikipedia», cela me retournerait un nombre raisonnable de nœuds. Au doigt mouillé, si tu lui demandes ça, ça devrait passer. J'ai récemment demandé tous les repères géodésiques de france soit 140'000 noeuds et ça a marché en ~20 secondes là où la durée max autorisée est de 30s par défaut. Si toutefois ça devait durer plus longtemps, il existe un paramètre, dispo uniquement avec l'overpass, lui permettant de prendre encore plus de temps, la limite hard étant de 1h si je me souviens bien. Et si le téléchargement intégral de toute la france (soit ~60Go) ne passerait sans doute pas, dès que tu imposes une condition un minimum restrictive, ça devrait le faire. Par contre je ne sais pas quel travail cela demanderait au serveur et à sa base. Est-ce que la magie des index ferait que ça serait véloce, ou bien il devrait traiter un très grand nombre de nœuds et tout filtrer? Il le fera suffisamment bien, c'est à dire : pourrait encore mieux faire (postgresql/postgis étant plus performant), mais déjà largement suffisent par rapport à plein d'autres options. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
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
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Là on dirait que tu me fais un cours d'initiation de base, comme si je n'avais pas compris ça déjà. Le problème c'est surtout de savoir dans lequel des deux (le noeud ou la relation) un tag est le plus pertinent. Le noeud n'est pas pertinent pour la population, et j'ai listé des exemples où la répartition simple avec une relation et un seul noeud admin_centre ne marche pas toujours : noeud hors de la zone, ou plusieurs noeuds, et noeuds qui ne décrivent pas par leur nom de localité (place=*) le nom de la relation, et ambiguité dans le cas très fréquent où le même noeud est admin_centre de plusieurs relations (incluses les unes dans les autres en terme de surface voire parfois adjascentes sans aucune intersection autre que leur frontière, mais pas toujours). La population est un bon exemple : elle doit guider normalement le type de place=* qu'on met pour la localité, pourtant la popualtion devrait être celle de l'agglomération (ou partie d'agglomération) désignée par le noeud et non celle de la commune entière qui peut s'étendre sur plusieurs agglomérations (c'est le cas de nombreuses communes fusionnées qui ont plusieurs villages, conservant chacun leur nom propre : quel est le niveau administratif pertinent pour compter la population ? ce n'est pas toujours la commune au niveau 8 car elle est trop grande... De même ici concernant un article Wikipédia : il ne porte en général pas sur un seul nœud mais sur une commune entière (parfois un quartier ou un des villages de la commune). Pourtant c'est sur le nom assigné au nom place=* qu'on va aller chercher l'info en cliquant dessus sur une carte. Bref ton message parle du principe de base (que j'ai parfaitement compris) mais veut remettre de côté les difficultés liées à l'interprétation et la confrontation de la réalité (avec laquelle une simple recherche géométrique ne permet PAS de répondre correctement ou trouver les données qu'on s'attend à trouver). Le principe est donc à utiliser avec précaution, il peut ne pas être assez précis pour décrire correctement la réalité. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Le dimanche 11 novembre 2012 à 12:26 +0100, Fabien SK a écrit : Bonjour, J'ai remarqué que beaucoup de communes françaises n'avaient pas de lien Wikipedia (27915 / 32874 environ), et le rajouter à la main est fastidieux. J'ai pensé faire à peu près la même chose que je suis en train de faire avec les gares japonaises [1] (discussion sur la mailing list ja). Cela consisterait à: - récupérer le dump XML de Wikipedia France - créer une mini-base qui associe à un « code commune» (ref:INSEE dans OSM) le nom de la page Wikipédia - récupérer le dump récent OSM France - en extraire avec Osmosis les nœuds de type «place» ayant un «ref:INSEE» et pas de «wikipedia» - créer un script (ou un plug-in à Osmosis) qui va rajouter le ajouter le tag «wikipedia» et produire un fichier OSM (ou un jeu de fichiers OSM ayant un nombre de nœuds raisonnable). Ce script pourra éventuellement récupérer la dernière version des nodes depuis le serveur pour éviter un conflit dans JOSM. - mettre à jour avec JOSM (en utilisant un compte dédié), éventuellement de manière espacée dans le temps Qu'en pensez-vous? [1] http://wiki.openstreetmap.org/wiki/Mechanical_Edits/JaTrainWikipedia Fabien Je n'ai pas d'avis sur ta méthode, mais j'approuve l'automatisation de l'ajout d'un lien wikipedia sur les communes. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
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. Le 11 novembre 2012 12:26, Fabien SK fabie...@gmail.com a écrit : Bonjour, (...) - en extraire avec Osmosis les nœuds de type «place» ayant un «ref:INSEE» et pas de «wikipedia» - créer un script (ou un plug-in à Osmosis) qui va rajouter le ajouter le tag «wikipedia» et produire un fichier OSM (ou un jeu de fichiers OSM ayant un nombre de nœuds raisonnable). Ce script pourra éventuellement récupérer la dernière version des nodes depuis le serveur pour éviter un conflit dans JOSM. - mettre à jour avec JOSM (en utilisant un compte dédié), éventuellement de manière espacée dans le temps Qu'en pensez-vous? [1] http://wiki.openstreetmap.org/wiki/Mechanical_Edits/JaTrainWikipedia Fabien ___ 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
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Ok, je vais vérifier ce qu'il est est pour le tag Wikipedia des relations alors. Merci. Le 11/11/2012 14:55, Ab_fab 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. Le 11 novembre 2012 12:26, Fabien SK fabie...@gmail.com mailto:fabie...@gmail.com a écrit : Bonjour, (...) - en extraire avec Osmosis les noeuds de type «place» ayant un «ref:INSEE» et pas de «wikipedia» - créer un script (ou un plug-in à Osmosis) qui va rajouter le ajouter le tag «wikipedia» et produire un fichier OSM (ou un jeu de fichiers OSM ayant un nombre de noeuds raisonnable). Ce script pourra éventuellement récupérer la dernière version des nodes depuis le serveur pour éviter un conflit dans JOSM. - mettre à jour avec JOSM (en utilisant un compte dédié), éventuellement de manière espacée dans le temps Qu'en pensez-vous? [1] http://wiki.openstreetmap.org/wiki/Mechanical_Edits/JaTrainWikipedia Fabien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Et bien penser à mettre une URL Wikipedia humano-lisible, donc sans underscore ni caractères encodés, sous peine de subir les foudres d'Osmose ;-) Francescu Le 11 nov. 2012 15:41, Fabien SK fabie...@gmail.com a écrit : Ok, je vais vérifier ce qu'il est est pour le tag Wikipedia des relations alors. Merci. Le 11/11/2012 14:55, Ab_fab 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. Le 11 novembre 2012 12:26, Fabien SK fabie...@gmail.com a écrit : Bonjour, (...) - en extraire avec Osmosis les nœuds de type «place» ayant un «ref:INSEE» et pas de «wikipedia» - créer un script (ou un plug-in à Osmosis) qui va rajouter le ajouter le tag «wikipedia» et produire un fichier OSM (ou un jeu de fichiers OSM ayant un nombre de nœuds raisonnable). Ce script pourra éventuellement récupérer la dernière version des nodes depuis le serveur pour éviter un conflit dans JOSM. - mettre à jour avec JOSM (en utilisant un compte dédié), éventuellement de manière espacée dans le temps Qu'en pensez-vous? [1] http://wiki.openstreetmap.org/wiki/Mechanical_Edits/JaTrainWikipedia Fabien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Euh... oui, quand on a une relation mais quand elle n'existe pas, mettre le lien wikipedia sur le noeud place=* c'est un bon plan B, non ? 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. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Pourquoi pas. J'en profiterai pour voir quelles sont les communes qui n'ont pas de frontières administratives. Je me demande d'ailleurs si il y a des communes qui ne sont référencées ni par un noeud «place», ni par une relation. Je verrai bien ça... Actuellement il y a 1814 relations municipales avec un lien Wikipedia, et 29128 gui n'en n'ont pas. Le 11/11/2012 16:33, Christian Quest a écrit : Euh... oui, quand on a une relation mais quand elle n'existe pas, mettre le lien wikipedia sur le noeud place=* c'est un bon plan B, non ? Le 11 novembre 2012 14:55, Ab_fab gamma@gmail.com mailto: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
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Le dimanche 11 novembre 2012 13:35:54, Christophe Merlet a écrit : Le dimanche 11 novembre 2012 à 12:26 +0100, Fabien SK a écrit : Bonjour, J'ai remarqué que beaucoup de communes françaises n'avaient pas de lien Wikipedia (27915 / 32874 environ), et le rajouter à la main est fastidieux. J'ai pensé faire (...) Qu'en pensez-vous? Si la question est êtes vous d'accord si je le fais comme indiqué ?, je réponds oui pour l'idée, mais comme dit par d'autres, je préfère que ça soit fait sur la relation qui porte la commune et pas sur le noeud place. Si la relation n'existe pas, je préfère alors que rien ne soit fait. La raison étant que tôt ou tard les limites de communes y seront, que ça va faire une édition de masse incohérente en méthode En gardant à l'esprit que l'opération pourra être relancée plus tard. Si la question sous-entends un pensez-vous qu'il y a moyen de faire mieux parce que tu rencontres une difficulté pour le faire ou juste pour confronter à une autre idée, je proposerais plutôt la méthode suivante : - téléchargement des relations communes par xapi/overpass par pack de x (~50) - ajout du tag wikipedia si non présent et conditions requises présentes - ré-upload de la nouvelle version du pack de x histoire de limiter le temps pendant lequel on pourrait créer un conflit de + en cas de panne à l'aide d'un log tu peux reprendre là où tu en étais plus simplement il me semble. Idéalement identifier tes changesets : http://wiki.openstreetmap.org/wiki/Proposed_features/changeset_tags Je peux comprendre toutefois que cette variante ne soit pas nécessairement réaliste dans ton cas, mais me semble intéressante pour limiter le risque de conflit par rapport à : dump france en retard temps traitement upload long conflit bloquant avec JOSM -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
Le dimanche 11 novembre 2012 18:08:44, Fabien SK a écrit : Pourquoi pas. J'en profiterai pour voir quelles sont les communes qui n'ont pas de frontières administratives. Tu peux confronter/comparer avec cette liste : http://suivi.openstreetmap.fr/communes/communes.csv.txt (dispo en csv : http://suivi.openstreetmap.fr/communes/ ) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Automatisation des liens Wikipedia vers les communes
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
