Il ne faut pas confondre commune dun côté et ville ( village hameau) de
l'autre.
Dans osm les communes c'est la relation avec admin_level=8 et la ville
c'est place=*
Dans la plupart des communes de France la commune à le même nom que le
village principal mais pas partout.

Dans le cas de cette commune le officiel name sur les place= est inutile.
Les place sont dans les limite de la relation se la commune donc pas la
peine de rajouter le nom de la commune.
Je mettrait plutôt place=village pour les 2 "Lit" et aussi "mixe". La
distinction entre un hameau et un village est pas très claire mais pour moi
c'est son "importance". "Mixe" sert au nom de la commune, ça a été une
commune et ça semble être plus habité que pas mal de village de France donc
je mettrais "village"


Le lun. 10 sept. 2018 à 18:10, djakk djakk <djakk.dj...@gmail.com> a écrit :

> ... nat_name et official_name uniquement sur le noeud de la ville ou d’un
> village principal bien sûr !
>
>
> djakk
>
> Le lun. 10 sept. 2018 à 17:16, djakk djakk <djakk.dj...@gmail.com> a
> écrit :
>
>> Bon j’ai mis name=“Lit” et official_name ainsi que nat_name=“Lit-et-Mixe”
>> Je n’ai pas touché au nom de la frontière administrative bien sûr.
>>
>> On fait pareil pour les communes fusionnées ?
>>
>> Un rendu peut ainsi choisir le nat_name en zoom éloigné et le name en
>> zoom proche ...
>>
>>
>> djakk
>>
>>
>> Le jeu. 9 août 2018 à 14:20, Philippe Verdy <verd...@wanadoo.fr> a
>> écrit :
>>
>>> Pour les communes associées dans une fusion-association, ou pour les
>>> communes déléguées dans les communes nouvelles, ou pour les arrondissements
>>> municipaux (de Lille, Paris et Marseille), c'est le niveau 9 qui est
>>> utilisé avec admin_type:FR=* qui précise leur type respectif. La commune
>>> fusionnée de droit est de niveau 8, et peut avoir aussi un
>>> "admin_type:FR=*" pour la distinguer d'une commune simple (par défaut).
>>> En règle générale place=* est indépendant de l'entité adminsitrative (on
>>> devrait même se passer de "place=*" pour les relations, il est plus lié aux
>>> nodes).
>>> De même les chiffres de population devraient être sur la relation (quand
>>> il en existe une) et non sur le noeud. Le noeud peut être l'admin_centre de
>>> plusieurs relations adminsitratives, ou parfois un des "admin_centre" d'une
>>> même relation dans certains cas pour certaines entités: 'de jure' contre
>>> 'de facto'; 'capitale politique' contre 'capitale administrative' ou
>>> 'judiciaire'; 'capitale royale' contre 'capitale nationale'). Et très
>>> souvent ce noeud n'a pas le même nom que l'entité administrative où il est
>>> situé. Ce noeud donne plutôt une vision de géographie urbaine et non
>>> politique.
>>>
>>> Les statuts de "ville", "village", "borough" (admin_type=* sur les
>>> relations administratives ou politiques ou autres) ne vont pas bien avec
>>> les valeurs données à "place=*" pour les noeuds "admin_centre". Et nombre
>>> de ces lieux (village ou hameaux ou communautés rurales locales) n'ont
>>> aucun statut administratif et ne sont pas clairement délimités au sein de
>>> l'entité administrative.
>>>
>>> Assez souvent aussi un noeud "place=*" donne son nom à une entité qui
>>> est plus large que l'entité administrative (notamment dans les grandes
>>> métropoles, mais parfois aussi des villes plus petites, pour inclure une
>>> partie de leur périphérie): les "place" correspondent mieux en France à ce
>>> que l'INSEE désigne dans sa géographie urbaine (indépendante de la
>>> géographie administrative) qui évolue tout le temps et plus vite que la
>>> géographie administrative.
>>>
>>> Et pour moi "place=suburb" est donc inadapté en France, sauf pour les
>>> noeuds ajoutés en "admin_centre" des arrondissements municipaux des 3
>>> grandes villes: là c'est "admin_type:FR=arrondissement municipal" qui va
>>> prend le pas
>>>
>>> Le "place=suburb" est plus pour la compatibilité des rendus génériques
>>> internationaux: c'est une approximation permettant juste des comparaisons
>>> et d'améliorer le rendu final (pour sélectionner l'icone du noeud ou juste
>>> le style/la taille du libellé , il n'a pas de valeur en tant que donnée
>>> administrative, et sinon pour donner une priorité estimée de "l'importance"
>>> du lieu dans les recherches puisque une carte ne peut pas tous les afficher
>>> : ce "place=*" est juste un des critères possibles permettant de filtrer
>>> les éléments à afficher en priorité).
>>>
>>>
>>> Le 9 août 2018 à 11:20, djakk djakk <djakk.dj...@gmail.com> a écrit :
>>>
>>>> Oui tout à fait c’est le même problème avec les communes fusionnées. Je
>>>> n’aime pas l’utilisation du place=suburb pour les communes associées ... je
>>>> préférerai qu’on garde place=village ou place=town et que le détail
>>>> administratif se fasse avec les admin_level= ...
>>>> Car quand on se balade on ne ressent pas la ville ou le village par son
>>>> côté administratif mais par son urbanisme et sa densité commerciale et sa
>>>> densité de services.
>>>>
>>>> djakk
>>>>
>>>>
>>>> Le mar. 7 août 2018 à 19:00, Rpnpif <rpn...@trob.eu> a écrit :
>>>>
>>>>> Le  4 août 2018, Stéphane Péneau a écrit :
>>>>>
>>>>> > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est
>>>>> un
>>>>> > peu délicat.
>>>>> >
>>>>> > En revanche, town pour un bourg d'un peu plus de 1000 habitants, je
>>>>> ne
>>>>> > suis pas trop d'accord. place=village est mieux adapté
>>>>> >
>>>>>
>>>>> Bonjour,
>>>>>
>>>>> En complément de la réserve de Stéphane, c'est le même problème avec la
>>>>> fusion récente de communes.
>>>>> Il faudrait aussi adapter le niveau administratif 8, 9 ou autre.
>>>>> https://wiki.openstreetmap.org/wiki/Key:admin%20level?uselang=fr
>>>>>
>>>>> --
>>>>> Alain Rpnpif
>>>>>
>>>>> _______________________________________________
>>>>> Talk-fr mailing list
>>>>> Talk-fr@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-fr mailing list
>>>> Talk-fr@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à