Re: [OSM-talk-fr] relation boundary et noeud admin_centre
Il s'agit donc d'un cas particulier favorable... la généralité est inverse malheureusement à l'échelle de la planète. Le 3 octobre 2013 13:24, rainerU ra...@sfr.fr a écrit : Am 02.10.2013 22:35, schrieb Christian Quest: Le 2 octobre 2013 12:53, rainerU ra...@sfr.fr C'est parce que tu affiches le nom de la commune à la position de l'admin_centre. Je fais un rendu qui montre juste les limites administratives et les noms des communes. J'obtiens le meilleur résultat quand je positionne le nom par rapport au contour du polygone. Pour cela, il serait plus utile d'avoir population, name:xx etc. sur la relation. Et quand il n'y a pas de polygone... tu n'affiche plus de nom ? Ma carte ne couvre que le département 66 et toutes les polygones y existent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
Am 02.10.2013 22:35, schrieb Christian Quest: Le 2 octobre 2013 12:53, rainerU ra...@sfr.fr C'est parce que tu affiches le nom de la commune à la position de l'admin_centre. Je fais un rendu qui montre juste les limites administratives et les noms des communes. J'obtiens le meilleur résultat quand je positionne le nom par rapport au contour du polygone. Pour cela, il serait plus utile d'avoir population, name:xx etc. sur la relation. Et quand il n'y a pas de polygone... tu n'affiche plus de nom ? Ma carte ne couvre que le département 66 et toutes les polygones y existent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
Pas simple de répondre... surtout alors qu'on a 100% des nœuds place et 97% des boundary. D'un point de vue réutilisateur, actuellement la population sur les nœuds m'est bien utile pour le rendu, mais le tag wikipédia est plus utile sur la relation (quand elle existe). D'un point de vue modélisation, je serait tenter de tout mettre sur la relation... quand on les aura toutes, mais là aussi c'est pas si simple https://wiki.openstreetmap.org/wiki/Key:population ne fait référence qu'à place=*, pas aux boundary... Un autre point de vue à considérer c'est l'homogénéïté avec ce qui se fait hors de France. C'est en effet actuellement très compliqué d'utiliser ces données de façon systématique sur une base monde. Le principe même du ref:INSEE (ref:ISTAT en Italie, etc) est critiquable de ce point de vue car il faut connaitre chaque tag utilisé dans le pays. On devrait avoir un tag générique pour les découpages administratif/statistiques officiels des pays. On devrait aussi s'appuyer plus généralement sur les nomenclatures internationales officiells (comme l'ISO3166) ou officieuses (comme le FIPS américain), et pour l'Europe généraliser les ref:NUTS (Nomenclatures des Unités Territoriales Statistiques= nos ex-ZEAT, régions et départements) et ref:lau (Local Administrative Units = nos cantons et communes) Tout changement doit être discuté, car une info qui disparait ou se déplace a un impact pour les utilisateurs des données qu'il faut bien prendre en compte, anticiper, etc... Le 2 octobre 2013 09:32, rainerU ra...@sfr.fr a écrit : Bonjour, J'ai complété name:ca sur les noeuds place=* des communes du département 66 et je me demande s'il faut aussi le faire sur les relations des limites communales. Je constate que de manière générale les données relatives aux communes sont repartis de façon incohérente entre la relation boundary et le noeud place. On trouve certains informations (ref:INSEE, addr:postcode, population, wikipedia) sur les deux éléments et d'autres seulement sur un des deux. Comme les relations contiennent toutes le noeud place en tant que membre avec le rôle admin_centre, on peut remonter de la relation aux informations du noeud et vice-versa. D'un point de vue modèle de données il suffirait donc de stocker les informations sur un des deux éléments. Y-a-t-il un consensus ou une best practice sur ce sujet ? Sur le wiki et dans les listes je n'ai pas trouvé de réponse. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
2013/10/2 Christian Quest cqu...@openstreetmap.fr: D'un point de vue modélisation, je serait tenter de tout mettre sur la relation... quand on les aura toutes, mais là aussi c'est pas si simple https://wiki.openstreetmap.org/wiki/Key:population ne fait référence qu'à place=*, pas aux boundary... En principe, c'est vers ça qu'on devrait aller. Le traitement pour le rendu devrait pouvoir récupérer la population sur la relation lorsque le noeud place est admin_centre. je serait tenter de tout mettre sur la relation Sauf le tag name qui peut rester avec le noeud place. Une valeur spécifique de population pourrait faire sens lorsqu'il y a plusieurs noeuds place dans la commune (regroupement, hameaux) et qu'on veut indiquer la population des sous-groupes. Mais ces valeurs sont difficiles à obtenir et donc à vérifier. Dans tous les cas, la somme des populations des noeuds place ne devrait pas être supérieure à celle définie pour la commune elle-même dans la relation. Et s'il y a un seul noeud place, on peut la définir une seule fois et uniquement dans la relation (par cohérence). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
Le 2 octobre 2013 10:22, Pieren pier...@gmail.com a écrit : 2013/10/2 Christian Quest cqu...@openstreetmap.fr: D'un point de vue modélisation, je serait tenter de tout mettre sur la relation... quand on les aura toutes, mais là aussi c'est pas si simple https://wiki.openstreetmap.org/wiki/Key:population ne fait référence qu'à place=*, pas aux boundary... En principe, c'est vers ça qu'on devrait aller. Le traitement pour le rendu devrait pouvoir récupérer la population sur la relation lorsque le noeud place est admin_centre. ça ? c'est à dire rester sur le principe du wiki et garder population=* sur le place=* ? Je doute qu'on puisse agir globalement (monde) car une grande majorité de place=* n'ont actuellement pas de boundary. Vu par notre petit bout de la lorgnette hexagonale, ça semble bizarre, mais il suffit de regarder de nombreuses zones de la planète pour en faire le constat. Il faut rester sur des solutions simples adaptées à ces différents niveaux de mapping. Pas simple ! -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
2013/10/2 Christian Quest cqu...@openstreetmap.fr: ça ? c'est à dire rester sur le principe du wiki et garder population=* sur le place=* ? non, le ça fesait référence à ton je serait tenter de tout mettre sur la relation. Le wiki, on peut le changer. Je doute qu'on puisse agir globalement (monde) car une grande majorité de place=* n'ont actuellement pas de boundary. C'est vrai, il faut tenir compte de ça lorsque tu fais un rendu de carte mondiale. On peut concilier les deux: Du point de vue de notre modélisation en France: - migrer la population du noeud place vers la relation. (Ca n'est pas urgent et ça peut atttendre que les relations communales soient au complet) Du point de vue de celui qui créer des cartes (consommateur de données): - chercher population sur le noeud place en 1er - s'il n'y a pas de population, voir si le noeud place est admin_centre et chercher la population dans la relation - si non, considérer que l'info population manque. Il faut rester sur des solutions simples adaptées à ces différents niveaux de mapping. Pas simple ! J'espère que ce que je propose soit assez simple à implémenter. Reste un point délicat : le noeud place peut être admin_centre de plusieurs relations administratives et chacune d'entre-elles peut contenir un tag population (celui de la commune, celui de la préfecture, celui du département, etc). Laquelle choisir dans ce cas ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
Am 02.10.2013 09:47, schrieb Christian Quest: D'un point de vue réutilisateur, actuellement la population sur les nœuds m'est bien utile pour le rendu, mais le tag wikipédia est plus utile sur la relation (quand elle existe). C'est parce que tu affiches le nom de la commune à la position de l'admin_centre. Je fais un rendu qui montre juste les limites administratives et les noms des communes. J'obtiens le meilleur résultat quand je positionne le nom par rapport au contour du polygone. Pour cela, il serait plus utile d'avoir population, name:xx etc. sur la relation. Tout changement doit être discuté, car une info qui disparait ou se déplace a un impact pour les utilisateurs des données qu'il faut bien prendre en compte, anticiper, etc... Ça va de soi. Je me demandais juste s'il fallait ajouter les infos sur les deux objets, et si non, sur lequel. Il faut penser utile. Il doit avoir pas mal d'outils et de rendus qui utilisent uniquement les attributs l'admin_centre (ou pire: les deux comme le rendu standard qui affiche deux foix le nom des communes). Pour l'instant je fais donc tous les ajouts sur l'admin centre. Et pour éviter les redondances je n'ajoute rien aux boundaries. Pour mon rendu des limites communales je me débrouille avec SQL pour récupérer les infos qu'il me faut sur le noeud. Au fond c'est le même problème qui se pose pour les attributs des multipolygones et leurs chemins outer [1] ou le modèle pyramidal des limites administratives [2] : comment migrer d'un schéma de tagging à un autre. [1]https://lists.openstreetmap.org/pipermail/talk/2013-September/068189.html [2]https://lists.openstreetmap.org/pipermail/talk-fr/2013-September/062867.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
Le 2 oct. 2013 à 10:48, Christian Quest cqu...@openstreetmap.fr a écrit : ça ? c'est à dire rester sur le principe du wiki et garder population=* sur le place=* ? Je doute qu'on puisse agir globalement (monde) car une grande majorité de place=* n'ont actuellement pas de boundary. Vu par notre petit bout de la lorgnette hexagonale, ça semble bizarre, mais il suffit de regarder de nombreuses zones de la planète pour en faire le constat. J'ai du mal à relier systématiquement place avec une surface et donc des limites. C'est indiscutable pour city et town, ce ne l'est plus pour les villages , car, il peut y avoir beaucoup de villages dans une seule commune, et si des communes avec un seul village fusionnent, le village reste. Pour les hamlet et les isolated dwelling, les référer à des limites administratives relève de la mission impossible. La lorgnette hexagonale serait de supposer que tout est dirigé et régenté par l'administration et que ce qui n'est pas dans son viseur n'existe pas. Ne pas oublier nom plus que l'émièttement communal est une anomalie française et qu'ailleurs on peut avoir plusieurs villes et villages dans un seul district. En réalité, au niveau infra-communal, on est dans la logique floue, dans l'évolution du vivant, la reconfiguration lente de tous les espaces qui sont, d'abord et avant tout, mentaux. Pire, les habitants d'un même quartier urbain ou rural peuvent avoir des divergences sur les limites virtuelles, voire même sur la légitimité d'utiliser tel ou tel toponyme. Certaines communes peuvent utiliser une grille de découpage, mais, cela reste un outil de travail et non une réalité dont les habitants doivent tenir compte. Finalement, il n' y a pas de formule magique pour réunir deux ordres de grandeur différents : la démographie qui est reliée à des découpages artificiels et la géographie de l'humain qui est bien plus indécise et évolutive. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
Le 2 octobre 2013 12:53, rainerU ra...@sfr.fr a écrit : Am 02.10.2013 09:47, schrieb Christian Quest: D'un point de vue réutilisateur, actuellement la population sur les nœuds m'est bien utile pour le rendu, mais le tag wikipédia est plus utile sur la relation (quand elle existe). C'est parce que tu affiches le nom de la commune à la position de l'admin_centre. Je fais un rendu qui montre juste les limites administratives et les noms des communes. J'obtiens le meilleur résultat quand je positionne le nom par rapport au contour du polygone. Pour cela, il serait plus utile d'avoir population, name:xx etc. sur la relation. Et quand il n'y a pas de polygone... tu n'affiche plus de nom ? Tout changement doit être discuté, car une info qui disparait ou se déplace a un impact pour les utilisateurs des données qu'il faut bien prendre en compte, anticiper, etc... Ça va de soi. Je me demandais juste s'il fallait ajouter les infos sur les deux objets, et si non, sur lequel. Il faut penser utile. Il doit avoir pas mal d'outils et de rendus qui utilisent uniquement les attributs l'admin_centre (ou pire: les deux comme le rendu standard qui affiche deux foix le nom des communes). Pour l'instant je fais donc tous les ajouts sur l'admin centre. Et pour éviter les redondances je n'ajoute rien aux boundaries. A mon avis la majorité des rendus utilisent les nœuds place=* et n'ont aucune idée de leur éventuel rôle admin_centre dans la relation boundary. Il n'y a que des fadas comme moi pour aller bricoler avec les tables de slim et retrouver les liens entre le nœud et la relation (ça me sert à n'afficher le nom qu'une fois). Une fois passées dans osm2pgsql beaucoup de construction très belles sur le papier basées sur des relations ne sont plus accessibles. Il faut se frotter à la réutilisation pour bien saisir les enjeux. Bien sûr le fonctionnement d'osm2pgsql n'est pas non plus un dogme et ne doit pas trop influencer les modèles de tags, mais il faut quand même ne pas ignorer ces réutilisations relativement fréquentes. Pour mon rendu des limites communales je me débrouille avec SQL pour récupérer les infos qu'il me faut sur le noeud. Au fond c'est le même problème qui se pose pour les attributs des multipolygones et leurs chemins outer [1] ou le modèle pyramidal des limites administratives [2] : comment migrer d'un schéma de tagging à un autre. [1] https://lists.openstreetmap.org/pipermail/talk/2013-September/068189.html [2] https://lists.openstreetmap.org/pipermail/talk-fr/2013-September/062867.html Soit on ne migre pas et on reste sur le principe initial (population sur nœud place=*), soit on a des infos en double ou un modèle bien plus complet et qui peut être paralèlle (oui, avec le risque de redondance et d'incohérence). On a parlé aujourd'hui (à SIG2013) des différentes valeurs de population, double-compte ou pas, etc. Laquelle mettre ? Pourquoi pas toutes ? Bref, ça vaut peut être un modèle de tag plus complet à mettre sur les relations pour décrire de façon moins approximative la population vivant à l'intérieur d'une zone géographique clairement délimitée. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relation boundary et noeud admin_centre
Le 2 octobre 2013 12:53, rainerU ra...@sfr.fr a écrit : Il faut penser utile. Il doit avoir pas mal d'outils et de rendus qui utilisent uniquement les attributs l'admin_centre (ou pire: les deux comme le rendu standard qui affiche deux foix le nom des communes). Pour l'instant je fais donc tous les ajouts sur l'admin centre. Et pour éviter les redondances je n'ajoute rien aux boundaries. Le gros ennui c'est que les noeuds place existent qui sont des admin_center pour des relations de niveau différents et pas toujours d'ailleurs le niveau 8. De fait on ne sait pas du tout sur quelle surface (relation) porte les chiffres de la relation. L'Espagne utilise une solution simple: - c'est de mettre admin_level=n sur le noeud place pour savoir ce qu'il sert à désigner. Ca permet de sélectionner la bonne relation quand il y en a plusieurs. Si en France un noeud place n'est pas nommé pour représenter le centre de la commune avec la population totale de la commune, il ne faut pas y mettre admin_level=8 (on pourrait avoir admin_level=9 ou 10, mais en cas d'absence on ne sait pas quoi faire). - A ne pas confondre avec capital=n qui précise aussi un admin_level mais celui ayant la plus petite valeur parmi les relations qui existent (ou pourraient exister si elles sont tracées). On a aussi capital=yes équivalent à capital=2. Cette solution admin_level=n sur le noeud place permet de faire la liaison : les données entre la relation et le noeud ne DOIVENT PAS alors être contradictoires entre elles (cas de la population ou de la référence INSEE ou ISTAT etc... de la commune). Mais pourtant cela ne s'applique PAS au code postal car les zones postales ne correspondent pas aux zones adminsitratives : un noeud place pourra préciser un code postal unique alors que la relation en aura plusieurs (voire même pas celui du noeud place qui peut avoir un cedex par exemple !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
