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

2020-02-14 Par sujet Philippe Verdy 
Il faut noter aussi que mars 2020 est la date de fusion d'un certain nombre
d'EPCI, dont on connait déjà les contours (par exemple la prochaine
extension de la métropole lilloise ou MEL) car c'est déjà arrêté et on sait
combien d'élus municipaux siègeront dans l'intercommunalité.

Comme c'est déjà connu et qu'on est à moins d'un mois, déjà dans la période
de campagne électorale, on pourrait déjà mettre un "end_date" sur les EPCI
qui vont disparaitre.

Mais peut-on déjà changer les EPCI qui vont changer de périmètre sans
changer d'identité ? Là je parle par exemple de la MEL, avec deux solutions
:
- 1. conserver la relation historique existante avec "end_date=2020-03"
aussi, mais ajouter une autre relation homonyme avec le périmètre étendu et
"start_date=2020-03", éventuellement avec un préfixe "planned:" pour la clé
de "boundary=local_autority", puis après mars passer l'ancienne relation
avec un préfixe "disused:".
- 2. modifier la relation existante (mais alors perdre l'info historique,
et pas facile de déterminer quand le faire de façon pertinente, ni moyen
d'anticiper le changement).

J'aurais tendance à privilégier la solution 1 qui permet la transition en
douceur et pas dans l'urgence (sans compter aussi des références subsistant
encore à l'ancien périmètre pendant les opérations de transfert de
compétence vers les communes ou les nouveaux EPCI, et des recours
administratifs et judiciaires suite aux litiges qui seront liés à ces
transferts), la solution 1 permettant de conserver les liens valides
existants à une date donnée, et savoir ensuite comment et quand faire la
transition pour les références nouvelles.

Ensuite combien de temps garder l'ancienne relation? J'aurais tendance à
dire qu'il faut au moins 2 exercices comptables complets, ou comme l'INSEE
conserver pour au moins 10 ans après la date de dernier recours judiciaire
(davantage si des recours sont déjà amorcés), ce qui permet aussi une
continuité pour l'analyse statistique et la détection d'anomalies ou
d'irrégularités pouvant entraîner des recours judiciaires pour des
transferts pas correctement réalisés ou des "trous" dans les opérations de
contrôle (pas seulement par les organismes publics mais aussi la société
civile qui voudra pouvoir juger de la pertinence de tels changements en
comparant la situation avant/après et pas seulement sur des simulations
estimées).


Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
a écrit :

> Je voudrais proposer de modifier la façon de traiter les communes
> nouvelles françaises dans OSM.
>
> Je considère qu'une nouvelle commune devrait être enregistrée de la même
> façon qu'une ancienne commune issue de fusion de plusieurs communes.
>
> La possibilité de fusion des communes en France est très ancienne, elle
> a plus de 50 ans. Par exemple, certaines communes sont issues d'une
> campagne de fusion des années 1970. Ces dernières portent souvent le nom
> des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont
> pas distinguées des communes non issues de fusion (ou plutôt, celles
> dont on se souvient qu'elles ne sont pas issues de fusion ; si on
> remonte très loin, au Moyen-Âge, ces communes non issues de fusion
> doivent être assez rares).
>
> De façon que je considère arbitraire, les communes issues de fusion
> d'après 2010 (pourquoi ne pas prendre celles avant 2010 ?) , il a été
> décidé ici même de traiter à part les communes nouvelles en ne les
> enregistrant que par leur frontière et sous forme de relation avec leurs
> anciennes communes membres et leur admin_centre. Il a aussi été décidé
> de ne pas les repérer par un nœud place=* contrairement aux communes
> d'avant 2010 même issues de fusion (donc beaucoup comme on l'a vu).
>
> La conséquence la plus visible est que ces communes sont totalement
> invisibles dans le rendu officiel osm.org qui n'affiche pas le nom des
> zones englobées par une frontière sans place=*.  Il y a pourtant
> d'autres limites dont le nom est affiché comme les forêts, etc.
> Geoportail de l'IGN affiche bien, lui, ces nouvelles communes.
>
> On répond que les nouvelles communes ne sont que des délimitations
> administratives qui n'ont pas vocation à être des lieux-dits. Cette
> opinion est contestable car c'est pourtant comme cela que l'on note les
> anciennes communes issues ou non de fusion. De plus dans l'esprit du
> législateur, les nouvelles communes issues de fusions récentes ont
> vocation à fonctionner comme les autres communes en intégrant
> complètement les anciennes qui ne deviennent que des sortes de quartiers
> ou arrondissements. Ces anciennes communes peuvent être des villages et
> parfois des petites villes (plus de 1 habitants aux abords d'une
> grande agglomération).
>
> Par exemple, une commune classique non issue de fusion récente comporte
> souvent un bourg qui est appelé Le Bourg par les habitants et est
> rarement repéré par ce nom dans Osm.org (alors que BANO peut le
> marquer). En général, la mairie décide de noter sur les

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

