<div dir="ltr">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.<div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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=*").</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 12 févr. 2020 à 19:20, <<a href="mailto:osm.sanspourriel@spamgourmet.com">osm.sanspourriel@spamgourmet.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Le 12/02/2020 à 18:02, Christian Quest - <a href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>
a écrit :<br>
</p>
<blockquote type="cite">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 !
<br>
</blockquote>
On ne va pas non plus en ajouter des <a href="http://taginfo.openstreetmap.fr/search?q=admin_type%3AFR%3Dcommune+nouvelle" target="_blank">milliers</a>
(713). <br>
<blockquote type="cite">La
troisième règle non écrite d'OSM: toujours, toujours relire le
wiki <span title=";)"><span>;)</span></span></blockquote>
<p>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.</p>
<p>Je suis pour mettre des place=municipality avec les populations
qui vont bien sur les communes nouvelles.<br>
</p>
<p>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... ?</p>
<p>Maintenant on peut décider qu'en France :<br>
</p>
<p>-soit les population=* ne sont mis que sur les admin_centre/label
des communes (niveau 8 ou aussi niveau 9 ?).<br>
- 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 ?<br>
- autre ?<br>
</p>
<p>Dans le cas d'une commune nouvelle où on met place=municipality
sur un label, pas de soucis.</p>
<p>Jean-Yvon<br>
</p>
</div>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</blockquote></div>