Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/2010 22:10, Christian Rogel a crit: Le 27/09/10 21:52, Benot ROUSSEAU a crit : Cette catgorie de commune souvent oublie dans les dcomptes de communes ncessite, elle-seule, d'avoir un chelon infra-communal. Je ne connais pas, je vais chercher une source. As-tu un exemple ? Le Wikipdia est une source souvent de valeur : http://fr.wikipedia.org/wiki/Commune_associe Les communes associes ont t cres en 1971 710 communes associes (a a tendance diminuer) 2 communes ont 9 communes associes (Isigny-le-Buat et Val-de-Meuse) et 2 autres en ont huit! Certains dpartements doivent n'en avoir aucune. En Finistre, il n'y a que Kernvel, commune associe de Rosporden. Christian Je dirai oui en tant que limite administrative au vu de "un officier d'tat civil et officier de police judiciaire,"... Je ne souponnais mme pas l'existence de ces communes associes ! Merci Christian pour cette info. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/2010 22:43, Pieren a crit: 2010/9/27 Benot ROUSSEAU adressepossi...@free.fr Stop au suivi systmatique ! Est-ce que le sens des quartiers Allemands est le mme que celui en France ? ? ? Connaissant la rputation Allemande face a la latine, je pense quelle est cohrente. Pour autant, sans nous mettre des illres,et ne pas allez voir autour ce qui se fait, on peux aussi rflchir par nous mme. Par exemple, quand milie nous parle des usages de subarea dans le dcoupage en Espagne elle ne semble franchement prte l'appliquer en France. Si on regarde le tableau ici: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative j'ai rapidement compt les admin_level correspondant la municipalit: 1 pays au niveau 5, 2 au niveau 6, 5 au niveau 7, 40 au niveau 8, 1 au niveau 9 (l'Australie), 1 au niveau 10. Le solde contient ceux que je n'ai pas pu dterminer (comme la Chine) ou qui est inapplicable ou indtermin. Le niveau administratif infrieur est souvent le "suburb" qui se trouve mieux rpartit entre les admin_level 9 et 10. Bonne ide ton tableau. Merci. Notez tout en bas de la page "Current import of US states has begun to use an extension, border_type=* to give the name of the boundary's type." qui a la mme vocation ma proposition d'ajouter "nature". Mais cela exite t'il encore ou est-ce une trace archologique ? Je n'ai pas vrifi. En tous cas d'autres pays se posent des questions sur l'usage de boundary=administrative pour des entits de mme niveau administratif. Donc, part quelques cas qui se distinguent, on a conserv une structure peu prs cohrente de niveau 8 pour les municipalits (NUTS 5, y compris en Allemagne), 6 pour les dpartements (NUTS 3) et 4 pour les rgions (NUTS 2) (http://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics). Les allemands sont deux fois dans le tableau avec 10 ou 11 niveaux. J'en conclus qu'il y a controverse chez-eux aussi (pour ce qui concerne les niveaux infrieurs au Gemeinde). Merci pour le lien NUTS. Ma remarque est que comme pour l'INSEE, c'est un dcoupage vocation statistique. Il sert beaucoup comme rfrence un dcoupage administratif et peux conduire des aberrations et des contresens. Alors, c'est vrai, on peut adapter les tags nos particularismes mais j'aimerais que nous conservions au moins les niveaux 2,4,6,8 comme ils sont actuellement. Pour le reste, la discussion est ouverte (et ne m'intresse pas beaucoup, je dois avouer). Les spcification "fr" actuelles pour 2,4,6 et 8 ne posent de pb personne sous l'tiquette boundary=administrative avec le seul tag admin_level, telles quelles sont dfinies actuellement. Les discussions actuelles pose la question des EPCI en 7, qui devraient tre en 8, des quartiers qui ne devraient pas tres tiquetes systmatiquement en divisions administratives, des arrondissements dpartementaux et communes associes qui ne sont pas reprsents et de l'usage qui y inclus parfois les cantons. Pieren Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 26/09/2010 22:45, Vincent de Chateau-Thierry a crit: Le 26/09/2010 02:30, Benot ROUSSEAU a crit : Selon moi, le niveau 7 correspondrait aux arrondissements dpartementaux. Voir : http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre chapitre "Cadre" Je suis d'accord avec toi, et mme avec moi :-), sachant que je proposais ceci au dbut du fil. Il reste pour appliquer a statuer sur les com'com qui occupent cet admin_level [1]. Comment continuer sur le sujet des com'com ? Il y a -au moins- deux propositions de modlisation de la relation, par boundary=* et par region=*, ainsi que des tags spcifiques tablir (typologie des EPCI, etc). Une nouvelle page de wiki et son onglet discussion ? :-). Pour ma part sans enlever les rfrences au COG, je me baserai sur le dcoupage du chapitre "Cadre" de http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre avec les communes et les arrondissements municipaux en plus. Il y aurait ainsi seulement 6 niveaux administratifs : A - Pays, B - Rgions, C - Dpartements(Prfectures), D - Sous-Prfectures (sachant qu'elles sont "sous tutelle" de la Prfecture au niveau dpartemental), E - Communes, F- Arrondissements municipaux. Avec une hsitation pour les Sous-prfectures... Avec ce dcoupage, les territoires s'emboitent, les limites communales sont partages entre les niveaux et il me semble que le sens premier de boundary=administative est respect et comprhensible. +1 vincent [1] : http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives#En_proposition_:_.C3.89tablissements_publics_de_coop.C3.A9ration_intercommunale Je vais dj prparer une synthse avec des exemples pour que tout le monde puisse suivre et voir, si, se rpondre sur des points de dtail on ne s'est fourvoys globalement. Un vote serait ensuite une bonne chose... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 26 sept. 10 à 14:25, Benoît ROUSSEAU a écrit : Du coup je suis allé voir à la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid . Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des délégations de la Mairie. Admin_level poserait alors le même problème que pour les EPCI puisque ce n'est pas un sous-niveau administratif à la Commune mais un découpage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient être traités en tant que tel même si la densité de population est plus élevée en ville. Je ne suis pas sur du bien comprendre cette obligation de voir un système strictement hiérarchique dans les différents niveaux des boundary=administrative. Rien n'oblige a suivre cette idée. boundary=administrative ne définit que des frontières administratives. Un quartier avec conseil local et budget autonome entre à priori dans ce cadre, de même qu'un arrondissement préfectoral ou même un EPCI... Ce qui bloque réellement, à mon avis, c'est l'usage des admin_level (3 à 10)... laissant pas assez de places actuellement pour y insérer d'autres frontières administratives. On notera que quelques pays (allemagne et pays-bas) ont déjà étendu au admin_level=11 pour les quartiers. Sur la discussion actuelle on voit bien que les définitions sont délicates et que certains niveaux admin ne sont pas compatible avec la règle implicite d'inclusion dans les niveaux supérieurs et inférieurs (les cantons par exemple). J'aurai tendance a dire qu'il faudrait conserver les système actuels des boundary pour les niveaux déjà utilisés (région, département, commune) y définir 7 plutôt pour les arrondissements préfectoraux. Et expérimenter le système proposé de relation region pour les EPCI par inclusion des relation de communes. Mais on pourrait aussi imaginer de n'utiliser la relation frontière que pour les communes et les cantons et de construire les autres niveaux par addition (relation type region) des communes qui constitue. Evidemment ça pose certains problèmes (évoqué par d'autres) puisque toutes les communes ne sont pas définis à ce jour, mais c'est théoriquement un modèle conforme. Toutefois je suis d'accord qu'il ne puisse s'appliquer que pour un nombre restreint de communes (EPCI par exemple). -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 26/09/10 14:25, Benoît ROUSSEAU a écrit : Du coup je suis allé voir à la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid . Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des délégations de la Mairie. Admin_level poserait alors le même problème que pour les EPCI puisque ce n'est pas un sous-niveau administratif à la Commune mais un découpage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient être traités en tant que tel même si la densité de population est plus élevée en ville. Benoît R. Je n'ai pas eu le courage d'aller voir la source, mais je signale que le territoire infra-communal qui doit être tracé en premier lieu, c'est celui de la commune associée, car elle seule a une existence administrative indiscutable : son corps électoral élit des conseillers particuliers qui s'intègrent au conseil municipal général. Cette catégorie de commune souvent oubliée dans les décomptes de communes nécessite, à elle-seule, d'avoir un échelon infra-communal. Si un niveau 11 a déjà été mis en place dans le monde, prenons-le, mais en vérifiant que l'échelon communal allemand correspond bien à nos communes, i.e. être l'avant-dernier échelon de la pyramide. Par ailleurs, je redis que la notion de quartier est floue (sauf à Paris) : dans ma ville, on a pris la mauvaise habitude d'appeler quartier les anciennes communes fusionnées (qui ont un adjoint spécial),ça fait de beaux quartiers de 3000 ha, mais quid des quartiers réels, au raz de la vie des gens? A la campagne, au moins par ici, il y avait (a?) des quartiers regroupant un nombre variable de hameaux desservis par une chapelle; En tout cas, je ne vois pas la correspondance quartier/lieu-dit. Christian Habitant d'un immense quartier, 1/4 urbain - 3/4 rural ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/2010 20:34, Pierre-Alain Dorange a crit: Le 26 sept. 10 14:25, Benot ROUSSEAU a crit : Du coup je suis all voir la source :http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid. Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des dlgations de la Mairie. Admin_level poserait alors le mme problme que pour les EPCI puisque ce n'est pas un sous-niveau administratif la Commune mais un dcoupage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient tre traits en tant que tel mme si la densit de population est plus leve en ville. Je ne suis pas sur du bien comprendre cette "obligation" de voir un systme strictement hirarchique dans les diffrents niveaux des boundary=administrative. Rien n'oblige a suivre cette ide. boundary=administrative ne dfinit que des frontires administratives. Un quartier avec conseil local et budget autonome entre priori dans ce cadre, de mme qu'un arrondissement prfectoral ou mme un EPCI... Euh, j'attends de faire la synthse, mais personne n'a dit a. C'est venu dans la discussion essentiellement comme des questionnements. Ce qui a t dit c'est qu'on ai un systme qui puisse intgrer l'ordre tabli au niveau international sans le bouleverser. Donc implmenter le schma boundary=administrative pour tout ce qui y entre naturellement. Ce qui bloque rellement, mon avis, c'est l'usage des admin_level (3 10)... laissant pas assez de places actuellement pour y insrer d'autres frontires administratives. On notera que quelques pays (allemagne et pays-bas) ont dj tendu au admin_level=11 pour les quartiers. Stop au suivi systmatique ! Est-ce que le sens des quartiers Allemands est le mme que celui en France ? ? ? Connaissant la rputation Allemande face a la latine, je pense quelle est cohrente. Pour autant, sans nous mettre des illres,et ne pas allez voir autour ce qui se fait, on peux aussi rflchir par nous mme. Par exemple, quand milie nous parle des usages de subarea dans le dcoupage en Espagne elle ne semble franchement prte l'appliquer en France. Sur la discussion actuelle on voit bien que les dfinitions sont dlicates et que certains niveaux admin ne sont pas compatible avec la rgle "implicite" d'inclusion dans les niveaux suprieurs et infrieurs (les cantons par exemple). Les cantons ne sont pas des limites administratives mais lectorales. Voir les discussions prcdentes ou la synthse venir. Donc effectivement ils sont dlicats intgrer car ils ne devraient pas y tre intgrs. J'aurai tendance a dire qu'il faudrait conserver les systme actuels des boundary pour les niveaux dj utiliss (rgion, dpartement, commune) y dfinir 7 plutt pour les arrondissements prfectoraux. Et exprimenter le systme propos de relation region pour les EPCI par inclusion des relation de communes. Les deux ne sont pas incompatibles. On peux passer de l'un l'autre donc il faudra trancher mais les consquences seront minimes si l'usage le choix s'avrait tre le moins pratique. On pourrait passer l'autre modle par traitement automatique. Mais on pourrait aussi imaginer de n'utiliser la relation frontire que pour les communes et les cantons et de construire les autres niveaux par addition (relation type region) des communes qui constitue. Evidemment a pose certains problmes (voqu par d'autres) puisque toutes les communes ne sont pas dfinis ce jour, mais c'est thoriquement un modle conforme. Toutefois je suis d'accord qu'il ne puisse s'appliquer que pour un nombre restreint de communes (EPCI par exemple). C'est dans le tas des propositions. Je ne comprends pas le sens donner "Toutefois je suis d'accord qu'il ne puisse s'appliquer que pour un nombre restreint de communes (EPCI par exemple).".
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/2010 21:31, Christian Rogel a crit: Le 26/09/10 14:25, Benot ROUSSEAU a crit : Du coup je suis all voir la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid . Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des dlgations de la Mairie. Admin_level poserait alors le mme problme que pour les EPCI puisque ce n'est pas un sous-niveau administratif la Commune mais un dcoupage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient tre traits en tant que tel mme si la densit de population est plus leve en ville. Benot R. Je n'ai pas eu le courage d'aller voir la source, mais je signale que le territoire infra-communal qui doit tre trac en premier lieu, c'est celui de la commune associe, car elle seule a une existence administrative indiscutable : son corps lectoral lit des conseillers particuliers qui s'intgrent au conseil municipal gnral. Cette catgorie de commune souvent oublie dans les dcomptes de communes ncessite, elle-seule, d'avoir un chelon infra-communal. Je ne connais pas, je vais chercher une source. As-tu un exemple ? Si un niveau 11 a dj t mis en place dans le monde, prenons-le, mais en vrifiant que l'chelon "communal" allemand correspond bien nos communes, i.e. tre l'avant-dernier chelon de la pyramide. Par ailleurs, je redis que la notion de quartier est floue (sauf Paris) : dans ma ville, on a pris la mauvaise habitude d'appeler "quartier" les anciennes communes fusionnes (qui ont un adjoint spcial),a fait de beaux "quartiers" de 3000 ha, mais quid des quartiers rels, au raz de la vie des gens? A la campagne, au moins par ici, il y avait (a?) des quartiers regroupant un nombre variable de hameaux desservis par une chapelle; En tout cas, je ne vois pas la correspondance quartier/lieu-dit. Christian Habitant d'un immense "quartier", 1/4 urbain - 3/4 rural Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/10 21:52, Benoît ROUSSEAU a écrit : Cette catégorie de commune souvent oubliée dans les décomptes de communes nécessite, à elle-seule, d'avoir un échelon infra-communal. Je ne connais pas, je vais chercher une source. As-tu un exemple ? Le Wikipédia est une source souvent de valeur : http://fr.wikipedia.org/wiki/Commune_associée Les communes associées ont été crées en 1971 710 communes associées (ça a tendance à diminuer) 2 communes ont 9 communes associées (Isigny-le-Buat et Val-de-Meuse) et 2 autres en ont huit! Certains départements doivent n'en avoir aucune. En Finistère, il n'y a que Kernével, commune associée de Rosporden. Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
2010/9/27 Benoît ROUSSEAU adressepossi...@free.fr Stop au suivi systématique ! Est-ce que le sens des quartiers Allemands est le même que celui en France ? ? ? Connaissant la réputation Allemande face a la latine, je pense quelle est cohérente. Pour autant, sans nous mettre des œillères,et ne pas allez voir autour ce qui se fait, on peux aussi réfléchir par nous même. Par exemple, quand Émilie nous parle des usages de subarea dans le découpage en Espagne elle ne semble franchement prête à l'appliquer en France. Si on regarde le tableau ici: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative j'ai rapidement compté les admin_level correspondant à la municipalité: 1 pays au niveau 5, 2 au niveau 6, 5 au niveau 7, 40 au niveau 8, 1 au niveau 9 (l'Australie), 1 au niveau 10. Le solde contient ceux que je n'ai pas pu déterminer (comme la Chine) ou qui est inapplicable ou indéterminé. Le niveau administratif inférieur est souvent le suburb qui se trouve mieux répartit entre les admin_level 9 et 10. Donc, à part quelques cas qui se distinguent, on a conservé une structure à peu près cohérente de niveau 8 pour les municipalités (NUTS 5, y compris en Allemagne), 6 pour les départements (NUTS 3) et 4 pour les régions (NUTS 2) ( http://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics). Les allemands sont deux fois dans le tableau avec 10 ou 11 niveaux. J'en conclus qu'il y a controverse chez-eux aussi (pour ce qui concerne les niveaux inférieurs au Gemeinde). Alors, c'est vrai, on peut adapter les tags à nos particularismes mais j'aimerais que nous conservions au moins les niveaux 2,4,6,8 comme ils sont actuellement. Pour le reste, la discussion est ouverte (et ne m'intéresse pas beaucoup, je dois avouer). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
2010/9/27 Pieren pier...@gmail.com 2010/9/27 Benoît ROUSSEAU adressepossi...@free.fr Stop au suivi systématique ! Est-ce que le sens des quartiers Allemands est le même que celui en France ? ? ? Connaissant la réputation Allemande face a la latine, je pense quelle est cohérente. Pour autant, sans nous mettre des œillères,et ne pas allez voir autour ce qui se fait, on peux aussi réfléchir par nous même. Par exemple, quand Émilie nous parle des usages de subarea dans le découpage en Espagne elle ne semble franchement prête à l'appliquer en France. Si on regarde le tableau ici: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative j'ai rapidement compté les admin_level correspondant à la municipalité: 1 pays au niveau 5, 2 au niveau 6, 5 au niveau 7, 40 au niveau 8, 1 au niveau 9 (l'Australie), 1 au niveau 10. Le solde contient ceux que je n'ai pas pu déterminer (comme la Chine) ou qui est inapplicable ou indéterminé. Le niveau administratif inférieur est souvent le suburb qui se trouve mieux répartit entre les admin_level 9 et 10. Quelques notes pour préciser que je ne suis pas sure que l'Australie soit un bon exemple puisqu'ils ont des limites administratives non consistantes d'un admin_level a l'autre. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 26/09/2010 11:51, Vincent Pottier a crit: On 26/09/2010 02:30, Benot ROUSSEAU wrote: Pour garder homogne le "grand tableau mondial" ok. Selon moi, le niveau 7 correspondrait aux arrondissements dpartementaux. Voir : http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre chapitre "Cadre" pour ce qui est du thme de l'administration. Pour ce qui est des quartiers en niveau 10, je ne sais pas quoi en penser, car je ne sais pas s'il existe "lgalement" des organismes d'administration des quartiers. Les Conseils de quartier par exemple, n'ont qu'un avis consultatif selon http://fr.wikipedia.org/wiki/Conseil_de_quartier. Les conseils de quartiers peuvent avoir un petit bout d'administration local, particulirement en animation : "l'initiative locale" un budget vot en amont par le conseil municipal. Et, en lien avec un adjoint, prendre des dcisions mineurs sur l'amnagement, l'entretien... L'importance dpend de la politique municipale. Du coup je suis all voir la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid . Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des dlgations de la Mairie. Admin_level poserait alors le mme problme que pour les EPCI puisque ce n'est pas un sous-niveau administratif la Commune mais un dcoupage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient tre traits en tant que tel mme si la densit de population est plus leve en ville. -- FrViPofm Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Bonsoir, Le 26/09/2010 14:25, Benoît ROUSSEAU a écrit : Le 26/09/2010 11:51, Vincent Pottier a écrit : On 26/09/2010 02:30, Benoît ROUSSEAU wrote: Pour garder homogène le grand tableau mondial ok. Selon moi, le niveau 7 correspondrait aux arrondissements départementaux. Voir : http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre chapitre Cadre pour ce qui est du thème de l'administration. Pour ce qui est des quartiers en niveau 10, je ne sais pas quoi en penser, car je ne sais pas s'il existe légalement des organismes d'administration des quartiers. Les Conseils de quartier par exemple, n'ont qu'un avis consultatif selon http://fr.wikipedia.org/wiki/Conseil_de_quartier. Les conseils de quartiers peuvent avoir un petit bout d'administration local, particulièrement en animation : l'initiative locale un budget voté en amont par le conseil municipal. Et, en lien avec un adjoint, prendre des décisions mineurs sur l'aménagement, l'entretien... L'importance dépend de la politique municipale. Du coup je suis allé voir à la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid . Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des délégations de la Mairie. Admin_level poserait alors le même problème que pour les EPCI puisque ce n'est pas un sous-niveau administratif à la Commune mais un découpage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient être traités en tant que tel même si la densité de population est plus élevée en ville. -- Oui, c'est vrai qu'en toute logique, on ne devrait pas plus placer les quartiers que les EPCI dans l'arbre administratif, si la référence est le COG. Quand je proposais [1] de libérer le niveau 10 pour les quartiers, en remontant à 9 les arrondissements municipaux, je soulignais d'avance que dans le cas on n'aurait pas de ref:INSEE au niveau 10, manière de dire qu'ils n'avaient pas la même officialité. Il n'est pas rare cependant de voir un découpage de la ville proposé par la mairie, avec limites dessinées et nom attribué. C'est cet usage que je trouverais pertinent de placer en niveau 10, en faisant la supposition que les quartiers ne se chevauchent pas (à la différence des EPCI). Enfin, contrairement au niveau commune, le niveau admin 10 reste bien sûr complètement optionnel, pertinent seulement s'il reflète un usage (pour la toponymie) et si ses limites géographiques sont connues. Le recours au nodes place=* pour les lieux-dits reste bien sûr une alternative, déjà largement pratiquée dans la base. vincent [1] : http://lists.openstreetmap.org/pipermail/talk-fr/2010-September/026880.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Bonjour, Le 25/09/2010 13:27, Benoît ROUSSEAU a écrit : Pour les subarea je n'est remarqué aucun consensus, Pierre Quenee nous a proposé, comme base de travail, l'adaptation sur un modèle existant et Émilie à évoqué subarea en nous disant ca ne me plait pas mais ça existe par ailleurs. Oui, tout à fait. Mais hier soir je disais : _si_ il y a consensus. Mis a part le modèle proposer qui reste à affiner, renommer les tags, le compléter, il n'y a pas incohérence avec le modèle actuel bien au contraire c'est un complément indispensable ! C'est le modèle actuel qui nous amène à l'incohérence. Soit en hiérarchisant de haut en bas : des éléments qui pour certains ne sont pas des limites administratives ou des élément qui devraient être au même niveau administratif sur des niveaux différents. Même si nous rajoutions une numérotation de niveau a plus de 10 échelons, ce serait faux ! Ce n'est pas parce que le modèle qui fait consensus dans la base est limité que nous devons le reproduire bêtement à l'infini en entrant des données dedans au chausse pied en considérant que c'est un fourre tout. Tagguer un admin level 7 pour une communauté de commune est une erreur si les communes sont en 8 ! Ou alors il faut compléter le modèle actuel en ajoutant des compléments d'information pour distinguer les limites administratives placées au même niveau. Je viens de relire ce que je disais hier, et ça prête à confusion, je comprends ta réponse. Je ne parlais (ne voulais parler) que de la manière de construire l'objet com'com : par une relation de type boundary=*, ou par une autre de type region=*. Il est clair pour moi que dans un cas comme dans l'autre, le tag admin_level=* n'a rien à faire dans cette relation. En revanche, il est présent dans chacun des membres de la relation. En essayant de reformuler : quand on agrège des communes pour construire un département, on utilise boundary=*, pourquoi ne pas utiliser aussi boundary=autre chose pour agréger des communes à l'échelle d'une com'com. La solution de la relation est très pratique et flexible puisqu'elle évite d'avoir nécessairement à ressaisir les contours en incluant les contours des communes. L'argument comment on fait s'il n'y à pas de contours de communes ne tient pas, il faut les tracer. Facile à dire, et j'aimerais être d'accord avec ça, mais il faut être lucide, la courbe de croissance des limites admin est plutôt faible. Construire une version temporaire de com'com, avec les nodes place=* permet déjà d'identifier la com'com et ses communes constituantes (via leur ref:INSEE) ainsi que, au mieux, ses domaines de compétence. Le jour où les contours de commune existent, on remplace le node place=* par la relation boundary=administrative, mais au moins comme ça on ne créé pas d'adhérence entre les objets com'com et limite admin. Utiliser le node place=* est une suggestion pour gérer une situation transitoire, pas ce qui devrait être le modèle définitif. Personne ne se pose la question de tracer une route sans ways ou d'indiquer des sorties d'autoroutes sans l'autoroute. Qui plus est la relation permet d'ajouter un contour propre à la com'com. Le plus important même si l'on tâtonne en base est d'avoir l'ensemble des informations cohérentes pour transtyper automatiquement ces éléments si nécessaire dans le futur. Ca la relation et le modèle proposé le permettent. Tout à fait. Et cela peut valoir aussi bien pour membres de la relation (de node place=* à boundary=administrative) que pour les tags. A mon avis :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 25/09/2010 14:16, Vincent de Chateau-Thierry a crit: Bonjour, Le 25/09/2010 13:27, Benot ROUSSEAU a crit : Pour les subarea je n'est remarqu aucun consensus, Pierre Quenee nous a propos, comme base de travail, l'adaptation sur un modle existant et milie voqu subarea en nous disant "ca ne me plait pas mais a existe par ailleurs". Oui, tout fait. Mais hier soir je disais : "_si_ il y a consensus". Je reformule :p avec avoir en prime : je n'ai pas remarqu qu'on se dirigeai vers un consensus... Mis a part le modle proposer qui reste affiner, renommer les tags, le complter, il n'y a pas incohrence avec le modle actuel bien au contraire c'est un complment indispensable ! C'est le modle actuel qui nous amne l'incohrence. Soit en hirarchisant de haut en bas : des lments qui pour certains ne sont pas des limites administratives ou des lment qui devraient tre au mme niveau administratif sur des niveaux diffrents. Mme si nous rajoutions une numrotation de niveau a plus de 10 chelons, ce serait faux ! Ce n'est pas parce que le modle qui fait consensus dans la base est limit que nous devons le reproduire btement l'infini en entrant des donnes dedans au chausse pied en considrant que c'est un fourre tout. Tagguer un admin level 7 pour une communaut de commune est une erreur si les communes sont en 8 ! Ou alors il faut complter le modle actuel en ajoutant des complments d'information pour distinguer les limites administratives places au mme niveau. Je viens de relire ce que je disais hier, et a prte confusion, je comprends ta rponse. Je ne parlais (ne voulais parler) que de la manire de construire l'objet com'com : par une relation de type boundary=*, ou par une autre de type region=*. Il est clair pour moi que dans un cas comme dans l'autre, le tag admin_level=* n'a rien faire dans cette relation. En revanche, il est prsent dans chacun des membres de la relation. En essayant de reformuler : "quand on agrge des communes pour construire un dpartement, on utilise boundary=*, pourquoi ne pas utiliser aussi boundary="autre chose" pour agrger des communes l'chelle d'une com'com." L, il va me falloir du temps pour simuler avec un cas concret pour bien comprendre avant de rpondre. La solution de la relation est trs pratique et flexible puisqu'elle vite d'avoir ncessairement ressaisir les contours en incluant les contours des communes. L'argument comment on fait s'il n'y pas de contours de communes ne tient pas, il faut les tracer. Facile dire, et j'aimerais tre d'accord avec a, mais il faut tre lucide, la courbe de croissance des limites admin est plutt faible. Construire une version temporaire de com'com, avec les nodes place=* permet dj d'identifier la com'com et ses communes constituantes (via leur ref:INSEE) ainsi que, au mieux, ses domaines de comptence. Le jour o les contours de commune existent, on remplace le node place=* par la relation boundary=administrative, mais au moins comme a on ne cr pas d'adhrence entre les objets com'com et limite admin. Utiliser le node place=* est une suggestion pour grer une situation transitoire, pas ce qui devrait tre le modle dfinitif. Courbe de croissance faible oui. Je m'loigne du sujet prcis pour illustration mavie Pour exemple je vais prendre mon comportement face aux adresses et aux rivires. Les rivires j'ai essay, j'ai arrt aprs avoir lu le wiki et ses 50 (exagr) manires de faires et les discussions sur la liste qui en amenaient encore d'autres. Les adresses c'est en stanby alors que j'ai les moyens d'importer des millions d'adresses (j'ai fait les essais) automatiquement car le modle "Karl", est pass de proposition norme et aujourd'hui standard indboulonnable. Il me semble inappropri, car lui aussi mlange diffrents type d'adresses (administrative, gographique, postales), dans quelque chose qui devient systmatiquement contradictoire entre ceux qui militent pour l'administrative, la postale et la gographique. Soit je fais le forcing en imposant un nouveau standard en important plus d'adresses que tous les autres sur un schma perso, soit j'attends un
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 25/09/2010 14:38, Vincent Pottier a écrit : Il me semble qu'il y a une différence de nature entre un département et une communauté de commune. Un département n'est pas une agrégation de commune, mais un territoire, une collectivité territoriale dont les limites coïncident avec elles de M, N Une communauté de commune, quant à elle, est une agrégation de communes à laquelle adhèrent M, N... Oui. Mon raisonnement pour parler d'agrégation est à voir sous l'angle des primaires géométriques dans la base, avec en tête une question : comment rendre la base cohérente en terme de construction, à la fois pour ceux qui la constituent (nous) et pour ceux qui s'en servent/serviront (nous aussi, entre autres). Dans les 2 cas, depts et com'com, la construction _dans osm_se fait en assemblant un puzzle dont les pièces sont des communes (*). Et je ne trouve pas d'argument pour dire : en fonction du nombre de pièces du puzzle, je vais prendre des pièces limites ou des pièces surfaces. Mais bon, je ne suis pas spécialiste... Alors on est 2 :-) vincent (*) Je mets de côté la démarche Cartographes Associés qui partait directement de l'échelle département pour les constituer, vu qu'on supprime cette source doucement mais sûrement, pour lui substituer une géométrie et un maillage plus fins. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 25/09/2010 15:09, Vincent de Chateau-Thierry a crit: Le 25/09/2010 14:38, Vincent Pottier a crit : Il me semble qu'il y a une diffrence de nature entre un dpartement et une communaut de commune. Un dpartement n'est pas une agrgation de commune, mais un territoire, une collectivit territoriale dont les limites concident avec elles de M, N Une communaut de commune, quant elle, est une agrgation de communes laquelle adhrent M, N... Posons-nous la question : si on voulait un jour rcuprer ces informations de dcoupage administratif comment voudrions nous les voir reprsentes ? Je ne parle pour l'instant que du dcoupage, ensuite on verra comment intgrer les informations connexes. Le dcoupage administratif de manire gnral est un arbre, pas une pile. On sait dcrire un arbre en XML. Commenons par la structure avec des tags fictifs pour dbuter, piochons dans l'existant puis nous dfinirons ce qui manque. Oui. Mon raisonnement pour parler d'agrgation est voir sous l'angle des primaires gomtriques dans la base, avec en tte une question : comment rendre la base cohrente en terme de construction, la fois pour ceux qui la constituent (nous) et pour ceux qui s'en servent/serviront (nous aussi, entre autres). Dans les 2 cas, depts et com'com, la construction _dans osm_se fait en assemblant un puzzle dont les pices sont des communes (*). Et je ne trouve pas d'argument pour dire : en fonction du nombre de pices du puzzle, je vais prendre des pices "limites" ou des pices "surfaces". Sous l'angle des primaires gomtriques, difficile de trancher, car dans le cas des limites administratives puisque dfinissons des limites (frontires) de surfaces (territoires), qui donc doivent boucler. Ces limites donc pourraient trs bien tre des dfinies en surfaces sans en changer le sens. Pour ma part je prfrerai des area en place des boundary, mais dfinir des boundary n'est pas moins illogique.. Mais bon, je ne suis pas spcialiste... Alors on est 2 :-) vincent (*) Je mets de ct la dmarche "Cartographes Associs" qui partait directement de l'chelle "dpartement" pour les constituer, vu qu'on supprime cette source doucement mais srement, pour lui substituer une gomtrie et un maillage plus fins. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.856 / Base de donnes virale: 271.1.1/3158 - Date: 09/25/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Autre proposition : Actuellement pour les limites administratives des communes ont utilise quelque chose : des way dcrits comme suit : way id="34630977" visible="true" timestamp="2009-05-17T13:35:16Z" version="1" changeset="1221617" user="monsieur a" uid="97101" nd ref="393099429" / nd ref="393099430" / nd ref="393099441" / nd ref="393099442" / nd ref="393099443" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="source" v="cadastre-dgi-fr source : Direction Gnrale des Impts - Cadastre ; mise jour : 2008" / /way des relations d'appartenance dcrites comme suit : relation id="132343" visible="true" timestamp="2009-12-10T20:34:46Z" version="6" changeset="3344785" user="MrsPeel" uid="206119" member type="way" ref="34283363" role="" / member type="way" ref="34283360" role="" / member type="way" ref="34330022" role="" / member type="way" ref="34393976" role="" / member type="way" ref="34630977" role="" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Quinay" / tag k="ref:INSEE" v="86204" / tag k="source:ref:INSEE" v="COG" / tag k="type" v="boundary" / /relation relation id="145018" visible="true" timestamp="2009-11-09T11:58:47Z" version="4" changeset="3072415" user="EtienneChoveBot" uid="183561" member type="way" ref="34330016" role="" / member type="way" ref="34630977" role="" / member type="way" ref="34517049" role="" / member type="way" ref="34330421" role="" / member type="way" ref="34517047" role="" / member type="way" ref="34630990" role="" / tag k="addr:postcode" v="86580" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Vouneuil-sous-Biard" / tag k="ref:INSEE" v="86297" / tag k="source:addr:postcode" v="source of postcode is from osm nodes" / tag k="source:ref:INSEE" v="source of ref is from osm nodes" / tag k="type" v="boundary" / /relation Pourquoi ne pas simplement ajouter des relations com2com comme suit avec un tag "nature" (les anglophones traduiront) pour les distingues des communes au mme niveau et ca rsout le pb : relation id="145019" visible="true" timestamp="2009-11-09T11:58:48Z" version="4" changeset="30724185" user="quidam" uid="1883561" member type="way" ref="34630977" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Communaut de communes du val machin" / tag k="ref:INSEE" v="xxx" / tag k="type" v="boundary" / tag k="nature" v="ECPI" / /relation Ca ne change quasiment rien au schma actuel puisque c'est de la mme veine que le tag natural=coastline. Pas de region pas de subarea, ... et si j'ai bien compris c'est la proposition exprime par Vincent de Chteau-Thierry. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 25/09/2010 16:51, Benoît ROUSSEAU a écrit : Autre proposition : Actuellement pour les limites administratives des communes ont utilise quelque chose : des way décrits comme suit : way id=34630977 visible=true timestamp=2009-05-17T13:35:16Z version=1 changeset=1221617 user=monsieur a uid=97101 nd ref=393099429 / nd ref=393099430 / nd ref=393099441 / nd ref=393099442 / nd ref=393099443 / tag k=admin_level v=8 / tag k=boundary v=administrative / tag k=source v=cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre ; mise à jour : 2008 / /way des relations d'appartenance décrites comme suit : relation id=132343 visible=true timestamp=2009-12-10T20:34:46Z version=6 changeset=3344785 user=MrsPeel uid=206119 member type=way ref=34283363 role= / member type=way ref=34283360 role= / member type=way ref=34330022 role= / member type=way ref=34393976 role= / member type=way ref=34630977 role= / tag k=admin_level v=8 / tag k=boundary v=administrative / tag k=name v=Quinçay / tag k=ref:INSEE v=86204 / tag k=source:ref:INSEE v=COG / tag k=type v=boundary / /relation relation id=145018 visible=true timestamp=2009-11-09T11:58:47Z version=4 changeset=3072415 user=EtienneChoveBot uid=183561 member type=way ref=34330016 role= / member type=way ref=34630977 role= / member type=way ref=34517049 role= / member type=way ref=34330421 role= / member type=way ref=34517047 role= / member type=way ref=34630990 role= / tag k=addr:postcode v=86580 / tag k=admin_level v=8 / tag k=boundary v=administrative / tag k=name v=Vouneuil-sous-Biard / tag k=ref:INSEE v=86297 / tag k=source:addr:postcode v=source of postcode is from osm nodes / tag k=source:ref:INSEE v=source of ref is from osm nodes / tag k=type v=boundary / /relation Pourquoi ne pas simplement ajouter des relations com2com comme suit avec un tag nature (les anglophones traduiront) pour les distinguées des communes au même niveau et ca résout le pb : relation id=145019 visible=true timestamp=2009-11-09T11:58:48Z version=4 changeset=30724185 user=quidam uid=1883561 member type=way ref=34630977 role= / member type=way ref= role= / member type=way ref= role= / member type=way ref= role= / member type=way ref= role= / member type=way ref= role= / tag k=admin_level v=8 / tag k=boundary v=administrative / tag k=name v=Communauté de communes du val machin / tag k=ref:INSEE v=xxx / tag k=type v=boundary / tag k=nature v=ECPI / /relation Ca ne change quasiment rien au schéma actuel puisque c'est de la même veine que le tag natural=coastline. Pas de region pas de subarea, ... et si j'ai bien compris c'est la proposition exprimée par Vincent de Château-Thierry. Euh...:-) Une différence avec ce que je propose, c'est que dans une relation com'com basée sur des limites, il faut le tag type=boundary (puisqu'on parle de limites), mais il ne faut surtout pas boundary=administative. D'où ma proposition de boundary=local_authority. Après oui, si on regarde par exemple la définition actuelle de Saint-Quentin-en-Yvelines : relation id=49584 visible=true timestamp=2010-07-18T18:53:48Z version=24 changeset=5253787 user=ToineToine uid=313558 member type=way ref=24301382 role=/ member type=way ref=26167773 role=/ (...) member type=way ref=30967781 role=/ member type=way ref=30988827 role=/ tag k=admin_level v=7/ tag k=boundary v=administrative/ tag k=name v=Saint-Quentin-en-Yvelines/ tag k=type v=boundary/ /relation pour la convertir dans le modèle que j'imagine, il y a très peu à changer : - supprimer admin_level=7 - changer boundary=administrative en boundary=local_authority (ou autre si on trouve mieux) - ajouter les tags relatifs à la nature et aux compétences de l'EPCI ...et c'est tout. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Petite clarification. Ce qui me gêne c'est l'utilisation qu'il en fait en Espagne et en Pologne où les données géométriques sont mélangées avec des relations avec le rôle subarea. Pour moi cela n'a aucun sens. Dans le cas d'une relation boundary, si les données géo ne sont pas mélangées, ça ne me gêne pas. Emilie Laffray On 25 Sep 2010 12:28, Benoît ROUSSEAU adressepossi...@free.fr wrote: ___ 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] niveaux admin_level=7 (était : Limites,, communales)
compris. Le 25/09/2010 19:10, Emilie Laffray a crit: Petite clarification. Ce qui me gne c'est l'utilisation qu'il en fait en Espagne et en Pologne o les donnes gomtriques sont mlanges avec des relations avec le rle subarea. Pour moi cela n'a aucun sens. Dans le cas d'une relation boundary, si les donnes go ne sont pas mlanges, a ne me gne pas. Emilie Laffray On 25 Sep 2010 12:28, "Benot ROUSSEAU" adressepossi...@free.fr wrote: ___ 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 Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.856 / Base de donnes virale: 271.1.1/3158 - Date: 09/25/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 25/09/2010 17:24, Vincent de Chateau-Thierry a crit: Le 25/09/2010 16:51, Benot ROUSSEAU a crit : Autre proposition : Actuellement pour les limites administratives des communes ont utilise quelque chose : des way dcrits comme suit : way id="34630977" visible="true" timestamp="2009-05-17T13:35:16Z" version="1" changeset="1221617" user="monsieur a" uid="97101" nd ref="393099429" / nd ref="393099430" / nd ref="393099441" / nd ref="393099442" / nd ref="393099443" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="source" v="cadastre-dgi-fr source : Direction Gnrale des Impts - Cadastre ; mise jour : 2008" / /way des relations d'appartenance dcrites comme suit : relation id="132343" visible="true" timestamp="2009-12-10T20:34:46Z" version="6" changeset="3344785" user="MrsPeel" uid="206119" member type="way" ref="34283363" role="" / member type="way" ref="34283360" role="" / member type="way" ref="34330022" role="" / member type="way" ref="34393976" role="" / member type="way" ref="34630977" role="" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Quinay" / tag k="ref:INSEE" v="86204" / tag k="source:ref:INSEE" v="COG" / tag k="type" v="boundary" / /relation relation id="145018" visible="true" timestamp="2009-11-09T11:58:47Z" version="4" changeset="3072415" user="EtienneChoveBot" uid="183561" member type="way" ref="34330016" role="" / member type="way" ref="34630977" role="" / member type="way" ref="34517049" role="" / member type="way" ref="34330421" role="" / member type="way" ref="34517047" role="" / member type="way" ref="34630990" role="" / tag k="addr:postcode" v="86580" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Vouneuil-sous-Biard" / tag k="ref:INSEE" v="86297" / tag k="source:addr:postcode" v="source of postcode is from osm nodes" / tag k="source:ref:INSEE" v="source of ref is from osm nodes" / tag k="type" v="boundary" / /relation Pourquoi ne pas simplement ajouter des relations com2com comme suit avec un tag "nature" (les anglophones traduiront) pour les distingues des communes au mme niveau et ca rsout le pb : relation id="145019" visible="true" timestamp="2009-11-09T11:58:48Z" version="4" changeset="30724185" user="quidam" uid="1883561" member type="way" ref="34630977" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Communaut de communes du val machin" / tag k="ref:INSEE" v="xxx" / tag k="type" v="boundary" / tag k="nature" v="EPCI" / /relation Ca ne change quasiment rien au schma actuel puisque c'est de la mme veine que le tag natural=coastline. Pas de region pas de subarea, ... et si j'ai bien compris c'est la proposition exprime par Vincent de Chteau-Thierry. Euh...:-) Une diffrence avec ce que je propose, c'est que dans une relation com'com base sur des limites, il faut le tag type=boundary (puisqu'on parle de limites), mais il ne faut surtout pas boundary=administative. D'o ma proposition de boundary=local_authority. Aprs oui, si on regarde par exemple la dfinition actuelle de Saint-Quentin-en-Yvelines : relation id="49584" visible="true" timestamp="2010-07-18T18:53:48Z" version="24" changeset="5253787" user="ToineToine" uid="313558"
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
2010/9/24 Pierre Quenee pierre.que...@sfr.fr En ce qui concerne les rôles : admin_center Attention à la syntaxe anglaise : admin_centre (et non admin_center). Erreur très courante, en particulier chez les français (on se demande pourquoi ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
2010/9/24 Pieren pier...@gmail.com 2010/9/24 Pierre Quenee pierre.que...@sfr.fr En ce qui concerne les rôles : admin_center Attention à la syntaxe anglaise : admin_centre (et non admin_center). Erreur très courante, en particulier chez les français (on se demande pourquoi ;-) Ou chez les américains :p Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Pieren pier...@gmail.com wrote: En ce qui concerne les rôles : admin_center Attention à la syntaxe anglaise : admin_centre (et non admin_center). Erreur très courante, en particulier chez les français (on se demande pourquoi ;-) Concernant les EPCI je crois pas que admin_centre soit pertinent ; il n'y a pas de réel centre administratif (un adresse postale c'est tout). Aucune commune n'a d'égénomie (en théorie, car souvent c'est la ville principale qui assume ce rôle). Mais la relation proposée est très intéressante. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Bonsoir, Le 24/09/2010 22:03, Pierre-Alain Dorange a écrit : Pierenpier...@gmail.com wrote: En ce qui concerne les rôles : admin_center Attention à la syntaxe anglaise : admin_centre (et non admin_center). Erreur très courante, en particulier chez les français (on se demande pourquoi ;-) Concernant les EPCI je crois pas que admin_centre soit pertinent ; il n'y a pas de réel centre administratif (un adresse postale c'est tout). Aucune commune n'a d'égénomie (en théorie, car souvent c'est la ville principale qui assume ce rôle). Mais la relation proposée est très intéressante. Oui, et à double titre, puisqu'elle permet de faire la place pour les arrondissements départementaux ;o) Pour revenir sur les propositions d'aujourd'hui, je reste partisan du modèle par limite (boundary=*) plutôt que par surface (region+subarea), pour la raison invoquée hier : la capacité de définir le périmètre de la com'com même en l'absence des limites admin de certains villes constituantes. Même si, comme le dit justement Pieren, les regroupements dans ce cas concernent bien peu de communes en comparaison de ce que regroupe un département. Néanmoins, un autre point, déjà évoqué, est celui de la cohérence de modèle. Je trouve dommage de s'éparpiller sur 2 modélisations pour, finalement, la même chose (avec quelques guillemets) : la définition d'une zone par agrégat de communes. Je ne vois pas de raison majeure pour faire de 2 manières distinctes : somme de limites versus somme de surfaces. Et l'usage boundary=* étant un consensus pour les contours administratifs à l'échelle de toute la base OSM, je trouve que ça légitime d'autant plus de continuer pour la déclinaison com'com. Maintenant s'il y a consensus sur region+subarea, je l'appliquerai, que ce soit clair, mais bon... en grognant :-) 2 autres points : - il faut prévoir la situation où l'on veut définir une com'com en l'absence de limites communales. Comment inclure une commune sans limites administatives tracées ? A priori en plaçant dans la relation com'com le node place=* qui représente la commune ? Le rôle subarea ne me plaît pas s'agissant d'un node. Peut-être peut-on laisser le node sans rôle ? - je vois dans l'exemple cobaye de Pierre Quenee ma proposition de tag local_authority. Ca n'est qu'une proposition, faut-il le rappeler. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Bonjour, Est ce que le codage des Communautés de Communes peut être codé en relation père ? par exemple : http://www.openstreetmap.org/api/0.6/relation/1187442 auquel cas l'intéret d'un niveau 7 devient relatif. En effet, si à (long) terme les communautés devait se substituer aux communes l'application du même niveau 8 pour cette structure se révélerait pertinente. Par ailleurs j'ai cru comprendre que les outils de rendu avait des problèmes avec ces structures complexes, mais est ce une raison pour ne pas les utiliser ? Quelles rôles (au sens JOSM) doit t'on appliquer à chaque membre (Validator ne semble pas aimer les roles vides) Merci pour vos éclairages ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
me demande s'il est utile Hm, ouaipch, probablement tu n'as pas tort... Peut-être vaudrait-il mieux, d'attendre voir ce qui adviendra, et s'atteler à décrire le résultat ensuite, une fois qu'ils auront décidé, au lieu de maintenant y engager la sueur du front, pour dans quelque temps devoir re-modifier ? Parfois, il peut être urgent, d'attendre. L'énergie des osm'eurs est tellement précieuse, et nous avons déjà tellement à faire, à re-caoutchouter les ways (and means...) suite aux imports en masse, à éviter que les rues traversent les maisons, éviter que l'arrêt de bus se retrouve dans l'arrière-cour, éviter que des hameaux se retrouvent dans du landuse:forest, port du casque obligatoire ? , il y a du boulot sur la planche... Oups, pardon ! c'est juste my two cents ! En aucun cas je voudrais empêcher qui que ce soit, de faire ce qu'il veut faire ! C'est simplement, que je trouverais triste, si de l'énergie précieuse soit engagée là où probablement dans deux, trois ans il faudra reprendre, et que personne pour l'instant encore ne sait ni quoi ni comment... Amicalement Gerhard --- Le 23 sept. 2010 à 00:44, Christian Rogel a écrit : Dans une discussion similaire, j'ai rappelé que l'actuelle réforme territoriale a pour ambition de supprimer le canton et de le remplacer par un territoire dans lequel serait élu un conseiller territorial. Il a été avancé que les communautés de communes (après des fusions obligatoires après 2013) pourraient être cette circonscription. De mauvaises langues disent que la réforme sera finalement sabordée. En attendant la fin de ce suspense, je me demande s'il est utile de s'intéresser à une bagarre canton versus communauté. Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Dans ce cas on arrte les routes :p "avec le nombre de projets de dviations et de constructions, ca ne sert rien". La rforme territoriale elle se fera, mais a ne rsoudra pas nos pb pour autant de prendre des dcisions quant comment l'arbre. Les mmes problmes se poseront. Benot R. Le 23/09/2010 10:09, g.d a crit: me demande s'il est utile Hm, ouaipch, probablement tu n'as pas tort... Peut-tre vaudrait-il mieux, d'attendre voir ce qui adviendra, et s'atteler dcrire le rsultat ensuite, une fois qu'ils auront dcid, au lieu de maintenant y engager la sueur du front, pour dans quelque temps devoir re-modifier ? Parfois, il peut tre urgent, d'attendre. L'nergie des osm'eurs est tellement prcieuse, et nous avons dj tellement faire, re-caoutchouter les ways (and means...) suite aux imports en masse, viter que les rues traversent les maisons, viter que l'arrt de bus se retrouve dans l'arrire-cour, viter que des hameaux se retrouvent dans du landuse:forest, "port du casque obligatoire" ? , il y a du boulot sur la planche... Oups, pardon ! c'est juste my two cents ! En aucun cas je voudrais empcher qui que ce soit, de faire ce qu'il veut faire ! C'est simplement, que je trouverais triste, si de l'nergie prcieuse soit engage l o probablement dans deux, trois ans il faudra reprendre, et que personne pour l'instant encore ne sait ni quoi ni comment... Amicalement Gerhard --- Le 23 sept. 2010 00:44, Christian Rogel a crit : Dans une discussion similaire, j'ai rappel que l'actuelle rforme territoriale a pour ambition de supprimer le canton et de le remplacer par un territoire dans lequel serait lu un conseiller territorial. Il a t avanc que les communauts de communes (aprs des fusions obligatoires aprs 2013) pourraient tre cette circonscription. De mauvaises langues disent que la rforme sera finalement saborde. En attendant la fin de ce suspense, je me demande s'il est utile de s'intresser une bagarre canton versus communaut. Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.851 / Base de donnes virale: 271.1.1/3152 - Date: 09/22/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Le 23/09/2010 09:40, Pierre Quenee a crit: Bonjour, Est ce que le codage des Communauts de Communes peut tre cod en relation pre ? par exemple : http://www.openstreetmap.org/api/0.6/relation/1187442 auquel cas l'intret d'un niveau 7 devient relatif. En effet, si (long) terme les communauts devait se substituer aux communes l'application du mme niveau 8 pour cette structure se rvlerait pertinente. Par ailleurs j'ai cru comprendre que les outils de rendu avait des problmes avec ces structures complexes, mais est ce une raison pour ne pas les utiliser ? Quelles rles (au sens JOSM) doit t'on appliquer chaque membre (Validator ne semble pas aimer les roles vides) Merci pour vos clairages ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr +5 L'ide de relation pour les communauts de communes, les communauts d'agglomrations, ... est une bonne ide qui reprsente bien la structure. Ca me semble cohrent. Le mme niveau d'admin rend bien compte de la situation actuelle ou ces communaut se substutuent sur certains point de gestion, le ramassage des ordures, les transports en commun, ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Pierre Quenee pierre.que...@sfr.fr wrote: Est ce que le codage des Communautés de Communes peut être codé en relation père ? par exemple : http://www.openstreetmap.org/api/0.6/relation/1187442 auquel cas l'intéret d'un niveau 7 devient relatif. En effet, si à (long) terme les communautés devait se substituer aux communes l'application du même niveau 8 pour cette structure se révélerait pertinente. C'est une excellente proposition. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 23 sept. 2010 à 11:23, Benoît ROUSSEAU a écrit : Dans ce cas on arrête les routes :p avec le nombre de projets de déviations et de constructions, ca ne sert à rien. La réforme territoriale elle se fera, mais ça ne résoudra pas nos pb pour autant de prendre des décisions quant à comment l'arbre. Les mêmes problèmes se poseront. Benoît R. Tu as bien raison, je pense, et, comme j'écrivis, *rien* n'empêche d'y aller, de faire. Juste être conscient que probablement ce sera à refaire de fond en comble d'ici deux ou trois ans. Fut un temps j'avais tracé, re-tracé, re-re-re-tracé les tronçons de la A 750, au fur et à mesure des modif's de chantier, aux environs de Gignac, durant un ou deux ans, jusqu'à abandon. Le tracé final ensuite a été dessiné sur osm par d'autres contributeurs (Merci à eux !). Ce n'est qu'un exemple local, délimité dans l'espace-temps. Ce que je voulais dire était, s'attaquer à un territoire grand comme la France, pour y tracer des sous-admin desquels on sait par avance que d'ici deux, trois ans ça pourrait changer complètement, pourrait peut-être être un peu prématuré. Rien n'empêche de le faire. Je n'en émets aucun jugement, loin de moi, que Dieu m'en préserve. Peut-être les cantons et circonscriptions resurgiront, mais qui sait ? Tant que là-haut ça se débat avec les principes de démocratie et ses variantes, nous ci-bas ne sommes sûrs de rien. Difficulté complémentaire étant, qu'un peu tout peut être déclaré rétroactivement, ou peut être invalidé sans que ça paraisse au JO, ça rend difficile à savoir sur quel pied danser. Mon souci pour osm au sujet cantons vs communes vs agglos vs autres regroupements simplement est, que nous sommes si peu d'osm'eurs, par rapport à la quantité de données bancales qui déjà sont dans la bdd et qui demandent d'être remis à l'endroit, que je doute qu'il soit utile d'en ajouter, quand on sait que dans peu de temps ce sera changé. Ça aurait sa valeur historique, valeurs irremplaçables, c'est sûr. On en a parlé, de faire des versions historiques de la carte, mais en pratique on n'en est pas encore là. (Il serait chouette, d'un jour avoir Cassini, voire Piri-Reis, dans osm... hm, blêmes de projection à prévoir...). Juste être conscient que rien n'est éternel. Out, over, je rends l'antenne. Gerhard. (Post scriptum : L'import sans regarder les chevauchements et superpositions insensés que ça donne, ça commence à barber. Dans beaucoup d'agglomérations, selon la carte osm, on rentre droit dans le mur. C'est quoi, ça ?! Il n'est pas la quantité de données qui ferait la qualité et utiisabilité d'une carte. Quand un higway:primary passe dans l'arrière-cour, et un bus-stop se retrouve au fond du jardin, il y a un couack. Et ce n'est pas seulement ponctuel, on en a dans quasi toutes le villes. Ça devient inquiétant. On aura pour des années, à rectifier ces bourdes grossières. Pitié ! J'abandonne. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Le 23/09/2010 13:25, Pierre-Alain Dorange a crit: Pierre Quenee pierre.que...@sfr.fr wrote: Est ce que le codage des Communauts de Communes peut tre cod en relation pre ? par exemple : http://www.openstreetmap.org/api/0.6/relation/1187442 auquel cas l'intret d'un niveau 7 devient relatif. En effet, si (long) terme les communauts devait se substituer aux communes l'application du mme niveau 8 pour cette structure se rvlerait pertinente. C'est une excellente proposition. Reste dterminer l'tiquetage ? Des propositions ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
2010/9/23 Benoît ROUSSEAU adressepossi...@free.fr Reste à déterminer l'étiquetage ? Des propositions ? Benoît R. Je suis d'accord qu'il faut revoir l' étiquetage. Avec la proposition actuelle: http://www.openstreetmap.org/browse/relation/1187442 je vois quelques problèmes dont le principal est de mélanger des relations définissant des limites (somme de frontières extérieures formant une surface) avec des regroupements de communes (somme de surfaces) en utilisant la même famille de tags (type=boundary; boundary=administrative). Donner un role=relation n'est pas suffisament distinctif ce qui pourrait compliquer leur exploitation par logiciel, amha (on ne tague pas pour les logiciels mais il faut garder une certaine cohérence tout de même; la question s'est déjà posée pour les départements, régions, etc). Un autre problème dans cette proposition est d'y avoir ajouter le code postal qui se trouve déjà dans les sous-relations. Je ne sais pas si la création de communautés de communes implique toujours la fusion en un seul code postal mais les codes postaux devraient figurer dans une seule relation à la fois pour éviter les risques d'incohérences ultérieures. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
2010/9/23 Pieren pier...@gmail.com 2010/9/23 Benoît ROUSSEAU adressepossi...@free.fr Reste à déterminer l'étiquetage ? Des propositions ? Benoît R. Je suis d'accord qu'il faut revoir l' étiquetage. Avec la proposition actuelle: http://www.openstreetmap.org/browse/relation/1187442 je vois quelques problèmes dont le principal est de mélanger des relations définissant des limites (somme de frontières extérieures formant une surface) avec des regroupements de communes (somme de surfaces) en utilisant la même famille de tags (type=boundary; boundary=administrative). Donner un role=relation n'est pas suffisament distinctif ce qui pourrait compliquer leur exploitation par logiciel, amha (on ne tague pas pour les logiciels mais il faut garder une certaine cohérence tout de même; la question s'est déjà posée pour les départements, régions, etc). Un autre problème dans cette proposition est d'y avoir ajouter le code postal qui se trouve déjà dans les sous-relations. Je ne sais pas si la création de communautés de communes implique toujours la fusion en un seul code postal mais les codes postaux devraient figurer dans une seule relation à la fois pour éviter les risques d'incohérences ultérieures. Il faut noter que la Pologne et l'espagne utilise des relations subarea. Je ne suis pas tres fan de cela mais cela est fait. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Le 23/09/2010 14:44, Pieren a crit: 2010/9/23 Benot ROUSSEAU adressepossi...@free.fr Reste dterminer l'tiquetage ? Des propositions ? Benot R. Je suis d'accord qu'il faut revoir l' "tiquetage". Avec la proposition actuelle: http://www.openstreetmap.org/browse/relation/1187442 je vois quelques problmes dont le principal est de mlanger des relations dfinissant des limites (somme de frontires extrieures formant une surface) avec des regroupements de communes (somme de surfaces) en utilisant la mme famille de tags (type=boundary; boundary=administrative). Donner un "role=relation" n'est pas suffisament distinctif ce qui pourrait compliquer leur exploitation par logiciel, amha (on ne tague pas pour les logiciels mais il faut garder une certaine cohrence tout de mme; la question s'est dj pose pour les dpartements, rgions, etc). Un autre problme dans cette proposition est d'y avoir ajouter le code postal qui se trouve dj dans les sous-relations. Je ne sais pas si la cration de communauts de communes implique toujours la fusion en un seul code postal mais les codes postaux devraient figurer dans une seule relation la fois pour viter les risques d'incohrences ultrieures. Pieren Tout a fait d'accord, le type "boundary" ne convient pas. Pour les surfaces il y aurait "area". De mme pour le code postal qui n'a rien faire ici. Par contre l'INSSE donne un code EPCI pour ces regroupement dans le document tlchargeable ici : http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637IdSousTheme=2IdSource=NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France. Ce code pourrait tre inclu. Il faudrait, a discuter, voir en terme de groupement, car relation exprime un regroupement administratif de territoires. Ce n'est pas une description gomtrique qui est dj dfinie par les limites des communes concernes. Je ne pense donc pas qu'il faille dfinir un contour pour les communauts de communes car 1- il est intrinsque 2 - les communaut de communes changes relativement rapidement. Utiliser une relation permet d'inclure ou d'exclure des communes facilement. J'arrte le franglish = un truc type=groupe ou groupement_administratif seraient ils trop simples et pas assez descriptif ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Bonsoir, Le 23/09/2010 15:25, Benoît ROUSSEAU a écrit : Le 23/09/2010 14:44, Pieren a écrit : 2010/9/23 Benoît ROUSSEAU adressepossi...@free.fr mailto:adressepossi...@free.fr Reste à déterminer l'étiquetage ? Des propositions ? Benoît R. Je suis d'accord qu'il faut revoir l' étiquetage. Avec la proposition actuelle: http://www.openstreetmap.org/browse/relation/1187442 je vois quelques problèmes dont le principal est de mélanger des relations définissant des limites (somme de frontières extérieures formant une surface) avec des regroupements de communes (somme de surfaces) en utilisant la même famille de tags (type=boundary; boundary=administrative). Donner un role=relation n'est pas suffisament distinctif ce qui pourrait compliquer leur exploitation par logiciel, amha (on ne tague pas pour les logiciels mais il faut garder une certaine cohérence tout de même; la question s'est déjà posée pour les départements, régions, etc). Je suis d'accord avec ça. Je penche pour le recours à la même modélisation que celle utilisée pour les départements, à savoir une somme de ways qui forment un contour. Il y a la raison de cohérence que donne Pieren, et j'en ajouterai une autre : avoir une somme de limites / bordures permet de définir l'emprise complète du territoire sans disposer de tous ses constituants. L'exemple des départements plaide pour ça : on a aujourd'hui la définition des limites de tous les départements, tout en ayant (et de loin :-( ) pas encore toutes les limites de communes. Si on avait défini les départements comme des sommes de surfaces communales, on ne saurait pas proposer un découpage départemental complet de la France. Et encore pour un petit bout de temps... Un autre problème dans cette proposition est d'y avoir ajouter le code postal qui se trouve déjà dans les sous-relations. Je ne sais pas si la création de communautés de communes implique toujours la fusion en un seul code postal mais les codes postaux devraient figurer dans une seule relation à la fois pour éviter les risques d'incohérences ultérieures. Autant que je sache, il n'y a pas de fusion des CPs à la création d'une communauté de communes. Et si cela arrive, ça n'est pas une règle. En France, hormis pour quelques communes avec plusieurs codes postaux, le niveau commuune entière reste le plus pertinent pour stocker cette info. donc dans osm la relation d'admin_level=8 Tout a fait d'accord, le type boundary ne convient pas. Pour les surfaces il y aurait area. De même pour le code postal qui n'a rien à faire ici. Par contre l'INSSE donne un code EPCI pour ces regroupement dans le document téléchargeable ici : http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637IdSousTheme=2IdSource=NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637IdSousTheme=2IdSource=NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France. Ce code pourrait être inclu. Chouette, un nouveau ref:INSEE :-) Il faudrait, a discuter, voir en terme de groupement, car relation exprime un regroupement administratif de territoires. Ce n'est pas une description géométrique qui est déjà définie par les limites des communes concernées. Je ne pense donc pas qu'il faille définir un contour pour les communautés de communes car 1- il est intrinsèque 2 - les communauté de communes changes relativement rapidement. Utiliser une relation permet d'inclure ou d'exclure des communes facilement. Plutôt pas d'accord (voir + haut) J'arrête le franglish = un truc type=groupe ou groupement_administratif seraient ils trop simples et pas assez descriptif ? En modélisant le contour plutôt que la surface, je proposais hier boundary=local_authority, qui se traduit plus ou moins par collectivité locale, ce qui, j'en conviens, ne tombe pas pile sur ce qu'on veut décrire. Ce sera bien de trouver autre chose. Je pense par ailleurs qu'on n'échappera pas à un espace de noms du style local_authority:FR un peu sur le modèle de school:FR si on veut introduire la typologie des EPCI (cf. doc de l'INSEE ci-dessus) : Les communautés urbaines (CU), communautés d'agglomération (CA), communautés de communes (CC), syndicats d'agglomération nouvelle (SAN) Donc tout ça nous fait au moins 2 points à trancher : modélisation par limites ou par surface, et vocabulaire des tags. A vous lire, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Au passage, il serait profitable de trouver une meilleure définition pour ces communautés de communes que boundary=administrative / admin_level=7, histoire de pouvoir affecter cet admin_level aux arrondissements départementaux (= les subdivisions départementales par sous-préfecture). On pourrait redéfinir les niveaux en passant les départements à admin_level=5, les arrondissements à : admin_level=6, et les communautés de communes (et CA et CU) à : admin_level=7 ? Mais existe-t-il des communautés de communes à cheval sur plusieurs arrondissements ? Comment les gérer ? et il y a aussi des découpages qui ne sont pas administratifs mais électoraux, y aurait-il possibilité de les définir ? cf Wikipedia : http://fr.wikipedia.org/wiki/Circonscriptions_%C3%A9lectorales_(France) - les cantons (pour les conseillers généraux), qui ne suivent pas toujours les contours des communes - les circonscriptions législatives (pour les députés), qui ne suivent ni toujours les contours des communes, ni toujours ceux des cantons - les grandes régions des élections européennes (qui suivent les bords de régions, ouf !) Peut-être un boundary=electoral_district ? Damien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
De : Damouns Au passage, il serait profitable de trouver une meilleure définition pour ces communautés de communes que boundary=administrative / admin_level=7, histoire de pouvoir affecter cet admin_level aux arrondissements départementaux (= les subdivisions départementales par sous-préfecture). On pourrait redéfinir les niveaux en passant les départements à admin_level=5, les arrondissements à : admin_level=6, et les communautés de communes (et CA et CU) à : admin_level=7 ? Mais existe-t-il des communautés de communes à cheval sur plusieurs arrondissements ? Comment les gérer ? et il y a aussi des découpages qui ne sont pas administratifs mais électoraux, y aurait-il possibilité de les définir ? cf Wikipedia : http://fr.wikipedia.org/wiki/Circonscriptions_%C3%A9lectorales_(France) - les cantons (pour les conseillers généraux), qui ne suivent pas toujours les contours des communes - les circonscriptions législatives (pour les députés), qui ne suivent ni toujours les contours des communes, ni toujours ceux des cantons - les grandes régions des élections européennes (qui suivent les bords de régions, ouf !) Peut-être un boundary=electoral_district ? Le problème, c'est que la logique arborescente des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empêche des communes de départements différents de se regrouper au sein d'une communauté. Par exemple les Hauts-de-Bièvre : http://www.agglo-hautsdebievre.fr/index.php?option=com_contentview=articleid=1Itemid=33 sont à cheval sur le 91 et le 92. En France, on a à chaque admin_level une partition de l'espace : la somme des boundary=administrative de ce level permet de reconstituer l'ensemble du territoire. Inversement, aucun endroit du territoire n'appartient à deux entités différentes de même admin_level. Un département n'appartient qu'à une région, par ex. Partant de ça, pour mon exemple des Hauts-de-Bièvre, ça coince. Ca n'est ni complètement dans le 92, ni complètement dans le 91, et ça empiète sur chacun d'eux. Bref ça n'a pas sa place dans les branches de l'arbre administratif. Donc à mon sens, le débat sur les tags des communautés d'agglo, c'est surtout pour définir le type de boundary (implicitement autre que administrative) qu'il faudrait leur coller. Ensuite, les raffinements devraient porter sur les compétences propres à chaque agglo (transports, voirie, etc.). Un peu de lecture ici : http://fr.wikipedia.org/wiki/Communaut%C3%A9_de_communes vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/10, Damouns damo...@gmail.com a écrit : Au passage, il serait profitable de trouver une meilleure définition pour ces communautés de communes que boundary=administrative / admin_level=7, histoire de pouvoir affecter cet admin_level aux arrondissements départementaux (= les subdivisions départementales par sous-préfecture). On pourrait redéfinir les niveaux en passant les départements à admin_level=5, les arrondissements à : admin_level=6, et les communautés de communes (et CA et CU) à : admin_level=7 ? Mais existe-t-il des communautés de communes à cheval sur plusieurs arrondissements ? Comment les gérer ? La communauté de commune CAP Atlantique (déjà dans OSM) regroupe des communes de Loire-Atlantique et d'Ille-et-Vilaine. Pas le même département ni la même région. Elle est taguée en admin_level=7. Si on met de côté l'aspect hiérarchique, dans OSM ça marche ! On peut imaginer pour cette entité remplacer admin_level un admin_struture=Communauté d'agglomération. Wikipédia me signale également : la communauté de communes la communauté urbaine le SIVU et le SIVOM le syndicat mixte le pays le SICTOM ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Vincent de Chateau-Thierry v...@laposte.net wrote: Le problème, c'est que la logique arborescente des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empêche des communes de départements différents de se regrouper au sein d'une communauté. En effet mais il en va un peu de même pour les cantons par exemple. De plus cette logique arborescente qui existe pour certains admin_level n'est pas définit (je n'en trouve pas de traces dans le wiki). Certes c'est pratique et ça parait logique et plus simple, mais est-ce une nécessité des admin_level ? Mais (voir mon autre message dans l'ancienne enfilade) les intercommunalités ont aussi des caractéristiques différentes des autres : les représentants ne sont pas élus au suffrage direct (mais ça pourrait changer un jour), la division ne me semble pas administrative (dans le sens décidé par l'administration) ; il s'agit de regroupement autour de compétences. L'autre problème c'est de placer les cantons et arrondissement qui vont aussi entre le département et la commune... -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/2010 20:26, Pierre-Alain Dorange a crit: Vincent de Chateau-Thierry v...@laposte.net wrote: Le problme, c'est que la logique "arborescente" des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empche des communes de dpartements diffrents de se regrouper au sein d'une communaut. En effet mais il en va un peu de mme pour les cantons par exemple. De plus cette "logique" arborescente qui existe pour certains admin_level n'est pas dfinit (je n'en trouve pas de traces dans le wiki). Certes c'est pratique et a parait logique et plus simple, mais est-ce une ncessit des admin_level ? Mais (voir mon autre message dans l'ancienne enfilade) les intercommunalits ont aussi des caractristiques diffrentes des autres : les reprsentants ne sont pas lus au suffrage direct (mais a pourrait changer un jour), la division ne me semble pas administrative (dans le sens dcid par l'administration) ; il s'agit de regroupement autour de comptences. L'autre problme c'est de placer les cantons et arrondissement qui vont aussi entre le dpartement et la commune... A mon sens les cantons ne sont pas des "admin_level" au sens administratif, mais lectoral. La partie administrative est le dpartement pour les cantons, car les conseillers gnraux sigent au Conseil gnral. Ce sont des reprsentants politiques, pas des des fonctionnaires dans cette fonction (mme s'il peuvent l'tre par ailleurs). C'est le Conseil gnral qui gre administrativement, selon ses prrogatives, le dpartement dont la population est reprsente par des lus de fractions lectorales de ce territoire. Mme si les conseillers municipaux sont lus sur des secteurs lectoraux ont ne tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a proprement parler des admin_level, sauf si les conseils de quartiers... sont lgalement obligatoires et on un rle administratif (je ne sais pas vrifier). Les Sous-prfectures avec leurs arrondissements administratifs oui, c'est une fraction de territoire de police, avec des fonctionnaires. A ce titre, les Acadmies auraient plus leur place, en admin_level, que les cantons. Les Acadmies sont bien des fractions administratives de l'tat, elles dterminent, par exemple, par ricoch les priodes de congs scolaires, l'endroit o inscrire les enfants l'cole publique, ... Le dcoupage lectoral ne suit pas le dcoupage administratif, nous sommes tous d'accord. Mais c'est mon avis une erreur de vouloir les intgrer au niveau d'admin_level il faudrait un dcoupage lectoral part, qui existe je crois. D'ailleurs on risque d'avoir le mme pb l'inverse quand on voudra monter le dcoupage lectoral, des morceaux seront en admin_level, les autres en "electoral_level", ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/2010 21:32, Benot ROUSSEAU a crit: Le 22/09/2010 20:26, Pierre-Alain Dorange a crit: Vincent de Chateau-Thierry v...@laposte.net wrote: Le problme, c'est que la logique "arborescente" des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empche des communes de dpartements diffrents de se regrouper au sein d'une communaut. En effet mais il en va un peu de mme pour les cantons par exemple. De plus cette "logique" arborescente qui existe pour certains admin_level n'est pas dfinit (je n'en trouve pas de traces dans le wiki). Certes c'est pratique et a parait logique et plus simple, mais est-ce une ncessit des admin_level ? Mais (voir mon autre message dans l'ancienne enfilade) les intercommunalits ont aussi des caractristiques diffrentes des autres : les reprsentants ne sont pas lus au suffrage direct (mais a pourrait changer un jour), la division ne me semble pas administrative (dans le sens dcid par l'administration) ; il s'agit de regroupement autour de comptences. L'autre problme c'est de placer les cantons et arrondissement qui vont aussi entre le dpartement et la commune... A mon sens les cantons ne sont pas des "admin_level" au sens administratif, mais lectoral. La partie administrative est le dpartement pour les cantons, car les conseillers gnraux sigent au Conseil gnral. Ce sont des reprsentants politiques, pas des des fonctionnaires dans cette fonction (mme s'il peuvent l'tre par ailleurs). C'est le Conseil gnral qui gre administrativement, selon ses prrogatives, le dpartement dont la population est reprsente par des lus de fractions lectorales de ce territoire. Mme si les conseillers municipaux sont lus sur des secteurs lectoraux ont ne tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a proprement parler des admin_level, sauf si les conseils de quartiers... sont lgalement obligatoires et on un rle administratif (je ne sais pas vrifier). Les Sous-prfectures avec leurs arrondissements administratifs oui, c'est une fraction de territoire de police, avec des fonctionnaires. A ce titre, les Acadmies auraient plus leur place, en admin_level, que les cantons. Les Acadmies sont bien des fractions administratives de l'tat, elles dterminent, par exemple, par ricoch les priodes de congs scolaires, l'endroit o inscrire les enfants l'cole publique, ... Le dcoupage lectoral ne suit pas le dcoupage administratif, nous sommes tous d'accord. Mais c'est mon avis une erreur de vouloir les intgrer au niveau d'admin_level il faudrait un dcoupage lectoral part, qui existe je crois. D'ailleurs on risque d'avoir le mme pb l'inverse quand on voudra monter le dcoupage lectoral, des morceaux seront en admin_level, les autres en "electoral_level", ... Benot R. Je poursuis avec un complment... Quant au n de niveau administratif, vouloir "emboiter" les niveaux comme des poupes russes avec un seul type par niveau est une erreur. Si on prends Acadmie et prfecture (sauf erreur - mais qu'importe pour la dmo) elle devrait tre au mme niveau, l'une est juste sous l'tat France par le Ministre de l'ducation, l'autre par le Ministre de l'intrieur. Et il existe d'autres dcoupages administratifs, comme par exemple celui des centres d'impts, qui ne correspond aucun autre, ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
2010/9/22 Benoît ROUSSEAU adressepossi...@free.fr A mon sens les cantons ne sont pas des admin_level au sens administratif, mais électoral. La partie administrative est le département pour les cantons, car les conseillers généraux siègent au Conseil général. Ce sont des représentants politiques, pas des des fonctionnaires dans cette fonction (même s'il peuvent l'être par ailleurs). C'est le Conseil général qui gère administrativement, selon ses prérogatives, le département dont la population est représentée par des élus de fractions électorales de ce territoire. Même si les conseillers municipaux sont élus sur des secteurs électoraux ont ne tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a proprement parler des admin_level, sauf si les conseils de quartiers... sont légalement obligatoires et on un rôle administratif (je ne sais pas à vérifier). Les Sous-préfectures avec leurs arrondissements administratifs oui, c'est une fraction de territoire de police, avec des fonctionnaires. A ce titre, les Académies auraient plus leur place, en admin_level, que les cantons. Les Académies sont bien des fractions administratives de l'état, elles déterminent, par exemple, par ricoché les périodes de congés scolaires, l'endroit où inscrire les enfants à l'école publique, ... Le découpage électoral ne suit pas le découpage administratif, nous sommes tous d'accord. Mais c'est à mon avis une erreur de vouloir les intégrer au niveau d'admin_level il faudrait un découpage électoral à part, qui existe je crois. D'ailleurs on risque d'avoir le même pb à l'inverse quand on voudra monter le découpage électoral, des morceaux seront en admin_level, les autres en electoral_level, ... boundary = political admin_level = * peut etre? Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/2010 21:43, Benoît ROUSSEAU a écrit : Le 22/09/2010 21:32, Benoît ROUSSEAU a écrit : Le 22/09/2010 20:26, Pierre-Alain Dorange a écrit : Vincent de Chateau-Thierry v...@laposte.net wrote: Le problème, c'est que la logique arborescente des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empêche des communes de départements différents de se regrouper au sein d'une communauté. En effet mais il en va un peu de même pour les cantons par exemple. De plus cette logique arborescente qui existe pour certains admin_level n'est pas définit (je n'en trouve pas de traces dans le wiki). Certes c'est pratique etça parait logique et plus simple, mais est-ce une nécessité des admin_level ? Mais (voir mon autre message dans l'ancienne enfilade) les intercommunalités ont aussi des caractéristiques différentes des autres : les représentants ne sont pasélus au suffrage direct (maisça pourrait changer un jour), la division ne me semble pas administrative (dans le sens décidé par l'administration) ; il s'agit de regroupement autour de compétences. L'autre problème c'est de placer les cantons et arrondissement qui vont aussi entre le département et la commune... A mon sens les cantons ne sont pas des admin_level au sens administratif, mais électoral. La partie administrative est le département pour les cantons, car les conseillers généraux siègent au Conseil général. Ce sont des représentants politiques, pas des des fonctionnaires dans cette fonction (même s'il peuvent l'être par ailleurs). C'est le Conseil général qui gère administrativement, selon ses prérogatives, le département dont la population est représentée par des élus de fractions électorales de ce territoire. Même si les conseillers municipaux sont élus sur des secteurs électoraux ont ne tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a proprement parler des admin_level, sauf si les conseils de quartiers... sont légalement obligatoires et on un rôle administratif (je ne sais pas à vérifier). Les Sous-préfectures avec leurs arrondissements administratifs oui, c'est une fraction de territoire de police, avec des fonctionnaires. A ce titre, les Académies auraient plus leur place, en admin_level, que les cantons. Les Académies sont bien des fractions administratives de l'état, elles déterminent, par exemple, par ricoché les périodes de congés scolaires, l'endroit où inscrire les enfants à l'école publique, ... Le découpage électoral ne suit pas le découpage administratif, nous sommes tous d'accord. Mais c'est à mon avis une erreur de vouloir les intégrer au niveau d'admin_level il faudrait un découpage électoral à part, qui existe je crois. D'ailleurs on risque d'avoir le même pb à l'inverse quand on voudra monter le découpage électoral, des morceaux seront en admin_level, les autres en electoral_level, ... Benoît R. Je poursuis avec un complément... Quant au n° de niveau administratif, vouloir emboiter les niveaux comme des poupées russes avec un seul type par niveau est une erreur. Si on prends Académie et préfecture (sauf erreur - mais qu'importe pour la démo) elle devrait être au même niveau, l'une est juste sous l'état France par le Ministère de l'éducation, l'autre par le Ministère de l'intérieur. Et il existe d'autres découpages administratifs, comme par exemple celui des centres d'impôts, qui ne correspond à aucun autre, ... Benoît R. Il y a en effet bien plus qu'une manière de subdiviser le territoire : Les Académies, les régions militaires, etc. Pour faire simple, je pense qu'on peut apparenter l'idée des admin_level d'osm, pour la France, à ce qui est consultable ici : http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp c'est à dire la représentation imbriquée des différents niveaux de découpage donnés par le COG [1]. C'est en tout cas ce que reflète le wiki. Sur le caractère arborescent, le wiki ne dit rien explicitement, en effet, mais il parle de hiérarchie. La modélisation en arbre des différents niveaux administratifs n'est pas nouvelle dans les bases de données géographiques. On trouve dans les documentations des éditeurs commerciaux à peu près exactement la même littérature que les grands tableaux de la page admin_level du wiki [2] . Le but est toujours le même : tenter d'harmoniser à un niveau international les spécificités nationales, de manière à ce que des applications clientes de ces contenus puissent les utiliser de façon homogène d'un pays à l'autre. vincent [1] : http://fr.wikipedia.org/wiki/Code_officiel_g%C3%A9ographique [2] : http://wiki.openstreetmap.org/wiki/Admin_level ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Vincent de Chateau-Thierry v...@laposte.net wrote: Il y a en effet bien plus qu'une manière de subdiviser le territoire : Les Académies, les régions militaires, etc. Pour faire simple, je pense qu'on peut apparenter l'idée des admin_level d'osm, pour la France, à ce qui est consultable ici : http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp c'est à dire la représentation imbriquée des différents niveaux de découpage donnés par le COG [1]. C'est en tout cas ce que reflète le wiki. Pas tout à fait puisque la COG imbrique Région Département Arrondissement Canton Commune Les admin_level actuels (wiki) n'ont rien pour les cantons et arrondissements. Les intercommunalités sont probablement a gérer à part, ainsi que les autres frontières évoqués : académie (qui n'ont qu'un sens très restreint) ou région militaire. On peut ajouter les bassins hydrauliques ou les massifs comme exemple géographique pur. Arrondissement de la Charente (COG) : http://insee.fr/fr/methodes/nomenclatures/cog/carte_arrdep.asp?codedep=1 6 et cantons de l'arrondissement de Cognac : http://insee.fr/fr/methodes/nomenclatures/cog/carte_canarr.asp?codearr= 162 Dans les exemples (de mon coin) ci-dessus de la COG on notera que le cas des cantons nord et sud de Cognac (la vilel est coupé sur 2 cantons) sont évacués sur la carte qui représentent les cantons Nord et Sud sans inclure la ville de Cognac qui est graphiquement représenté comme une commune à part (appartenant au 2 cantons à la fois) -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/2010 23:26, Pierre-Alain Dorange a écrit : Vincent de Chateau-Thierry v...@laposte.net wrote: Il y a en effet bien plus qu'une manière de subdiviser le territoire : Les Académies, les régions militaires, etc. Pour faire simple, je pense qu'on peut apparenter l'idée des admin_level d'osm, pour la France, à ce qui est consultable ici : http://insee.fr/fr/methodes/nomenclatures/cog/carte_regions.asp c'est à dire la représentation imbriquée des différents niveaux de découpage donnés par le COG [1]. C'est en tout cas ce que reflète le wiki. Pas tout à fait puisque la COG imbrique Région Département Arrondissement Canton Commune Les admin_level actuels (wiki) n'ont rien pour les cantons et arrondissements. Pour les arrondissements, on essaie justement d'y remédier :-) Pour les cantons, ça reste comme déjà dit par Benoît un découpage à part. On peut avoir plusieurs communes dans un canton, mais aussi plusieurs cantons dans une commune, donc difficile à ranger de manière homogène. Les intercommunalités sont probablement a gérer à part, ainsi que les autres frontières évoqués : académie (qui n'ont qu'un sens très restreint) ou région militaire. On peut ajouter les bassins hydrauliques ou les massifs comme exemple géographique pur. Reste (au moins pour les interco) à leur trouver le(s) tag(s) ad'hoc. Est-ce que boundary=local_authority irait pour commencer ? Merci aux anglophones de corriger/améliorer... Arrondissement de la Charente (COG) : http://insee.fr/fr/methodes/nomenclatures/cog/carte_arrdep.asp?codedep=1 6 et cantons de l'arrondissement de Cognac : http://insee.fr/fr/methodes/nomenclatures/cog/carte_canarr.asp?codearr= 162 Dans les exemples (de mon coin) ci-dessus de la COG on notera que le cas des cantons nord et sud de Cognac (la vilel est coupé sur 2 cantons) sont évacués sur la carte qui représentent les cantons Nord et Sud sans inclure la ville de Cognac qui est graphiquement représenté comme une commune à part (appartenant au 2 cantons à la fois) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Dans une discussion similaire, j'ai rappelé que l'actuelle réforme territoriale a pour ambition de supprimer le canton et de le remplacer par un territoire dans lequel serait élu un conseiller territorial. Il a été avancé que les communautés de communes (après des fusions obligatoires après 2013) pourraient être cette circonscription. De mauvaises langues disent que la réforme sera finalement sabordée. En attendant la fin de ce suspense, je me demande s'il est utile de s'intéresser à une bagarre canton versus communauté. Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/2010 22:56, Vincent de Chateau-Thierry a crit: Le 22/09/2010 21:43, Benot ROUSSEAU a crit : Le 22/09/2010 21:32, Benot ROUSSEAU a crit : Le 22/09/2010 20:26, Pierre-Alain Dorange a crit : Vincent de Chateau-Thierry v...@laposte.net wrote: Le problme, c'est que la logique "arborescente" des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empche des communes de dpartements diffrents de se regrouper au sein d'une communaut. En effet mais il en va un peu de mme pour les cantons par exemple. De plus cette "logique" arborescente qui existe pour certains admin_level n'est pas dfinit (je n'en trouve pas de traces dans le wiki). Certes c'est pratique eta parait logique et plus simple, mais est-ce une ncessit des admin_level ? Mais (voir mon autre message dans l'ancienne enfilade) les intercommunalits ont aussi des caractristiques diffrentes des autres : les reprsentants ne sont paslus au suffrage direct (maisa pourrait changer un jour), la division ne me semble pas administrative (dans le sens dcid par l'administration) ; il s'agit de regroupement autour de comptences. L'autre problme c'est de placer les cantons et arrondissement qui vont aussi entre le dpartement et la commune... A mon sens les cantons ne sont pas des "admin_level" au sens administratif, mais lectoral. La partie administrative est le dpartement pour les cantons, car les conseillers gnraux sigent au Conseil gnral. Ce sont des reprsentants politiques, pas des des fonctionnaires dans cette fonction (mme s'il peuvent l'tre par ailleurs). C'est le Conseil gnral qui gre administrativement, selon ses prrogatives, le dpartement dont la population est reprsente par des lus de fractions lectorales de ce territoire. Mme si les conseillers municipaux sont lus sur des secteurs lectoraux ont ne tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a proprement parler des admin_level, sauf si les conseils de quartiers... sont lgalement obligatoires et on un rle administratif (je ne sais pas vrifier). Les Sous-prfectures avec leurs arrondissements administratifs oui, c'est une fraction de territoire de police, avec des fonctionnaires. A ce titre, les Acadmies auraient plus leur place, en admin_level, que les cantons. Les Acadmies sont bien des fractions administratives de l'tat, elles dterminent, par exemple, par ricoch les priodes de congs scolaires, l'endroit o inscrire les enfants l'cole publique, ... Le dcoupage lectoral ne suit pas le dcoupage administratif, nous sommes tous d'accord. Mais c'est mon avis une erreur de vouloir les intgrer au niveau d'admin_level il faudrait un dcoupage lectoral part, qui existe je crois. D'ailleurs on risque d'avoir le mme pb l'inverse quand on voudra monter le dcoupage lectoral, des morceaux seront en admin_level, les autres en "electoral_level", ... Benot R. Je poursuis avec un complment... Quant au n de niveau administratif, vouloir "emboiter" les niveaux comme des poupes russes avec un seul type par niveau est une erreur. Si on prends Acadmie et prfecture (sauf erreur - mais qu'importe pour la dmo) elle devrait tre au mme niveau, l'une est juste sous
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Bonjour, Le 23/09/2010 00:44, Christian Rogel a écrit : Dans une discussion similaire, j'ai rappelé que l'actuelle réforme territoriale a pour ambition de supprimer le canton et de le remplacer par un territoire dans lequel serait élu un conseiller territorial. Il a été avancé que les communautés de communes (après des fusions obligatoires après 2013) pourraient être cette circonscription. De mauvaises langues disent que la réforme sera finalement sabordée. En attendant la fin de ce suspense, je me demande s'il est utile de s'intéresser à une bagarre canton versus communauté. bagarre ?? Le fait est que les 2 notions (cantons et com'com) existent aujourd'hui et obéissent chacune à leur logique. En tant que découpages géographiques, elles ont à mon sens toutes les 2 leur place dans osm dès lors qu'on saura (saurait) les qualifier avec des tags appropriés. Le début de la discussion provient justement du caractère inapproprié -à mon avis- de l'admin_level 7 pour les com'com. Bien les tagguer permettrait de libérer l'admin_level 7 pour les arrondissements départementaux. Concernant les cantons, pourquoi pas les ranger eux aussi à part, en utilisant le boundary=political déjà suggéré. Il y en a 89 dans la base actuellement : http://tagwatch.stoecker.eu/Planet/En/tagstats_boundary_political.html qui semblent plutôt des initiatives individuelles qu'une démarche consensuelle : http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Vincent de Chateau-Thierry v...@laposte.net wrote: Le fait est que les 2 notions (cantons et com'com) existent aujourd'hui et obéissent chacune à leur logique. En tant que découpages géographiques, elles ont à mon sens toutes les 2 leur place dans osm dès lors qu'on saura (saurait) les qualifier avec des tags appropriés. Le début de la discussion provient justement du caractère inapproprié -à mon avis- de l'admin_level 7 pour les com'com. Bien les tagguer permettrait de libérer l'admin_level 7 pour les arrondissements départementaux. +1 Concernant les cantons, pourquoi pas les ranger eux aussi à part, en utilisant le boundary=political déjà suggéré. Concernant les cantons je reste plus circonspect... La définition des Arrondissements, c'est qu'ils sont composés de Cantons... Mais je n'ai pas de solution non plus... -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
