Le jeu. 28 mai 2020 à 17:04, Rpnpif via Talk-fr <[email protected]> a écrit :
> Le 28/05/2020 à 15:29, Jean-Claude Repetto a écrit : > > Bonjour, > > > > Je réponds partiellement: > > > > Le 28/05/2020 à 14:45, Yann-Gaël LARGILLET a écrit : > >> > >> Je me permets d'écrire sur cette liste, merci de me dire si ce n'est > >> pas le bon endroit. J'ai envoyé un message sur le forum, mais j'ai > >> l'impression que ma question aura peut-être plus de chances de > >> réponses sur cette liste ! > > > > Oui, cette liste est beaucoup plus active que le forum. > > > >> "Saint-M'Hervon" a été engloutie par la commune de > >> "Montauban-de-Bretagne". J'ai donc transformé le point en lieu-dit, > >> est-ce ok ? > > > > Non, un lieu-dit n'a pas d'habitants. Je pense que "village" est plus > > approprié. > > Bonjour, > > Un lieu-dit, mot générique, peut avoir des habitants ou pas car place > signifie lieu-dit (un village est aussi un lieu-dit). Sans habitant, > c'est place=locality. > > Et bien se souvenir que il n'y a malheureusement aucun rendu pour le > moment des communes nouvelles issues de la fusion sur la carte > officielle https://www.openstreetmap.org/ sauf, comme dans ce cas, si la > commune ne change pas de nom. Ce n'est pas exact: si les noeuds représentent les place=* pour les noms locaux, les noms des relations sont visibles le long des frontières (il suffit de zoomer pour les voir). si on dézoome, le noeud va être trop petit par rapport à la relation, et la relation prend le pas, masquant le noeud représentant une relation plus petite quand on ne peut pas afficher les deux. Pour les communes nouvelles, comme elles conservent la toponymie des communes membres, le nom de la commune nouvelle ne remplace pas celui des communes membres, qui conservent également leur code INSEE propre à 5 chiffres (même si ces communes ne sont plus de "plein exercice" en tant que personnes morales séparées, le code INSEE à 5 chiffres est un code géographique, pas un code sur la personne morale qui, elle, est codée avec le code SIREN). La commune nouvelle adopte simplement le code INSEE à 5 chiffres d'une de ses communes membres, celle de son chef-lieu, les "anciens" codes INSEE à 5 chiffres ne sont pas "supprimés", il restent en vigueur et même liés aux communes membres. L'association du code INSEE à 5 chiffres avc la commune nouvelle est seulement une "facilité". C'est pour ça qu'on a mis en plus dans OSM l'attribut "admin_type:FR=commune [nouvelle/déléguée]" pour distinguer deux utilisations du même code INSEE à 5 chiffres qui permet de distinguer deux entités "communes" selon leur type et qui se partagent le même code INSEE à 5 chiffres. L'atrtibut "end_date=*" ne signifie pas la "fin" d'une commune membre, seulement son changement de statut en tant que commune de plein exercice, mais la commune (déléguée) existe toujours sous son nouveau statut (sans personnalité morale, donc plus avec un code SIREN puisqu'elle devient un ensemble d'établissements (SIRET) parties de la commune nouvelle. L'ancien SIREN est terminé, pas leur code INSEE à 5 chiffres, et les anciens SIRET de l'ancienne commune pleine devenue commune déléguée sont donc modifiés (si les établissements existent encore, ce qui est souvent le cas pour nombre d'établissements) en créant de nouveaux établissements dans le nouveau code SIREN de la commune nouvelle (ce nouveau code SIREN est basé sur le code INSEE à 5 chiffres de la commune déléguée chef-lieu) > Dans ce cas et autrement, on ne voit que > les communes anciennes sur la carte, marquées par un point place=village > ou bien place=* (autre). Alors que pour toutes les communes anciennes > fusionnées ou pas, un point place=* est placé traditionnellement en plus > de la frontière sous forme de relation même si la commune ancienne > comprend plusieurs place=village (agglomérations de plus de 200 > habitants). La raison est que les relations comportant le nom de la > commune nouvelle ne sont pas malheureusement non plus rendues (sauf le > long de la frontière de la commune en tout petit). > > La carte https://www.openstreetmap.org/ a choisi de ne pas représenter > les surfaces place=* pour une raison qui m'est inconnue contrairement à > l'application OsmAnd. > > Comme la communauté française a choisi de ne pas ajouter de point > place=* pour les communes nouvelles (alors que pour les habitants de > plus en plus celles-ci sont entrées dans la vie quotidienne entre autres > pour des raisons postales et de transports) et bien ces communes sont > invisibles sur ce rendu comme sur celui de openstreetmap.fr. > Il ne faut pas confondre les noms des collectivités territoriales (personnes morales) avec les noms géographiques (qui n'ont aucune obligation de désigner la même chose). L'organisation adminsitrative/fiscale/comptable/électorale est indépendante de l'organisation territoriale qui conserve sa finesse et sa pertinence. Personnellemment je vois les noms des communes nouvelles de la même façon que les noms des enseignes commerciales: ce ne sont pas des noms géographiques, et leur pertinence géographique est très peu significative et n'a d'intérêt que pour les lieux beaucoup plus locaux de leurs établissements et savoir quelle entité morale les gère. Malheureusement OSM n'a pas d'admin_level autre que le niveau 8 pour distinguer les types de communes, ce qui nécessite alors un admin_type:FR=* supplémentaire puisqu'on ne peut pas utiliser un admin_type=8.5 pour les communes déléguées, qui donc sont passées au niveau admin_type=9 (le même utilisé aussi pour les communes associées dans une commune en fusion-association, ou pour les arrondissements municipaux à Paris/Lyon/Marseille). De même OSM ne distingue pas non plus de niveau ni de place=* pour distinguer les arrondissements de Marseille et les secteurs de la ville (regroupements des arrondissements municipaux aux fins électorales, ce qui fait que les secteurs de Marseille n'ont aucun admin_level=* qui convient entre le niveau 8 pour la commune et le niveau 9 des arrondissements; et il n'y a pas non plus de place=* qui convienne bien pour les secteurs, entre place=city pour la ville, et place=suburb pour les arrondissements; les secteurs ne peuvent que réutiliser place=suburb, même si cela ne se rapporte à aucun admin_level=* entre 8 et 9 donc aucune relation de type boundary=administrative, mais seulement une relation de type boundary=political+political_division=secteur municipal). Mais ce modèle qui semble compliqué fonctionne: on peut tout avoir, mais pas avec les mêmes attributs. Il reste ensuite à OSM à afficher les noms des relations (il le fait) et séparément ceux des noeuds géographiques (s'il reste de la place une fois les relations affichées et s'ils ne sont pas homonymes).
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