2020-02-13 Par sujet Eric SIBERT via Talk-fr 
Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur 
admin_centre.

[...]



Il y en a peut être un peu moins que ça, en regardant rapidement je vois 
des trucs bizarres :
un name=Saint-Pierre-d'Entremont (Isère) et un 
name=Saint-Pierre-d'Entremont (Savoie)


Un village traversé par la frontière entre la Savoie* et la France!

Au final, deux communes distinctes avec le même nom mais dans deux 
départements différents:


https://www.mapillary.com/map/im/XNQGJlkkRhXWYQ6lthzkFg

Et le code postal de la commune iséroise rattaché à la Savoie!!!

Eric

* Savoie indépendante, du fois pour nos vaches!!!

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-12 Par sujet Philippe Verdy 
Des admin_level=8 correspondent à plusieurs statuts communaux, ayant un
conseil élu et une autonomie financière (communes simples, communes
nouvelles, associations de communes, communes spéciales à arrondissements),
ou pas (mais qui ont une identité administrative inclue dans une entité
plus grande dont elle fait partie du découpage).

Dans le Pacifique il n'y a pas toujours un admin_centre désigné car les
compétences sont sur plusieurs iles simultanément, les conseils ont bien un
adresse postale, mais le lieu des conseils peut changer (conseils
itinérants) et les services communaux sont répartis sur les iles qui ont
des sortes de "mairies annexes" pour la représentation publique, la plupart
des iles étant de tous petits villages, ou les iles ayant des populations
très saisonnières, et une grande partie des services sont en fait délégués
à un service territorial qui centralise gestion pour chaque commune pour
des économies de moyens (cela est conjugué aux difficultés de transport et
aux coûts). Les communes ont pourtant une entité juridique et une autonomie
comptable mais le gros de leur travail est délégué sur chacune des iles par
des conseils locaux, la commune validant leurs décisions (où figurent aussi
des conseils de droit coutumier qui ne suivent pas non plus la logique du
découpage communal). Les communes sont assez théoriques, en pratique ce
sont les conseils "îliens" (réunis autour des conseillers locaux élus dans
la commune pour représenter chaque ile) qui font le travail et travaillent
pour plusieurs collectivités (la commune, le territoire, et le domaine
coutumier) et sous la supervision préfectorale/haut-commissariat pour
valider les décisions. C'est beaucoup moins centralisé et hiérarchisé qu'en
métropole.

C'est le cas en Polynésie, à Wallis-et-Futuna et en nouvelle-Calédonie où
le droit coutumier est reconnu et où cohabitent plusieurs domaines publics,
que les communes ne représentent pas et ne peuvent décider seules.

Se baser uniquement sur admin_level=8 et boundary=adminsitrative ne permet
pas de différencier tous les cas. C'est pour ça qu'on a des
"admin_type:FR=*" différents. Les statuts "communaux" ont même tendance à
se multiplier (et cela va continuer avec les fusions de compétence)
l'admin_level=8 désigne juste des communes ou *assimilées*, nécessaires
pour assurer la complétude du découpage territorial des entités
territoriales plus grandes.

Le jeu. 13 févr. 2020 à 04:56, Jérôme Amagat  a
écrit :

