Re: [OSM-talk-fr] Notice à suivre pour les imports
Bonjour à tous, Les guideslines sur les imports (http://wiki.openstreetmap.org/wiki/Import/Guidelines ) vont plus loin en préconisant de ne pas utiliser le tag source pour mentionner l'origine des données. - Use a dedicated user account Create a new user for the import. You must not use your standard OSM user account. The user page for the account should be used to collate data relating to the source and contact details for the import. Furthermore, it means that attribution can often be carried in the account's display name, or in the account's user page, which is better than putting it as a tag, as the user's editing history is a permanent record of the source and doesn't interfere with tags or increase the size of the database as much. For these reasons, creating a dedicated user account is preferable to using a source http://wiki.openstreetmap.org/wiki/Key:source=* tag. - Ce choix est motivé par : - l'usage du compte OSM créé pour l'import afin de donner des informations sur la source, les outils, le lien vers une page du wiki. Le nom même du compte peut indiquer la source. - la permanence de l'enregistrement des modifications effectuées à l'aide du compte d'import. - le souci de ne pas charger la base de données de la carte OSM sachant que l'historique des modifications est à part Pour connaitre la source d'un objet, il faut consulter l'historique des modifications et repérer le compte qui a créé l'objet. Cela me laisse perplexe sur la visibilité qu'OSM veut donner à ses sources. Autant citer la liste de tous les organismes ayant fourni des données dans les conditions générales d'utilisation d'OSM ou dans une page Remerciements du wiki. En tant que contributeur, le tag source me parait une indication utile sur la qualité d'un objet. Si je constate une anomalie, je peux contacter la source (cf les monuments historiques mal localisés) ou l'auteur de l'import. Le mouvement Opendata amorcé en France va générer des imports de données. Il me parait important que la communauté OSM s'accorde sur des règles et pratiques pour ces projets d'import. Librement Christophe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Pour que ce soit cohérent, il faudrait alors un seul compte utilisateur par source, et seul ce compte pourrait importer des données. Est-ce à dire qu'on ne peut plus importer de données venant du cadastre par exemple, et seulement compter sur les administrations pour qu'elles procèdent elles-mêmes aux imports ? Jusqu'à présent, elles ne peuvent pas le faire car elles ne sont pas financées pour le faire. La règle énoncée me semble totalement anticollaborative. Mentionner la source est une bonne chose. En attendant, cela veut dire que si quelqu'un importe une source, il doit utiliser un compte utilisateur séparé pour chaque source ? Et s'abstenir totalement de fusionner d'autres données ou dédoublonner les données importées avec les données existantes, à charge ensuite pour lui d'utiliser un autre compte pour faire le nettoyage ? Le risque est alors de trouver dans la base des quantités énormes de doublons, incohérents entre eux. Il y a pourtant un autre outil pour le suivi : les groupes de modification, qui sont conservés aussi dans les historiques et peuvent mentionner la source utilisée. Utiliser plusieurs comptes ne peut qu'apporter des tonnes de problèmes, par l'impossibilité de fusionner les données en doublon (et la base contiendra bien plus de pollution que les chaines du tag source=* !!!). Il suffit d'indiquer la source dans le commentaire du groupe de modification. Plusieurs comptes c'est inutile, et le risque d'utiliser le mauvais compte pour certaines modifs est grand (d'autant qu'il n'est pas aisé de le faire dans les éditeurs actuels). Cette règle est ridicule, contre-productive, anti-collaborative, et produira bien plus d'effets indésirables ! Je milite plutôt pour les commentaires des groupes de modification, si on veut arrêter d'utiliser les tag source=*. Le 28 avril 2012 12:41, isnogoud os...@free.fr a écrit : Use a dedicated user account Create a new user for the import. You must not use your standard OSM user account. The user page for the account should be used to collate data relating to the source and contact details for the import. Furthermore, it means that attribution can often be carried in the account's display name, or in the account's user page, which is better than putting it as a tag, as the user's editing history is a permanent record of the source and doesn't interfere with tags or increase the size of the database as much. For these reasons, creating a dedicated user account is preferable to using a source=* tag. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[forum-osm-fr]cr�ation de trace GPS
Le message suivant de Sleyb: ## bonjour je cherche un site ou un soft avec le quel je pourrai faire des traces GPX avec le fond de carte openstreeet.. es ce quelqu'un aurai ça sous la main merci a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=3 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose erreur de validation no translation
Le 25 avril 2012, Fabien a écrit : Bonjour, En essayant de corriger les erreurs osmose dans Marseille je suis tombé sur ce point [1]. II annonce un problème de traduction mais ne correspond à aucun noeud réel dans la base OSM. J'ai regardé les bâtiments autour mais je ne vois pas à quoi cela peut être lié. Quelqu'un a une idée ? C'est un petit souci dans le frontend d'osmose. Si ton navigateur est configuré en anglais par défaut (ou du moins, plus important que le français) et que l'analyse ne retourne pas de traduction anglaise pour le sous-titre d'une erreur, alors le frontend met no translation dans la version en anglais. Si ton navigateur a le français par défaut, ça devrait afficher correctement la version en français. J'ai corrigé le frontend pour qu'il prenne un des sous-titres fournis par l'analyse pour la version anglaise: tu ne devrais plus avoir ce problème maintenant :) -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Bonjour, je suis assez d'accord avec Pieren avec nuance sur je tag source qui facilite l'appréciation des données lors du mapping. De plus on est si nombreux à utiliser des données via import, parfois partiels et en tous cas toujours retouchés qu'un compte dédié n'a de sens que pour des cas particuliers. Mes 0.02€ Le 28/04/12, Philippe Verdyverd...@wanadoo.fr a écrit : Pour que ce soit cohérent, il faudrait alors un seul compte utilisateur par source, et seul ce compte pourrait importer des données. Est-ce à dire qu'on ne peut plus importer de données venant du cadastre par exemple, et seulement compter sur les administrations pour qu'elles procèdent elles-mêmes aux imports ? Jusqu'à présent, elles ne peuvent pas le faire car elles ne sont pas financées pour le faire. La règle énoncée me semble totalement anticollaborative. Mentionner la source est une bonne chose. En attendant, cela veut dire que si quelqu'un importe une source, il doit utiliser un compte utilisateur séparé pour chaque source ? Et s'abstenir totalement de fusionner d'autres données ou dédoublonner les données importées avec les données existantes, à charge ensuite pour lui d'utiliser un autre compte pour faire le nettoyage ? Le risque est alors de trouver dans la base des quantités énormes de doublons, incohérents entre eux. Il y a pourtant un autre outil pour le suivi : les groupes de modification, qui sont conservés aussi dans les historiques et peuvent mentionner la source utilisée. Utiliser plusieurs comptes ne peut qu'apporter des tonnes de problèmes, par l'impossibilité de fusionner les données en doublon (et la base contiendra bien plus de pollution que les chaines du tag source=* !!!). Il suffit d'indiquer la source dans le commentaire du groupe de modification. Plusieurs comptes c'est inutile, et le risque d'utiliser le mauvais compte pour certaines modifs est grand (d'autant qu'il n'est pas aisé de le faire dans les éditeurs actuels). Cette règle est ridicule, contre-productive, anti-collaborative, et produira bien plus d'effets indésirables ! Je milite plutôt pour les commentaires des groupes de modification, si on veut arrêter d'utiliser les tag source=*. Le 28 avril 2012 12:41, isnogoud os...@free.fr a écrit : Use a dedicated user account Create a new user for the import. You must not use your standard OSM user account. The user page for the account should be used to collate data relating to the source and contact details for the import. Furthermore, it means that attribution can often be carried in the account's display name, or in the account's user page, which is better than putting it as a tag, as the user's editing history is a permanent record of the source and doesn't interfere with tags or increase the size of the database as much. For these reasons, creating a dedicated user account is preferable to using a source=* tag. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Envoyé avec mon mobile Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, avec cquest, on a eus une discussion sur IRC avec pnorman justement. On ne peut pas dire que ça a été une discussion super plaisante mais Christian me corrigera, voila les grandes lignes: Import de sa ville locale fait correctement bien nettoyé en utilisant les connaissances locales, pas de compte particulier Serial importer de villes, compte particulier pour l'import des villes par personne. Je ne suis pas convaincue par certains des arguments avances mais on va essayer de jouer le jeu un minimum :) La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Donc je pense qu'en faisant attention la dessus ça devrait passer. Toutefois, comme il a ete fait avec Corine, des que l'on fait un import massif, il faut vraiment créer un compte particulier pour ça. Emilie Laffray On 27/04/2012 06:47, Fabien wrote: pnornam D'ailleurs il m'a répondu en demandant de mettre à jour le wiki. J'attends quand même des avis ici plus nombreux. Fabien//lists.openstreetmap.org/listinfo/talk-fr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+b7psACgkQ7H1ne0ugLJnX5wCfWejlBFlGJmuLBHPZJOIeHxPF uEIAn21QM4rqfg4fJJ/muTcDRYMQ2oW1 =jokW -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Pour les serial importer... pnormal va me fournir les comptes qu'il a repérer. Je contacterai les contributeurs en questions afin de leur rappeler qu'il y a du travail à faire sur chaque import de cadastre: - fusionner avec l'existant: bâtiments et POI - s'assurer que la voirie est cohérente et qu'elle ne coupe pas les bâtiments qu'on ajoute La qualité doit passer avant la quantité. Le 28 avril 2012 15:20, Emilie Laffray emilie.laff...@gmail.com a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, avec cquest, on a eus une discussion sur IRC avec pnorman justement. On ne peut pas dire que ça a été une discussion super plaisante mais Christian me corrigera, voila les grandes lignes: Import de sa ville locale fait correctement bien nettoyé en utilisant les connaissances locales, pas de compte particulier Serial importer de villes, compte particulier pour l'import des villes par personne. Je ne suis pas convaincue par certains des arguments avances mais on va essayer de jouer le jeu un minimum :) La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Donc je pense qu'en faisant attention la dessus ça devrait passer. Toutefois, comme il a ete fait avec Corine, des que l'on fait un import massif, il faut vraiment créer un compte particulier pour ça. Emilie Laffray On 27/04/2012 06:47, Fabien wrote: pnornam D'ailleurs il m'a répondu en demandant de mettre à jour le wiki. J'attends quand même des avis ici plus nombreux. Fabien//lists.openstreetmap.org/listinfo/talk-fr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+b7psACgkQ7H1ne0ugLJnX5wCfWejlBFlGJmuLBHPZJOIeHxPF uEIAn21QM4rqfg4fJJ/muTcDRYMQ2oW1 =jokW -END PGP SIGNATURE- ___ 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] Notice à suivre pour les imports
Le 28 avril 2012 15:20, Emilie Laffray emilie.laff...@gmail.com a écrit : La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Est-ce lié au fait que j'ai corrigé des problèmes de géométrie un peu partout sur les frontières espagnoles ? Ce n'était pas des imports massifs, mais bien des corrections manuelles basées sur les données existantes. Pour que la carte affchée sur Layers s'affiche correctement dans tous les niveaux (c'est presque fini, sauf les municipalité en Aragon dont certaines ont plusieurs relations, chacune contenant une partie des frontières pour la même municipalité, ce que ni Osmose, ni Layers ne détectent), et les divers problèmes relevés sur Osmose (problèmes de rôles, problèmes de ways en doublons, communes non correctement fermées, et corrections demandées surt les frontières côtières pour lesquelles j'ai remplacé les frontières maritimes par les lignes côtières sur tous les niveaux sauf le niveau 2), plus des corrections mineures sur Bing. Une des communes espagnoles a un tracé assez bizarre que je n'arrive pas à faire valider dans l'état, la majeure partie de sa surface est constituée de municipalités quasi-jointives (sauf une petite bande de séparation de parfois moins de 10 mètres), ce qui donne à cette commune englobante l'allure d'un patchwork. J'ai fait tous les niveaux 4,5,6,7,8, et quelques niveaux 9 (je laisse de côté le niveau 10 qui n'est qu'à l'ébauche). De plus j'ai ajouté quelques comarques (niveau 7) J'ai fini les Canaries, il me reste quelques communes côtières près de Barcelone et Valencienne, et les communes des Baléares. Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Cantons administratifs
Je vois que certains ont commencé à cartographier les cantons français. Par exemple : le canton de Nant, relation 2099822 (wikipedia:fr:Canton de Nant). Cependant je note que le type de subdicision est marqué comme boundary=political_division, alors que les cantons restent encore des niveaux administratifs (qui servent souvent de base pour un bon nombre de communautés de communes). Il me semble qu'il y a confusion avec les cantons électoraux (qui sont différents, et qui sont marqués normalement boundary=electoral). Les cantons administratifs (contrairement aux cantons électoraux) sont des subdivisions exactes intermédiaires entre les arrondissements départementaux (niveau 7) et les communes (niveau 8), ce qui veut dire qu'ils contiennent des communes entières. Bien que ces cantons (administratifs, comme électoraux) ne sont pas des collectivités locales (contrairement aux communes, EPCI, départements et régions), ce critère n'est pas discriminant puisque les arrondissements départementaux (niveau 7) et arrondissements municipaux (niveau 9) n'en sont pas non plus. Cela ne devrait pas gêner leur typologie en tant que subdivision administrative de tous les cantons administratifs. Idéalement ce devrait être de type boundary=administrative, mais il faut un numéro entre 7 et 8 pour admin_level : on devrait utiliser admin_level=7.5 ? Est-ce que le tag admin_level=* est restreint à une valeur entière ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Bonjour, Le 28/04/2012 17:35, Philippe Verdy a écrit : Je vois que certains ont commencé à cartographier les cantons français. Par exemple : le canton de Nant, relation 2099822 (wikipedia:fr:Canton de Nant). Cependant je note que le type de subdicision est marqué comme boundary=political_division, alors que les cantons restent encore des niveaux administratifs (qui servent souvent de base pour un bon nombre de communautés de communes). Il me semble qu'il y a confusion avec les cantons électoraux (qui sont différents, et qui sont marqués normalement boundary=electoral). Que ce soit côté INSEE [1] ou Wikipedia [2], je vois surtout le canton évoqué comme subdivision à vocation électorale : le canton comme territoire d'élection d'un conseiller général. Si tu as des références à fournir, elles sont bienvenues. Les cantons administratifs (contrairement aux cantons électoraux) sont des subdivisions exactes intermédiaires entre les arrondissements départementaux (niveau 7) et les communes (niveau 8), ce qui veut dire qu'ils contiennent des communes entières. Ce que tu dis me fait plutôt penser aux pseudo-cantons de l'INSEE, à vocation statistique, et pour lesquels le découpage s'arrange pour que chaque commune soit inscrite dans un et un seul pseudo-canton : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton-ou-ville.htm Bien que ces cantons (administratifs, comme électoraux) ne sont pas des collectivités locales (contrairement aux communes, EPCI, départements et régions), ce critère n'est pas discriminant puisque les arrondissements départementaux (niveau 7) et arrondissements municipaux (niveau 9) n'en sont pas non plus. Cela ne devrait pas gêner leur typologie en tant que subdivision administrative de tous les cantons administratifs. Idéalement ce devrait être de type boundary=administrative, mais il faut un numéro entre 7 et 8 pour admin_level : on devrait utiliser admin_level=7.5 ? Est-ce que le tag admin_level=* est restreint à une valeur entière ? C'est en effet l'usage d'utiliser des valeurs entières pour le tag admin_level. Le principe dérape parfois un peu : http://taginfo.openstreetmap.org/keys/admin_level#values Au moment où, dans OSM, le niveau admin_level=7 a été attribué aux arrondissements départementaux [3], les niveaux 6 (département) et 8 (communes) étaient largement établis et non discutés. Le canton n'a pas été considéré comme concurrent pour ce niveau, vu sous l'angle de circonscription électorale (plus qu'administrative), car placé tantôt au dessus des communes (en zone rurale), tantôt en dessous ou à cheval (en urbain), ce qui rend sa place dans une pyramide comme celle des étages d'admin_level hasardeuse : 7 ? 8 ? 8 bis ? 9 ? Le choix de boundary=political, qui pré-existait sur le wiki [4], s'est fait dans ce contexte. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton.htm [2] : http://fr.wikipedia.org/wiki/Administration_territoriale_de_la_France#4_055_cantons [3] : http://lists.openstreetmap.org/pipermail/talk-fr/2011-June/033514.html [4] : http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Le 28/04/2012 17:02, Philippe Verdy a écrit : Le 28 avril 2012 15:20, Emilie Laffrayemilie.laff...@gmail.com a écrit : La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. (...) Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? Si ce que tu dis ci-dessus est vrai, alors le rapport avec les imports qu'évoque Emilie est assez lointain... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Dans ce cas, si ce qui est mappé sont les cantons électoraux, ce n'est pas une subdivision politique non plus. Donc ce devrait être boundary=electoral et non boundary=political_division. Il n'y a pas de subdivision politique en France qui ne soit pas administrative. Les cantons électoraux sont plutôt appelés aujourd'hui circonscriptions électorales. L'Insee fait un regroupement des communes en cantons entiers, quitte à y inclure ce qu'il appelle des fractions cantonales pour les communes couvertes par plusieurs cantons. Ils n'ont rien de statistiques puisqu'ils continuent à avoir un rôle administratif pour les services de l'Etat ne dépendant pas des collectivités locales (essentiellement la police et la gendarmerie, l'administration fiscale, puisque concernant l'éducation ce sont les académies qui se subdivisent selon les régions, départements et communes, les communes pouvant définir des zones aussi pour l'enseignement public de la carte scolaire, ou d'autres regroupements intercommunaux maintenant aussi au sein de leur EPCI). L'outil statistique c'est la fraction cantonale, pas le canton qui reste un niveau administratif (de l'Etat et non des collectivités locales). Le 28 avril 2012 18:19, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, Le 28/04/2012 17:35, Philippe Verdy a écrit : Je vois que certains ont commencé à cartographier les cantons français. Par exemple : le canton de Nant, relation 2099822 (wikipedia:fr:Canton de Nant). Cependant je note que le type de subdicision est marqué comme boundary=political_division, alors que les cantons restent encore des niveaux administratifs (qui servent souvent de base pour un bon nombre de communautés de communes). Il me semble qu'il y a confusion avec les cantons électoraux (qui sont différents, et qui sont marqués normalement boundary=electoral). Que ce soit côté INSEE [1] ou Wikipedia [2], je vois surtout le canton évoqué comme subdivision à vocation électorale : le canton comme territoire d'élection d'un conseiller général. Si tu as des références à fournir, elles sont bienvenues. Les cantons administratifs (contrairement aux cantons électoraux) sont des subdivisions exactes intermédiaires entre les arrondissements départementaux (niveau 7) et les communes (niveau 8), ce qui veut dire qu'ils contiennent des communes entières. Ce que tu dis me fait plutôt penser aux pseudo-cantons de l'INSEE, à vocation statistique, et pour lesquels le découpage s'arrange pour que chaque commune soit inscrite dans un et un seul pseudo-canton : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton-ou-ville.htm Bien que ces cantons (administratifs, comme électoraux) ne sont pas des collectivités locales (contrairement aux communes, EPCI, départements et régions), ce critère n'est pas discriminant puisque les arrondissements départementaux (niveau 7) et arrondissements municipaux (niveau 9) n'en sont pas non plus. Cela ne devrait pas gêner leur typologie en tant que subdivision administrative de tous les cantons administratifs. Idéalement ce devrait être de type boundary=administrative, mais il faut un numéro entre 7 et 8 pour admin_level : on devrait utiliser admin_level=7.5 ? Est-ce que le tag admin_level=* est restreint à une valeur entière ? C'est en effet l'usage d'utiliser des valeurs entières pour le tag admin_level. Le principe dérape parfois un peu : http://taginfo.openstreetmap.org/keys/admin_level#values Au moment où, dans OSM, le niveau admin_level=7 a été attribué aux arrondissements départementaux [3], les niveaux 6 (département) et 8 (communes) étaient largement établis et non discutés. Le canton n'a pas été considéré comme concurrent pour ce niveau, vu sous l'angle de circonscription électorale (plus qu'administrative), car placé tantôt au dessus des communes (en zone rurale), tantôt en dessous ou à cheval (en urbain), ce qui rend sa place dans une pyramide comme celle des étages d'admin_level hasardeuse : 7 ? 8 ? 8 bis ? 9 ? Le choix de boundary=political, qui pré-existait sur le wiki [4], s'est fait dans ce contexte. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/canton.htm [2] : http://fr.wikipedia.org/wiki/Administration_territoriale_de_la_France#4_055_cantons [3] : http://lists.openstreetmap.org/pipermail/talk-fr/2011-June/033514.html [4] : http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical ___ 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] Notice à suivre pour les imports
Le 28 avril 2012 18:23, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 28/04/2012 17:02, Philippe Verdy a écrit : Le 28 avril 2012 15:20, Emilie Laffrayemilie.laff...@gmail.com a écrit La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? Si ce que tu dis ci-dessus est vrai, alors le rapport avec les imports qu'évoque Emilie est assez lointain... D'abord ce que je dis est vrai, je ne vois pas pourquoi tu voudrais en doûter... Non, je ne réagissait pas au message reçu par Emilie, mais à l'évocation des imports massifs de multipolygones, pour des multipolygones que j'ai créés pour résoudre des problèmes de géométrie en Espagne, ou en fusionnant des ways, et les multipolygones ajoutés ou complétés pour les communes espagnoles qui n'étaient définies que par les ways. J'ai fait ces modifs sur une période de plusieurs semaines, petit à petit, avec plein de recherches sur les données de l'INE pour vérifier le tout, et en localisant des centres adminsitratifs, et vérifiant les liens Wikipédia au besoin, et en cas de problème locaux sur certains points sur l'imagerie Bing, ou on prolongeant les frontières mal connectées entre elles (quand l'écart n'était que de quelques mètres, essentiellement sur la côte, ou pour redessiner des côtes très grossières, ou pour réordonner des traits comme des routes côitères, forêts, et autres landuse qui sortaient des terres. Tout cela manuellement, sans import massif ni aucun bot, patiemment à la souris, et en consultant Osmose et Layers pour vérifier que tout restait cohérent, ou lever des ambiguités (afin de ne modifier le moins possible le rendu Mapnik et conserver tous les détails). Et lors des commits, j'ai toujours pris soin d'annuler toute modif en cours en cas de conflit (en repreant ce qui est dans la base pour refaire la modification, histoire de n'oublier aucune modif plus récente depuis le téléchargement. Ca veut dire aussi que j'ai patiemment téléchargé sur plusieurs semaines des millions de points, noeuds et relations (souvent plusieurs fois à cause des conflits). Ca m'a pris un temps fou. J'ai mis les commentaires différents selon les cas. C'est très visible que ce n'était pas un travail de robot (y compris parfois des modifs en plusieurs étapes pour vérifier des étapes intermédiaires pour pouvoir les annuler facilement en cas de pépin, et en regardant le rendu Mapnik ou Mapquest, et revérfiant chaque fois avec Osmose et Layers, l'analyseur de relations, et OSM Inspector... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Philippe, Je peux me tromper car je ne connais pas bien le contexte, mais je crois qu'Emilie parle d'import de bâtiments, et toi des limites administratives. Le 28 avril 2012 18:48, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 avril 2012 18:23, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 28/04/2012 17:02, Philippe Verdy a écrit : Le 28 avril 2012 15:20, Emilie Laffrayemilie.laff...@gmail.com a écrit La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? Si ce que tu dis ci-dessus est vrai, alors le rapport avec les imports qu'évoque Emilie est assez lointain... D'abord ce que je dis est vrai, je ne vois pas pourquoi tu voudrais en doûter... Non, je ne réagissait pas au message reçu par Emilie, mais à l'évocation des imports massifs de multipolygones, pour des multipolygones que j'ai créés pour résoudre des problèmes de géométrie en Espagne, ou en fusionnant des ways, et les multipolygones ajoutés ou complétés pour les communes espagnoles qui n'étaient définies que par les ways. J'ai fait ces modifs sur une période de plusieurs semaines, petit à petit, avec plein de recherches sur les données de l'INE pour vérifier le tout, et en localisant des centres adminsitratifs, et vérifiant les liens Wikipédia au besoin, et en cas de problème locaux sur certains points sur l'imagerie Bing, ou on prolongeant les frontières mal connectées entre elles (quand l'écart n'était que de quelques mètres, essentiellement sur la côte, ou pour redessiner des côtes très grossières, ou pour réordonner des traits comme des routes côitères, forêts, et autres landuse qui sortaient des terres. Tout cela manuellement, sans import massif ni aucun bot, patiemment à la souris, et en consultant Osmose et Layers pour vérifier que tout restait cohérent, ou lever des ambiguités (afin de ne modifier le moins possible le rendu Mapnik et conserver tous les détails). Et lors des commits, j'ai toujours pris soin d'annuler toute modif en cours en cas de conflit (en repreant ce qui est dans la base pour refaire la modification, histoire de n'oublier aucune modif plus récente depuis le téléchargement. Ca veut dire aussi que j'ai patiemment téléchargé sur plusieurs semaines des millions de points, noeuds et relations (souvent plusieurs fois à cause des conflits). Ca m'a pris un temps fou. J'ai mis les commentaires différents selon les cas. C'est très visible que ce n'était pas un travail de robot (y compris parfois des modifs en plusieurs étapes pour vérifier des étapes intermédiaires pour pouvoir les annuler facilement en cas de pépin, et en regardant le rendu Mapnik ou Mapquest, et revérfiant chaque fois avec Osmose et Layers, l'analyseur de relations, et OSM Inspector... ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Le 28/04/2012 18:37, Philippe Verdy a écrit : Dans ce cas, si ce qui est mappé sont les cantons électoraux, ce n'est pas une subdivision politique non plus. Donc ce devrait être boundary=electoral et non boundary=political_division. Le tableau n'ayant pas trop changé depuis, tu peux aussi voir le fil qui commence ici : http://lists.openstreetmap.org/pipermail/talk-fr/2011-October/036546.html qui traite du sujet. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Effectivement, mais dans de nombreux cas, mes modifs concernaient aussi les côtes, les landuse=* (ports, forets en distinguant bien les forêts de feuillus, conifères et mixtes, prairies, vignobles, zones résidentielles), y compris la récupération des fragments CORINE quant ils rendaient la carte illisible et ajoutaient des tas de points inutiles (ne correspondant à rien sur des zones jointives ayant exactement les mêmes attributs, cas fréquent sur les forêts que j'ai pu récupérer en grand nombre quand leur géométrie était totalement cassée) et des zones naturelles (plages, réserves naturelles, zones humides). A ce sujet, Osmose continue de me forunir des tonnes de faux positifs de façon répétée (alors qu'ils sont corrigés : Analyse 1 ne donne aucune erreur, ni Layers, et pourtant Osmose insiste tous les 3(4 jours pour mettre une étiquette à l'extrémité de TOUTES les limites communes des ways de frontières de toutes les municipalités (niveau 8) à l'intérieur des provinces (niveau 6) ou commautés autonome (niveau 4) : ces étiquettes d'erreur sont toutes fausses et mentionnent sans arrêt des points qui ne font nulle part partie des ways des frontières. J'ai tenté de signaler ces points en faux positifs, sans succès : ils reviennent elors que tout est bon. Même chose en les marquant comme corrigés (ils reviennent aussi 3 jours plus tard). Cela ne facilite pas du tout les corrections car cela cache les vraies erreurs, et il faut à chaque fois remarquer comme corrigé des centaines de points inutiles pour la même relation (que j'ai revérifiés dans Layers et avec le lien Analyse 1 d'Osmose qui ne signale aucune erreur pourtant). Il me semble donc qu'Osmose a des problèmes à calculer ses géométries. Ou bien je me demande si ce n'est pas un bogue d'Osmose (qui le fait aussi en Italie, en Allemagne, au Royaume-Uni, en Suisse...). On dirait qu'il ne tient pas compte des modifications effectuées dans ces pays et continue de réutiliser d'anciennes données à chaque import (comme si Osmose n'intégrait à chaque passage tous les 3 jours que les modifs effectuées en France). Osmose ne marche-t-il réellement que pour la France ? Le 28 avril 2012 19:01, Ab_fab gamma@gmail.com a écrit : Philippe, Je peux me tromper car je ne connais pas bien le contexte, mais je crois qu'Emilie parle d'import de bâtiments, et toi des limites administratives. Le 28 avril 2012 18:48, Philippe Verdy verd...@wanadoo.fr a écrit : Le 28 avril 2012 18:23, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 28/04/2012 17:02, Philippe Verdy a écrit : Le 28 avril 2012 15:20, Emilie Laffrayemilie.laff...@gmail.com a écrit La réaction est en partie liée a certains imports massifs qui ont été fait ou qui vont être faits (import cadastral espagnol qui a l'air d?être particulièrement violent (apparemment plus de polygones importés que de gens dans une ville)) et a des problèmes éventuels d'import non compatible avec la licence en règle générale et quelque soit la licence, car ça complique fortement les roll back. Est-ce mal ? Pourquoi devrais-je utiliser un autre compte alors que toutes ces corrections sont manuelles, et pas massives du tout, masi constituées d'une série de communes de la même zone ? Si ce que tu dis ci-dessus est vrai, alors le rapport avec les imports qu'évoque Emilie est assez lointain... D'abord ce que je dis est vrai, je ne vois pas pourquoi tu voudrais en doûter... Non, je ne réagissait pas au message reçu par Emilie, mais à l'évocation des imports massifs de multipolygones, pour des multipolygones que j'ai créés pour résoudre des problèmes de géométrie en Espagne, ou en fusionnant des ways, et les multipolygones ajoutés ou complétés pour les communes espagnoles qui n'étaient définies que par les ways. J'ai fait ces modifs sur une période de plusieurs semaines, petit à petit, avec plein de recherches sur les données de l'INE pour vérifier le tout, et en localisant des centres adminsitratifs, et vérifiant les liens Wikipédia au besoin, et en cas de problème locaux sur certains points sur l'imagerie Bing, ou on prolongeant les frontières mal connectées entre elles (quand l'écart n'était que de quelques mètres, essentiellement sur la côte, ou pour redessiner des côtes très grossières, ou pour réordonner des traits comme des routes côitères, forêts, et autres landuse qui sortaient des terres. Tout cela manuellement, sans import massif ni aucun bot, patiemment à la souris, et en consultant Osmose et Layers pour vérifier que tout restait cohérent, ou lever des ambiguités (afin de ne modifier le moins possible le rendu Mapnik et conserver tous les détails). Et lors des commits, j'ai toujours pris soin d'annuler toute modif en cours en cas de conflit (en repreant ce qui est dans la base pour refaire la modification, histoire de n'oublier aucune modif plus récente depuis le téléchargement. Ca veut dire aussi que j'ai patiemment téléchargé sur
Re: [OSM-talk-fr] Notice à suivre pour les imports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, en effet Philippe se trompe complètement. Ce que les espagnols sont en train d'importer est un mélange de bâtiments, de landuse. La plupart des limites administratives sont déjà importées depuis belle lurette. Bref encore pas mal de hors sujet avec aucun rapport ce qui se passe sans compter que l'import massif espagnol est le fait d'une seule personne pour le moment alors que la communauté espagnole est encore en train de discuter de tout ça. Emilie Laffray On 28/04/2012 18:01, Ab_fab wrote: Philippe, Je peux me tromper car je ne connais pas bien le contexte, mais je crois qu'Emilie parle d'import de bâtiments, et toi des limites administratives. sts.openstreetmap.org/listinfo/talk-fr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+cQGQACgkQ7H1ne0ugLJl1bQCdGMCiYIdBUE3gJB/Om4b7L1yt YfMAnj+/lREAKSlAtzNWqxrJ8NryOyr8 =pnAa -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Avant de me dire que je suis hors sujet, il aurait fallu préciser le sujet : rien n'indiquait que vous parliez des imports du bâti. De plus les limites espagnoles étaient encore loin d'être finies, certes elles avaient été importées mais avec des tonnes d'erreurs de géométrie, que je suis en train de corriger (puisque cela n'a jamais été fait; si vous avez vous les cartes Layers il y a deux semaines, c'était bourré de trous à cause des erreurs de géométrie et chemins en doublons mal connectées; de plus il y manquait pas mal d'admin_center non référencé, et il y avait encore pas mal de problèmes, très visibles aussi bien dans Osmose que Layers et OSM Inspector; diverses erreurs de zones superposées, des través approximatifs aussi, plein de lignes côtières fantaisistes, et des tonnes de TODO/FIXME (depuis longtemps). Au départ je n'aurais pas fait l'Espagne si la stabilité des frontières françaises dans les Pyrénées n'était pas en jeu (car aussi il y a encore du boulot à faire dans nos montagnes. Et puis les espagnols sont moins agressifs que certains d'entre vous sur cette liste à laquelle on m'avait pourtant invité. Le 28 avril 2012 21:09, Emilie Laffray emilie.laff...@gmail.com a écrit : en effet Philippe se trompe complètement. Ce que les espagnols sont en train d'importer est un mélange de bâtiments, de landuse. La plupart des limites administratives sont déjà importées depuis belle lurette. Bref encore pas mal de hors sujet avec aucun rapport ce qui se passe sans compter que l'import massif espagnol est le fait d'une seule personne pour le moment alors que la communauté espagnole est encore en train de discuter de tout ça. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Le 28/04/2012 19:10, Vincent de Chateau-Thierry a écrit : Le 28/04/2012 18:37, Philippe Verdy a écrit : Dans ce cas, si ce qui est mappé sont les cantons électoraux, ce n'est pas une subdivision politique non plus. Donc ce devrait être boundary=electoral et non boundary=political_division. Le tableau n'ayant pas trop changé depuis, tu peux aussi voir le fil qui commence ici : http://lists.openstreetmap.org/pipermail/talk-fr/2011-October/036546.html qui traite du sujet. vincent Bonsoir, C'est quand même Philippe qui a raison administrativement parlant! Cela est une certitude. En France les divisions administratives sont 1 État 2 Région 3 Département 4 Arrondissement 5 Canton 6 Communauté de communes (ou d'agglomération) ce niveau étant aléatoire 7 Communes 8 Conseil de quartier pour les communes les plus importantes (aléatoire dans les autres communes) mais sans valeur décisionnelle Soit 8 niveaux! Le problème est qu'à vouloir à tout prix faire de l'international et se plier aux systèmes anglophones (pour ne pas dire américain) on en oublie notre propre structure. Seuls les 5 premiers et le 7° sont impératifs du point de vue de la loi le 6° étant fortement recommandé dans un souci de rationalisation des moyens. Les points 5 et 6 peuvent se fusionner mais ce n'est absolument pas une vérité. Le point 8 n'a que peu d'intérêt car ce sont des structures consultatives. Maintenant si on veut s'amuser avec les juridictions je peux vous donner du plaisir avec l'ancien régime. La vous aurez des inclusions exclusions en pagaille dans les relations. Vous aurez une structure différente par type de sujet couvert: La justice, n'est pas la même selon que nous sommes au niveau seigneurial ou royal. Mêmes choses pour les impôts déclinés chacun avec leur zone géographique. Amusez-vous avec le rattachement des paroisses à leur évêché. Amusez-vous aussi avec les provinces et les parlements. Il est assez rare de voir toutes ces juridictions coller exactement les unes avec les autres. Et nous ne parlons pas de date car à c'est un individu qui avait le privilège donc selon le pouvoir royal tout peut changer d'une période à l'autre. Amitiés -- Yannick VOYEAUD Nul n'a droit au superflu tant que chacun n'a pas son nécessaire (Camille JOUFFRAY 1841-1924, maire de Vienne) http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Journées du Logiciel Libre: http://jdll.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
Le 28 avril 2012 22:05, Philippe Verdy verd...@wanadoo.fr a écrit : Avant de me dire que je suis hors sujet, il aurait fallu préciser le sujet : rien n'indiquait que vous parliez des imports du bâti. Bonsoir, Il s'agissait pourtant du sujet initial présenté par Fabien: *J'ai reçu ce matin un message, en Anglais, de la part d'un modérateur OSM par rapport au fait que j'ai importé récemment du bâti dans OSM.* Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Import des points de contact du réseau postal français
Bonsoir, Pour faire suite à la discussion sur les points libérés par La Poste [1], la page de visualisation : http://osm.vdct.free.fr/postes/index.html permet désormais d'éditer les points. J'ai du faire quelques choix pour les tags, les voici : * nom du tag ref : ref:FR:LaPoste * nom du tag name : c'est name et non post_office:name. La valeur est celle de la source, modulo le passage en minuscules hors initiales, et le remplacement de 'A' par 'Annexe', et de 'PAL' par 'Principal'. * tag post_office:type : il n'est pas renseigné pour les bureaux classiques. Il vaut 'post_annex' pour les Agences Postales Communales, et 'post_partner' pour les Relais Poste Commerçants. * un tag note compile, lorsque renseignés dans la source, les items complement_adresse,adresse et lieu_dit. L'idée est de proposer une aide à la géolocalisation avec ces infos. Mais une fois le point correctement placé, ne pas hésiter à supprimer ce tag. * les tags des services disponibles sont tous de la forme tag nommant le service='yes'. Initialement, une proposition était d'utiliser amenity=copy_facility pour les photocopies, mais amenity est déjà pris pour...amenity=post_office ! * pas de tag pour le service monnaie de Paris faute de proposition. Il est toujours temps, si vous êtes inspirés :-). L'identifiant des bureaux de poste permettra le cas échéant de propager le tag le moment venu. * telephone : j'ai laissé finalement les numéros courts, partant du principe qu'ils font partie de la source et que nous avons un tag pour les intégrer. Pour les numéros classiques, je n'ai pas procédé à un formatage, c'est le numéro brut tel que dans la source, contrairement à ce que préconise la page http://wiki.openstreetmap.org/wiki/Phone . Sur les 17100 bureaux proposés dans la source, seuls 15944 sont disponibles à l'import. Les autres n'ont pas, dans la source, de coordonnées lon/lat. Ils disposent néanmoins d'une adresse, il est donc possible de les importer manuellement. Pour rappel la page du wiki qui synthétise le sujet (et qui n'est pas 100% raccord avec ce mail) : http://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr/Import_des_points_de_contact_postaux L'interface vous permet de marquer un point importé, en distinguant le type d'import opéré. L'idée est de pouvoir produire des stats par la suite, voire de visualiser les points selon le type de traitement. Toutes les suggestions bienvenues. vincent [1] : http://lists.openstreetmap.org/pipermail/talk-fr/2012-April/042797.html et suivants ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : [Talk-fr] Notice à suivre pour les imports
Le 28 avril 2012, Romain Mehut a écrit : Le 28 avril 2012 22:05, Philippe Verdy verd...@wanadoo.fr a écrit : Avant de me dire que je suis hors sujet, il aurait fallu préciser le sujet : rien n'indiquait que vous parliez des imports du bâti. Bonsoir, Il s'agissait pourtant du sujet initial présenté par Fabien: J'ai reçu ce matin un message, en Anglais, de la part d'un modérateur OSM par rapport au fait que j'ai importé récemment du bâti dans OSM. Romain Merci Romain pour ta concision. Pour plusieurs, nous parcourons plusieurs listes de distribution et apprécions de pouvoir suivre simplement la discussion. Pour rappel, lorsque nos commentaires portent sur un point précis d'un long texte, la règle usuelle sur les groupes de discussion est de recopier cette partie du texte et la commenter ensuite. Pour ceux qui veulent consulter l'historique de la discussion, il est toujours possible de retourner sur le site http://lists.openstreetmap.org/listinfo/talk-fr . Pierre De : talk-fr-requ...@openstreetmap.org talk-fr-requ...@openstreetmap.org À : talk-fr@openstreetmap.org Envoyé le : Samedi 28 avril 2012 17h02 Objet : Lot Talk-fr, Vol 69, Parution 147 - Mail transféré - Envoyez vos messages pour la liste Talk-fr à talk-fr@openstreetmap.org Pour vous (dés)abonner par le web, consultez http://lists.openstreetmap.org/listinfo/talk-fr ou, par email, envoyez un message avec 'help' dans le corps ou dans le sujet à talk-fr-requ...@openstreetmap.org Vous pouvez contacter l'administrateur de la liste à l'adresse talk-fr-ow...@openstreetmap.org Si vous répondez, n'oubliez pas de changer l'objet du message afin qu'il soit plus spécifique que Re: Contenu du digest de Talk-fr... Thèmes du jour : 1. Re: Cantons administratifs (Vincent de Chateau-Thierry) 2. Re: Notice à suivre pour les imports (Philippe Verdy) 3. Re: Notice à suivre pour les imports (Emilie Laffray) 4. Re: Notice à suivre pour les imports (Philippe Verdy) 5. Re: Cantons administratifs (Yannick VOYEAUD) 6. Re: Notice à suivre pour les imports (Romain MEHUT) Le 28/04/2012 18:37, Philippe Verdy a écrit : Dans ce cas, si ce qui est mappé sont les cantons électoraux, ce n'est pas une subdivision politique non plus. Donc ce devrait être boundary=electoral et non boundary=political_division. Le tableau n'ayant pas trop changé depuis, tu peux aussi voir le fil qui commence ici : http://lists.openstreetmap.org/pipermail/talk-fr/2011-October/036546.html qui traite du sujet. vincent Effectivement, mais dans de nombreux cas, mes modifs concernaient aussi les côtes, les landuse=* (ports, forets en distinguant bien les forêts de feuillus, conifères et mixtes, prairies, vignobles, zones résidentielles), y compris la récupération des fragments CORINE quant ils rendaient la carte illisible et ajoutaient des tas de points inutiles (ne correspondant à rien sur des zones jointives ayant exactement les mêmes attributs, cas fréquent sur les forêts que j'ai pu récupérer en grand nombre quand leur géométrie était totalement cassée) et des zones naturelles (plages, réserves naturelles, zones humides). A ce sujet, Osmose continue de me forunir des tonnes de faux positifs de façon répétée (alors qu'ils sont corrigés : Analyse 1 ne donne aucune erreur, ni Layers, et pourtant Osmose insiste tous les 3(4 jours pour mettre une étiquette à l'extrémité de TOUTES les limites communes des ways de frontières de toutes les municipalités (niveau 8) à l'intérieur des provinces (niveau 6) ou commautés autonome (niveau 4) : ces étiquettes d'erreur sont toutes fausses et mentionnent sans arrêt des points qui ne font nulle part partie des ways des frontières. J'ai tenté de signaler ces points en faux positifs, sans succès : ils reviennent elors que tout est bon. Même chose en les marquant comme corrigés (ils reviennent aussi 3 jours plus tard). Cela ne facilite pas du tout les corrections car cela cache les vraies erreurs, et il faut à chaque fois remarquer comme corrigé des centaines de points inutiles pour la même relation (que j'ai revérifiés dans Layers et avec le lien Analyse 1 d'Osmose qui ne signale aucune erreur pourtant). Il me semble donc qu'Osmose a des problèmes à calculer ses géométries. Ou bien je me demande si ce n'est pas un bogue d'Osmose (qui le fait aussi en Italie, en Allemagne, au Royaume-Uni, en Suisse...). On dirait qu'il ne tient pas compte des modifications effectuées dans ces pays et continue de réutiliser d'anciennes données à chaque import (comme si Osmose n'intégrait à chaque passage tous les 3 jours que les modifs effectuées en France). Osmose ne marche-t-il réellement que pour la France ? Le 28 avril 2012 19:01, Ab_fab gamma@gmail.com a écrit : Philippe, Je peux me tromper car je ne connais pas bien le contexte, mais je crois qu'Emilie parle d'import de bâtiments, et toi des limites administratives. Le 28 avril 2012 18:48, Philippe
Re: [OSM-talk-fr] Cantons administratifs
Le 28/04/2012 22:59, Yannick VOYEAUD a écrit : C'est quand même Philippe qui a raison administrativement parlant! Cela est une certitude. En France les divisions administratives sont 1 État 2 Région 3 Département 4 Arrondissement 5 Canton 6 Communauté de communes (ou d'agglomération) ce niveau étant aléatoire 7 Communes 8 Conseil de quartier pour les communes les plus importantes (aléatoire dans les autres communes) mais sans valeur décisionnelle Soit 8 niveaux! Le problème est qu'à vouloir à tout prix faire de l'international et se plier aux systèmes anglophones (pour ne pas dire américain) on en oublie notre propre structure. En l'occurrence, le modèle de tags qui décline les valeurs d'admin_level n'a rien d'international, au contraire : à chaque pays de piocher autant de niveaux que nécessaire pour décrire ses découpages administratifs, qu'ils soient complets ou partiels en terme de couverture. Après, d'un pays à l'autre, il peut y avoir des conventions communes, comme celle qui affecte la valeur 8 d'admin_level au niveau local. Elle est d'ailleurs antérieure à OSM. Seuls les 5 premiers et le 7° sont impératifs du point de vue de la loi le 6° étant fortement recommandé dans un souci de rationalisation des moyens. Les points 5 et 6 peuvent se fusionner mais ce n'est absolument pas une vérité. Le point 8 n'a que peu d'intérêt car ce sont des structures consultatives. Concernant le statut des cantons, qu'ils soient un découpage administratif, soit (et s'il y a de la littérature là-dessus, ça m'intéresse). Le souci est pour le passage de la réalité à une modélisation où les niveaux sont imbriqués, comme c'est le cas avec les niveaux administratifs taggués en admin_level. Le canton pouvant aussi bien englober plusieurs communes (donc inférieur au niveau 8) qu'être une portion de commune (donc supérieur au niveau 8), il est impossible de le placer à un niveau constant dans la pyramide administrative une fois modélisée. D'où, compte tenu de son usage de circonscription électorale, le choix d'en faire une couche à part, hors pyramide admin, avec une valeur du tag boundary qui n'est pas administrative. Qu'on torde la réalité pour la faire entrer dans notre modèle, c'est un fait. Mais ça permet (de mon point de vue) une modélisation de la notion de canton plus claire : on définit le canton pour lui même, et non relativement à des communes, ce qui serait un casse-tête. Par suite la saisie (côté contributeur) et l'exploitation (côté consommateur) sont facilitées, c'est toujours ça. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Notice à suivre pour les imports
D'une part il fallait repérer ce seul mot dans un plus ancien message qui n'est pas celui auquel j'ai répondu en copiant justement une phrase d'Emilie. Elle parlait de données en nombre en Espagne, surtout des multipolygones et c'est uniquement là-dessus que j'ai répondu en citant justement sa phrase, car le sujet avait déjà dévié avant moi de son premier mesage dont la porée était toutefois bien plus générique que les seuls imports de bâti mais traitait tout import en général. Elle a évoqué un point particulier et c'est là-dessus que j'ai répondu, en restant justement dans son sujet. Arrêtez d'être plus pointilleux qu'elle. Je suis resté dans son sujet. Merci. Le 28 avril 2012 23:02, Romain MEHUT romain.me...@gmail.com a écrit : Le 28 avril 2012 22:05, Philippe Verdy verd...@wanadoo.fr a écrit : Avant de me dire que je suis hors sujet, il aurait fallu préciser le sujet : rien n'indiquait que vous parliez des imports du bâti. Bonsoir, Il s'agissait pourtant du sujet initial présenté par Fabien: J'ai reçu ce matin un message, en Anglais, de la part d'un modérateur OSM par rapport au fait que j'ai importé récemment du bâti dans OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons administratifs
Le 28 avril 2012 22:59, Yannick VOYEAUD yann...@voyeaud.org a écrit : En France les divisions administratives sont 1 État 2 Région 3 Département 4 Arrondissement 5 Canton 6 Communauté de communes (ou d'agglomération) ce niveau étant aléatoire 7 Communes 8 Conseil de quartier pour les communes les plus importantes (aléatoire dans les autres communes) mais sans valeur décisionnelle Tu oublies les arrondissements municipiaux entre 7 et 8 ici, qui sont dans la hiérarchie. Et non les communautés de communes (ou de façon plus générale les EPCI) ne sont pas des niveaux administratifs. En plus ces EPCI ne sont pas des subdivisions des cantons, ni des arrondissements départementaux et il arrive même qu'on ait des EPCI à cheval sur plusieurs départements ou régions. Les EPCI ne respectent pas la hiérarchie. De même les cantons ne suivent pas toujours les communes entières puisuq'il y a des fractions cantonnales (l'Insee donne une liste exhaustive des communes coupées en plusieurs fractions cantonales, chacune dans un canton différent, sachant aussi qu'une commune fractionnée peut avoir une fraction cantonale dans un canton qui regroupe d'autres communes limitrophes toutes entières). Les EPCI ne suivent pas du tout la hiérarchie administrative. Ce sont les communes elles-mêmes qui décident de s'associer ou non, la loi leur imposant maintenant de créer des territoires sans enclaves ni exclaves, mais cela n'a pas toujours été le cas et il reste des EPCI avec enclaves/exclaves. Ce qu'on appelait classiquement canton (depuis la mise en place de l'administration de la France par Napoléon), c'était la subdivision des arrondissements, quand les cantons respectaient les limites communales et découpaient exactement les arrondissements. Ces cantons persistent aujourd'hui effectivement dans les bases Insee aussi. Les canton actuels utilisés aux fins électorales ne s'appellent plus cantons mais circonscriptions, même si dans l'usage courant on parle encore d'élections cantonales (on devrait dire élections des conseillers généraux). Il y a plusieurs types de circonscriptions selon ceux pour qui on vote : les circonscriptions électorales pour les conseils généraux, pour les députés et pour le sénat, et pour les députés européens sont différentes (il y a d'autres circonscriptions pour des scrutins non universels, tels que les chambres professionnelles). Mais en rien ces circonscriptions ne sont des divisions administratives (un redécoupage électoral n'affecte en rien les services de l'Etat comme la police ou la gendarmerie au sein des cantons traditionnels). Ce sont ces cnatons traditionnels et non les circonscriptions électorales très changeantes qui sont référencées comme base et dans les noms de certains EPCI. Ces circonscritions ne sont pas non plus des subdivisions politiques. Et puis tu oublies d'autres regroupements: les pays (au sein des départements, certains étant à cheval sur plusieurs arrondissements mais incluant des communes entières), et pays loi Voynet (plus grand et pouvant inclure des communes sur plusieurs départements et régions) : ces regroupements sont appuyés par les EPCI, l'unité de base étant la commune entière, pas le canton administratif (historique) ni une circonscription électorale (qui évolue à chaque élection uniquement sur des bases de représentation équitable de la population sans tenir compte des subdivisions administratives ou historiques actuelles, sur la base des données de recensement de population, pour qu'il y ait à peu près le même nombre de citoyens, et non d'habitants, représentés par chaque élu à chaque élection). Les circonscriptions électorales sont faites selon la loi électorale et selon le mode de scrutin (avec ou sans proportionelle, un mode proportionnel nécessitant d'agrandir les circonscriptions pour regrouper plusieurs sièges d'élus dans une même circonscription par rapport au mode majoritaire). Les circonscriptions ne servent qu'aux élections, elles ne créent pas de subdivisions administratives. Et ne sont pas politiques non plus. Les cantons sont en revanche toujours des subdivisions administratives (même si ce ne sont pas des collectivités locales, ils émanent directement de l'Etat via les préfets). Enfin on peut parler d'autres découpages de la France (non directement administratifs) : le découpage des régions militaires, celui des régions maritimes, celui des juridictions, la carte hospitalière, les académies et la carte scolaire, la sécurité sociale, les zones d'emploi, etc. Chaque ministère crée et gère son découpage pour ses services aujourd'hui (d'autant plus vite que l'Etat veut en réduire le nombre, ferme des hopitaux, écoles), et il en est de même depuis que les communes (et autres collectivités locales) ont transféré des compétences vers leur EPCI pour les services socio-médicaux et équipements/services culturels ou sportifs, l'assainissement, les ordures ménagères, la protection de l'environnement, l'urbanisme, la voirie et les plans de
