[OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Philippe Verdy]

Il serait temps de commencer à réfléchir à la différenciation du découpage
administratif et du découpage urbain du territoire, comme le fait l'INSEE
justement.

Le premier (communes, etc.) évolue à coup de lois et décrets préfectoraux,
le second (agglomérations, zones urbaines) en fonction de l'activité et des
permis de construire ou lotir des communes (et maintenant du PLU communal
ou communautaire devenu obligatoire), mais une décision de lotir ou
construire ne signifie pas qu'il y a une occupation réelle, c'est
désynchronisé dans le temps (et des zones bâties disparaissent aussi par
des démolitions ou reconversions, y compris les démolition sur le littoral
ou les zones inondables).

Le découpage urbain de l'INSEE ne tient donc pas compte du zonage
d'aménagement des communes et de leur PLU mais de la situation réelle, pour
le découpage fin seulement, car au delà l'INSEE fait des regroupements de
communes entières (ou communes déléguées/associées) en incluant à la fois
leur domaine rural et urbain, en prenant le niveau administratif le plus
approprié pour faire ces regroupements statistiques. Ce découpage a une
finalité statistique et devrait donc être de type boundary=statistical (en
dessous du niveau des agglomérations, pour les communes les plus peuplées,
l'INSEE ajoute les RIS qu'on n'a pas encore modélisés, mais correspondent
au modèle du recensement, boundary=census_unit, mais qui ne tient pas
compte du découpage urbain mais des frontières administratives des communes
au niveau 8, ou celles des arrondissements, ou communes déléguées/associées
au niveau 9, ce découpage servant aussi en partie à délimiter les
circonscriptions électorales mais avec des exceptions notamment pour les
cantons, car les seuils dépendent des lois électorales pour "égaliser" la
population sans forcément tenir compte du découpage administratif, ou
statistique en RIS).

Vient ensuite le découpage de la réglementation routière qui définit les
"agglomérations routières" en fonction de la signalisation décidée ou
concertée par les communes et préfets. Ces agglomérations ne correspondent
pas non plus exactement aux agglomérations de l'INSEE. Ce zonage routier
(impliqué par les panneaux EB10/EB20 là où il y en a) est à part et a de
nombreuses exceptions qui ne tiennent pas du tout compte des autres
découpages, mais aussi de la nature des voies, leur équipement, les zones
de danger, la présence d'écoles ou zones sportives et de loisirs, ou encore
des nécessités environnementales.

Ce découpage des agglomérations routières pour l'instant a été tenté en
divers endroits en utilisant une relation "boundary=urban", qui ne me
semble pas être le bon tag mais dont le tracé remplit cet objectif (celui
de définit une limite de vitesse par défaut sur les voies qui y sont
incluses). Mais les limites de vitesse sont compliquées car elles sont
définies voie par voie (et même selon le sens de circulation), cela n'a pas
beaucoup de sens de délimiter des zones et il est plus simple de définir
directement le "maxspeed=*" sur les voies elles-mêmes. Si on conserve ces
relations, je verrais d'un bon oeil le changement du tag en quelque chose
de plus clair ("boundary=restriction"+"maxspeed=*").




Le mer. 12 févr. 2020 à 19:20, <osm.sanspourriel at spamgourmet.com> a écrit :

> Le 12/02/2020 à 18:02, Christian Quest - cquest at openstreetmap.fr a écrit :
>
> place=municipality est dans un tableau "administratively declared places",
> ce qui va très bien avec nos communes nouvelles rurales. Il est par contre
> très peu utilisé: quelques milliers à peine sur le monde entier !
>
> On ne va pas non plus en ajouter des milliers
> <http://taginfo.openstreetmap.fr/search?q=admin_type%3AFR%3Dcommune+nouvelle>
> (713).
>
> La troisième règle non écrite d'OSM: toujours, toujours relire le wiki ;)
>
> Relire la bonne page du wiki, car il arrive qu'on trouve des infos pas à
> jour, incomplètes (traduction françaises pas à jour) ou incohérentes avec
> d'autres pages toujours sur le wiki.
>
> Je suis pour mettre des place=municipality avec les populations qui vont
> bien sur les communes nouvelles.
>
> Je maintiens que mettre la population sur l'admin_centre c'est ambigu dans
> le cas où la commune (municipality) n'est pas uniquement urbaine : est-ce
> celle du town/village ou celles additionnées des town/village/hamlet... ?
>
> Maintenant on peut décider qu'en France :
>
> -soit les population=* ne sont mis que sur les admin_centre/label des
> communes (niveau 8 ou aussi niveau 9 ?).
> - soit que les population=* qui sont mis sur admin_centre/label des
> communes (niveau 8 ou aussi niveau 9 ?) sont ceux de l'INSEE pour la
> commune et que les éventuels autres sont des informations autres qui ne
> s'ajoutent pas au total (et donc on met place=municipality pour lever
> l'ambiguïté ? Bof, c'est bien de savoir si le bourg est un town ou un
> village). Mais alors, pourquoi avoir enlevé INSEE= sur ces nœuds ?
> - autre ?
>
> Dans le cas d'une commune nouvelle où on met place=municipality sur un
> label, pas de soucis.
>
> Jean-Yvon
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200212/151cbcc1/attachment.htm>