>
>
> Le mer. 12 févr. 2020 à 19:20,  a
> écrit :
>
>> Le 12/02/2020 à 18:02, Christian Quest - cqu...@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
>> 
>> (713).
>>
>>  Ce ne sont pas que des communes nouvelles ! et certaines communes
> nouvelles portent le nom d'une ville ou d'un village.
>
> J'ai fait cette requête sur overpass turbo :
> https://overpass-turbo.eu/s/QFS
> On peut faire des truc bien compliqué maintenant ! c'est la première fois
> que j'y utilise un if :)
>
> Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur
> admin_centre.
>
> dans le tas il y en a une quinzaine qui n'ont pas d'admin_centre
> tout est dans le pacifique en Polynésie et Clipperton (qui n'est pas une
> commune mais qui a sa relation admin_level=8 ?)
> sauf un truc (créé par Philippe) une relation admin_level=8 pour le
> domaine public maritime dans le golfe du morbillan :
> https://www.openstreetmap.org/relation/8687577
> relation inutile d’après moi.
>
> Il y en a 513 avec le tag admin_type:FR=commune nouvelle donc le reste
> (~400) a priori des communes qui n'ont pas bougé ses dernière années.
>
> Il y en a peut être un peu moins que ça, en regardant rapidement je vois
> des trucs bizarres :
> un name=Saint-Pierre-d'Entremont (Isère) et un
> name=Saint-Pierre-d'Entremont (Savoie)
> Rémire-Montjoly écrit avec ou sens accens.
>
> Je vois un autre problème non lié aux noms :
> "Matis73" a changer des place=village en place=quarter dans les alpes
>
> Comme évoqué par Florimond, il y a le cas des noms de villages et de
> communes avec "-sur-machin", '-en-bidule",... il y en a plein la France
> mais il ont souvent été ajouté au 20e siècle au nom du village ou de la
> ville. Je suis totalement contre les enlever du nom des villages mais que
> fait t on pour les nouveaux créé avec l’arrivée des communes nouvelles ?
> Cherbourg-en-Cotentin, Neuvéglise-sur-Truyère  c'est pas encore rentré
> dans les tête comme un changement du nom de la ville ou du village donc on
> les laisse comme nom de commune mais pas plus ou on les intègre au name des
> villes et villages ou en alt_name?
> ___
> Talk-fr mailing list
>

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

2020-02-12 Par sujet Jérôme Amagat 
Le mer. 12 févr. 2020 à 19:20,  a écrit :

> Le 12/02/2020 à 18:02, Christian Quest - cqu...@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
> 
> (713).
>
>  Ce ne sont pas que des communes nouvelles ! et certaines communes
nouvelles portent le nom d'une ville ou d'un village.

J'ai fait cette requête sur overpass turbo : https://overpass-turbo.eu/s/QFS
On peut faire des truc bien compliqué maintenant ! c'est la première fois
que j'y utilise un if :)

Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur
admin_centre.

dans le tas il y en a une quinzaine qui n'ont pas d'admin_centre
tout est dans le pacifique en Polynésie et Clipperton (qui n'est pas une
commune mais qui a sa relation admin_level=8 ?)
sauf un truc (créé par Philippe) une relation admin_level=8 pour le domaine
public maritime dans le golfe du morbillan :
https://www.openstreetmap.org/relation/8687577
relation inutile d’après moi.

Il y en a 513 avec le tag admin_type:FR=commune nouvelle donc le reste
(~400) a priori des communes qui n'ont pas bougé ses dernière années.

Il y en a peut être un peu moins que ça, en regardant rapidement je vois
des trucs bizarres :
un name=Saint-Pierre-d'Entremont (Isère) et un
name=Saint-Pierre-d'Entremont (Savoie)
Rémire-Montjoly écrit avec ou sens accens.

Je vois un autre problème non lié aux noms :
"Matis73" a changer des place=village en place=quarter dans les alpes

Comme évoqué par Florimond, il y a le cas des noms de villages et de
communes avec "-sur-machin", '-en-bidule",... il y en a plein la France
mais il ont souvent été ajouté au 20e siècle au nom du village ou de la
ville. Je suis totalement contre les enlever du nom des villages mais que
fait t on pour les nouveaux créé avec l’arrivée des communes nouvelles ?
Cherbourg-en-Cotentin, Neuvéglise-sur-Truyère  c'est pas encore rentré
dans les tête comme un changement du nom de la ville ou du village donc on
les laisse comme nom de commune mais pas plus ou on les intègre au name des
villes et villages ou en alt_name?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-12 Par sujet 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,  a écrit :

> Le 12/02/2020 à 18:02, Christian Quest - cqu...@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
> 
> (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

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

2020-02-12 Par sujet osm . sanspourriel 

Le 12/02/2020 à 18:02, Christian Quest - cqu...@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

(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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-12 Par sujet Christian Quest 

Le 12/02/2020 à 17:04, Rpnpif via Talk-fr a écrit :
Merci d'avoir pris en compte ce problème et merci pour vos suggestions 
(place=municipality) qui me font réfléchir..


Le problème est assez peu différent pour les communes anciennes et non 
fusionnées récemment ayant plusieurs agglomérations séparées. 
L'admin-centre n'est pas forcément l'agglomération la plus grande mais 
celle où est se situe le bâtiment de la mairie et on y met un place=* 
(Oui, Florimond, j'ai bien compris tes griefs et exemples).


J'aurais une suggestion qui va peut-être choquer : ce serait de 
remplacer place=village/town des anciennes communes incluses dans la 
fusion par des place=quarter/neighborough et de placer le nom de la 
nouvelle commune sur l'admin-centre en place=village/town/city comme 
on le fait pour Nantes, Paris, etc. toutes issues de fusions plus ou 
moins anciennes (oui bon la différence, c'est que ces communes ont 
gardé le nom de la commune principale).


Parce que, à priori, les communes dites déléguées ne sont que de 
futurs arrondissements ou quartiers de la nouvelle. Aujourd'hui, ce 
sont des sortes de quartiers à statut spécial.


Il me semble qu'on peut parler de quartiers quand c'est un sous ensemble 
d'une agglomération (fusion ou pas), mais pour le cas de la majorité des 
communes nouvelles, on est en zone rurale et on a des bourgs séparés, 
isolés les uns des autres.


Vu du terrain, ce sont des villages, qui oui, sont regroupés 
(uniquement) administrativement, mais on ne peut pas les considérer 
comme des quartiers.


Je m'appuie sur mon expérience locale autour de mon point de chute 
bourguignon avec plusieurs communes nouvelles à proximité. Si je 
demandais aux habitants leur point de vue, je doute fort qu'un seul se 
considère comme habitant d'un quartier de la commune nouvelle.


De même, ma commune point de chute (non fusionnée) se compose en fait de 
7 hameaux... et pas de quartiers non plus.


Petit tour sur https://wiki.openstreetmap.org/wiki/Key:place pour se 
remettre la logique de place=* en tête...


Le wiki est plutôt clair avec 4 tableaux... quarter et neighbourhood 
sont des parties de suburb qui est lui même une partie de city/town, 
donc de grosses agglomérations. C'est d'ailleurs uniquement dans un 
tableau "urban".


Pour le tableau "rural", on a town, village, hamlet, isolated_dwelling, 
farm, allotments... et rien d'autre ce qui me semble logique et lié à la 
population (le retour) qui se trouve sur ces place=*.


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 !


La troisième règle non écrite d'OSM: toujours, toujours relire le wiki ;)

--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-12 Par sujet Rpnpif via Talk-fr 
Merci d'avoir pris en compte ce problème et merci pour vos suggestions 
(place=municipality) qui me font réfléchir..


Le problème est assez peu différent pour les communes anciennes et non 
fusionnées récemment ayant plusieurs agglomérations séparées. 
L'admin-centre n'est pas forcément l'agglomération la plus grande mais 
celle où est se situe le bâtiment de la mairie et on y met un place=* 
(Oui, Florimond, j'ai bien compris tes griefs et exemples).


J'aurais une suggestion qui va peut-être choquer : ce serait de 
remplacer place=village/town des anciennes communes incluses dans la 
fusion par des place=quarter/neighborough et de placer le nom de la 
nouvelle commune sur l'admin-centre en place=village/town/city comme on 
le fait pour Nantes, Paris, etc. toutes issues de fusions plus ou moins 
anciennes (oui bon la différence, c'est que ces communes ont gardé le 
nom de la commune principale).


Parce que, à priori, les communes dites déléguées ne sont que de futurs 
arrondissements ou quartiers de la nouvelle. Aujourd'hui, ce sont des 
sortes de quartiers à statut spécial.


--
Rpnpif

Le 11/02/2020 à 18:03, Christian Quest a écrit :

Prenons un exemple pour réfléchir:

- Montholon (commune nouvelle): place=municipality + population=1500

  - Aillant-sur-Tholon (commune chef-lieu): place=village + 
population=1000


  - Volgré (commune déléguée): place=village + population=300

  - Villiers-sur-Tholon (commune déléguée): place=village + 
population=200


Chaque noeud est admin_centre d'une relation admin_level=8 ou 9


Sur le rendu, Montholon sera placé en priorité, puis Aillant, puis 
Volgré, puis Villiers.


Comme on aura plus le détail des populations des communes déléguées 
(quoique*) on peut conserver ce qu'on a de plus récent et on a le 
millésime en source:population


De toute façon, quelqu'un qui aurait besoin des populations à jour 
ferait quand même bien mieux (en France) de prendre le fichier de 
l'INSEE ;)



Place sur la relation + sur le noeud ? Bof bof bof, ça ne me semble 
pas cohérent car on a un doublon de place=* (qui décrit un objet, 
contrairement à population=* qui n'est pas un "objet" en tant que tel 
mais un attribut d'un objet).



* avec le carroyage INSEE on pourrait très bien déduire 
approximativement la population d'un hameau, d'un écart, etc...





___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-12 Par sujet Florimond Berthoux 
Le mer. 12 févr. 2020 à 05:08, Jérôme Amagat  a
écrit :

>
>
> Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Je voudrais proposer de modifier la façon de traiter les communes
>> nouvelles françaises dans OSM.
>>
>> Je considère qu'une nouvelle commune devrait être enregistrée de la même
>> façon qu'une ancienne commune issue de fusion de plusieurs communes.
>>
>> C'est traité de la même façon dans osm.
> Comme la grande majorité des communes porte le nom du village (ou la
> ville) principal on confond souvent les 2 mais dans osm la commune et le
> village sont indiqués de 2 façons différentes.
> relation boundary admin_level=8 pour les communes et place=village pour
> les village.
>
> Pour des communes fusionnées il y a longtemps avec un nom de commune
> différents de celui du village principal, j'ai des cas pas loin de chez moi
> :
> Hautecourt-Romanèche : https://www.openstreetmap.org/relation/140516
> Bohas-Meyriat-Rignat : https://www.openstreetmap.org/relation/140527
> fusionnées dans les années 70
> Pour les 2, les noms de communes sont l'addition des noms des anciennes
> communes.
>
> Pour des communes qui ne porte pas le nom d'un village, je connais Alleuze
> : https://www.openstreetmap.org/relation/1223480 qui porte le nom d'un
> château en ruine.
> J'ai pas d'autres exemples en tête mais il y en a d'autres.
>

La plus part des noms de communes sous la forme XXX leṣ|lès|des|en|sur...
sont souvent que des formes administrative pour différencier des homonymies
à l’échelle nationale.
Exemple : j’ai habité dans la commune de Lassay les Châteaux en campagne,
et j’allais au collège à Lassay.

-- 
Florimond Berthoux
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-11 Par sujet Jérôme Amagat 
Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
a écrit :

> Je voudrais proposer de modifier la façon de traiter les communes
> nouvelles françaises dans OSM.
>
> Je considère qu'une nouvelle commune devrait être enregistrée de la même
> façon qu'une ancienne commune issue de fusion de plusieurs communes.
>
> C'est traité de la même façon dans osm.
Comme la grande majorité des communes porte le nom du village (ou la ville)
principal on confond souvent les 2 mais dans osm la commune et le village
sont indiqués de 2 façons différentes.
relation boundary admin_level=8 pour les communes et place=village pour les
village.

Pour des communes fusionnées il y a longtemps avec un nom de commune
différents de celui du village principal, j'ai des cas pas loin de chez moi
:
Hautecourt-Romanèche : https://www.openstreetmap.org/relation/140516
Bohas-Meyriat-Rignat : https://www.openstreetmap.org/relation/140527
fusionnées dans les années 70
Pour les 2, les noms de communes sont l'addition des noms des anciennes
communes.

Pour des communes qui ne porte pas le nom d'un village, je connais Alleuze
: https://www.openstreetmap.org/relation/1223480 qui porte le nom d'un
château en ruine.
J'ai pas d'autres exemples en tête mais il y en a d'autres.

Pour ce qui est de l'utilisation de place=municipality :
l'ajout de la population de la municipalité serait logique.
Mais par contre, ce n'est pas l'admin_centre de la commune. (label ?)
Par contre où placer le node, dans un endroit dégagé pour pouvoir avoir le
nom des villages qui apparaissent aussi, au centre de la commune ou près de
l'admin_centre de la commune ?

:) par contre, 2 règles importantes d'osm serait enfreintes, "One feature,
one OSM element" et "ne pas taguer pour le rendu" :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-11 Par sujet Philippe Verdy 
Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
a écrit :

> La possibilité de fusion des communes en France est très ancienne, elle
> a plus de 50 ans. Par exemple, certaines communes sont issues d'une
> campagne de fusion des années 1970. Ces dernières portent souvent le nom
> des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont
> pas distinguées des communes non issues de fusion (ou plutôt, celles
> dont on se souvient qu'elles ne sont pas issues de fusion ; si on
> remonte très loin, au Moyen-Âge, ces communes non issues de fusion
> doivent être assez rares).


Effectivement puisque'au moyen-âge il n'y avait encore aucune "commune" en
France (en tout cas pas dans le sens civil de droit commun qu'on entend
aujourd'hui.
Les communes sont une création après la révolution française et l'abolition
des privilèges et de tous les anciens domaines seigneuriaux et
ecclésiastiques, et certains domaines pour des collèges de marchands (qui
avaient divers statuts très changeants selon les successions, invasions,
etc. seuls les bourgs semblaient délimités, les domaines ruraux n'avaient
pas de réelle frontière autre que naturelle et certains points de passage
sur les routes et chemins, plus ou moins défendus, selon la présence
militaire locale et le bon vouloir de la population locale et les moyens
des voyageurs).
Si on veut faire une cartographie des domaines seigneuriaux, cela va être
très compliqué car il va falloir gérer les dates dont bon nombre sont mal
connues. C'est un peu plus facile pour les domaines ecclésiastiques, bien
que leur usage pour le statut civil n'a pas suivi non plus les prétentions
seigneurales (Cela s'est compliqué avec les guerres de religion et nombreux
conflits de succession, mais aussi du fait des mobilisations et migrations
forcées de population par les seigneurs de passage sur "leurs" terres).
Les archives des communes ne remontent jamais avant la révolution, d'autant
plus que la toponymie est aussi incertaine et des tas de villages
différents ont été confondus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-11 Par sujet Christian Quest 

Prenons un exemple pour réfléchir:

- Montholon (commune nouvelle): place=municipality + population=1500

  - Aillant-sur-Tholon (commune chef-lieu): place=village + population=1000

  - Volgré (commune déléguée): place=village + population=300

  - Villiers-sur-Tholon (commune déléguée): place=village + population=200

Chaque noeud est admin_centre d'une relation admin_level=8 ou 9


Sur le rendu, Montholon sera placé en priorité, puis Aillant, puis 
Volgré, puis Villiers.


Comme on aura plus le détail des populations des communes déléguées 
(quoique*) on peut conserver ce qu'on a de plus récent et on a le 
millésime en source:population


De toute façon, quelqu'un qui aurait besoin des populations à jour 
ferait quand même bien mieux (en France) de prendre le fichier de l'INSEE ;)



Place sur la relation + sur le noeud ? Bof bof bof, ça ne me semble pas 
cohérent car on a un doublon de place=* (qui décrit un objet, 
contrairement à population=* qui n'est pas un "objet" en tant que tel 
mais un attribut d'un objet).



* avec le carroyage INSEE on pourrait très bien déduire 
approximativement la population d'un hameau, d'un écart, etc...



Le 11/02/2020 à 17:44, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour Christian,

J'ai fait des essais assez exhaustifs afin d'avoir une modélisation de
place avec une zone pour confirmer tes dires : il faut ceinture et
bretelles, place sur la relation (logique) et place sur le nœud label
(ou admin_centre).

https://www.openstreetmap.org/relation/10060749

Oui ici ça n'avait pas de sens de dire admin_centre pour un lotissement,
mais c'est aussi valable pour admin_centre.

> je sais, je suis lourd
Pas toi, c'est le modèle qui est lourd.

Reste qu'on a des admin_centre de niveaux 8 et 9 pour les communes
déléguées et assimilées.

Si on force municipality comme type de place, on indique bien que la
valeur porte sur l'ensemble de la commune et non sur une des
communes/zone agglomérée. Heu, quoique : Audierne-Esquibien (niveau 8) a
pour admin centre l'admin centre d'Audierne (9).

Comment sait-on si la population du nœud Audierne concerne Audierne ou
Audierne-Esquibien ?

population:admin_level= 8 ou 9 pourrait le résoudre.

Est-ce qu'il y a mieux en stock dans vos méninges ?

Jean-Yvon

Le 11/02/2020 à 17:18, Christian Quest - cqu...@openstreetmap.fr a 
écrit :

J'ai l'impression que le rendu osm.org ne prends en compte que les
noeuds place=*, pas les boundary.

Il fut une époque où il utilisait les deux, mais cela donnait des noms
en double.

Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle
prends le place=* en priorité (car mieux positionné) et le centroid du
boundary en second quand il n'y a pas de place pour un même nom.


Un noeud place=municipality avec un population pour prioriser quand on
manque de place (je sais, je suis lourd) permettrait de s'en sortir à
moindres frais.


Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour 
faire

apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la
frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
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


--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-11 Par sujet osm . sanspourriel 

Bonjour Christian,

J'ai fait des essais assez exhaustifs afin d'avoir une modélisation de
place avec une zone pour confirmer tes dires : il faut ceinture et
bretelles, place sur la relation (logique) et place sur le nœud label
(ou admin_centre).

https://www.openstreetmap.org/relation/10060749

Oui ici ça n'avait pas de sens de dire admin_centre pour un lotissement,
mais c'est aussi valable pour admin_centre.

> je sais, je suis lourd
Pas toi, c'est le modèle qui est lourd.

Reste qu'on a des admin_centre de niveaux 8 et 9 pour les communes
déléguées et assimilées.

Si on force municipality comme type de place, on indique bien que la
valeur porte sur l'ensemble de la commune et non sur une des
communes/zone agglomérée. Heu, quoique : Audierne-Esquibien (niveau 8) a
pour admin centre l'admin centre d'Audierne (9).

Comment sait-on si la population du nœud Audierne concerne Audierne ou
Audierne-Esquibien ?

population:admin_level= 8 ou 9 pourrait le résoudre.

Est-ce qu'il y a mieux en stock dans vos méninges ?

Jean-Yvon

Le 11/02/2020 à 17:18, Christian Quest - cqu...@openstreetmap.fr a écrit :

J'ai l'impression que le rendu osm.org ne prends en compte que les
noeuds place=*, pas les boundary.

Il fut une époque où il utilisait les deux, mais cela donnait des noms
en double.

Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle
prends le place=* en priorité (car mieux positionné) et le centroid du
boundary en second quand il n'y a pas de place pour un même nom.


Un noeud place=municipality avec un population pour prioriser quand on
manque de place (je sais, je suis lourd) permettrait de s'en sortir à
moindres frais.


Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la
frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
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

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

2020-02-11 Par sujet Christian Quest 
J'ai l'impression que le rendu osm.org ne prends en compte que les 
noeuds place=*, pas les boundary.


Il fut une époque où il utilisait les deux, mais cela donnait des noms 
en double.


Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle 
prends le place=* en priorité (car mieux positionné) et le centroid du 
boundary en second quand il n'y a pas de place pour un même nom.



Un noeud place=municipality avec un population pour prioriser quand on 
manque de place (je sais, je suis lourd) permettrait de s'en sortir à 
moindres frais.



Le 11/02/2020 à 15:32, marc marc a écrit :

Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :

ne pas les repérer par un nœud place=* contrairement aux communes
d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-11 Par sujet marc marc 
Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :
> ne pas les repérer par un nœud place=* contrairement aux communes
> d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-02-11 Par sujet Rpnpif via Talk-fr 
Je voudrais proposer de modifier la façon de traiter les communes 
nouvelles françaises dans OSM.


Je considère qu'une nouvelle commune devrait être enregistrée de la même 
façon qu'une ancienne commune issue de fusion de plusieurs communes.


La possibilité de fusion des communes en France est très ancienne, elle 
a plus de 50 ans. Par exemple, certaines communes sont issues d'une 
campagne de fusion des années 1970. Ces dernières portent souvent le nom 
des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont 
pas distinguées des communes non issues de fusion (ou plutôt, celles 
dont on se souvient qu'elles ne sont pas issues de fusion ; si on 
remonte très loin, au Moyen-Âge, ces communes non issues de fusion 
doivent être assez rares).


De façon que je considère arbitraire, les communes issues de fusion 
d'après 2010 (pourquoi ne pas prendre celles avant 2010 ?) , il a été 
décidé ici même de traiter à part les communes nouvelles en ne les 
enregistrant que par leur frontière et sous forme de relation avec leurs 
anciennes communes membres et leur admin_centre. Il a aussi été décidé 
de ne pas les repérer par un nœud place=* contrairement aux communes 
d'avant 2010 même issues de fusion (donc beaucoup comme on l'a vu).


La conséquence la plus visible est que ces communes sont totalement 
invisibles dans le rendu officiel osm.org qui n'affiche pas le nom des 
zones englobées par une frontière sans place=*.  Il y a pourtant 
d'autres limites dont le nom est affiché comme les forêts, etc. 
Geoportail de l'IGN affiche bien, lui, ces nouvelles communes.


On répond que les nouvelles communes ne sont que des délimitations 
administratives qui n'ont pas vocation à être des lieux-dits. Cette 
opinion est contestable car c'est pourtant comme cela que l'on note les 
anciennes communes issues ou non de fusion. De plus dans l'esprit du 
législateur, les nouvelles communes issues de fusions récentes ont 
vocation à fonctionner comme les autres communes en intégrant 
complètement les anciennes qui ne deviennent que des sortes de quartiers 
ou arrondissements. Ces anciennes communes peuvent être des villages et 
parfois des petites villes (plus de 1 habitants aux abords d'une 
grande agglomération).


Par exemple, une commune classique non issue de fusion récente comporte 
souvent un bourg qui est appelé Le Bourg par les habitants et est 
rarement repéré par ce nom dans Osm.org (alors que BANO peut le 
marquer). En général, la mairie décide de noter sur les panneaux 
d'entrées du bourg le nom de la commune. Donc la commune est aussi un 
lieu-dit qui devrait être noté par place=* au niveau du bourg ou de 
l'agglomération principale. Dans le cas d'une commune issue de fusion 
récente, certaines mairies n'affichent que le nom de la commune issue de 
fusion et pas l'ancienne. D'autres affichent le nom de l'ancienne 
commune avec mention du nom de la nouvelle dessous. Évidemment, quand le 
nom de la commune issue de la fusion est le même que celle de celui de 
la commune admin_centre, le problème est plus simple.


Les habitants et autres partenaires des nouvelles communes récentes font 
de moins en moins la distinction avec le fonctionnement des communes non 
fusionnées récemment que ce soit pour leurs relations avec la mairie, la 
Poste, etc. (bien sûr après un temps d'adaptation plus ou moins facile 
et plus ou moins heureux). Ils ont donc de plus en plus besoin de 
repérer leur commune nouvelle sur une carte.


En conséquence de ce que j'écris ci-dessus, ma proposition est la suivante :

Traiter les nouvelles communes comme les anciennes avec une relation 
frontière (boundary) et un nœud place=* mis aux abords de l'admin-centre 
ou bien vers le centre de la commune.


Garder le nœud place=* et la relation frontière (boundary) des anciennes 
communes comme on le fait déjà pour les place=village des lieux-dits 
d'agglomération de plus de 200 et de moins de 1 habitants à 
l'intérieur d'une commune « non fusionnée » récemment.


Cette proposition permet de simplifier les contributions ainsi que les 
moteurs de rendus.


--
Rpnpif


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr