subject:"Re\: \[OSM\-talk\-fr\] Communes nouvelles"


Le 30/12/2015 12:29, Christian Quest - cqu...@openstreetmap.fr a écrit :
Je pense mal me faire comprendre... je ne parle pas d'une modélisation 
dans l'absolu "ex-nihilo" où oui, admin_level=9 me semblerait adapté. 
Je parle d'une utilisation actuelle des données qui va être 
potentiellement impactée si on ne prend pas en compte de nouveaux 
tags, impact qui serait beaucoup plus limité si on faisait ça sur 
admin_level=10 qui n'avait pas l'homogénéité de admin_level=9

Non, je pense que tu es clair.
Est-ce que des outils s'en servent vraiment ?
Comme dit par d'autres, les 3 cas, chacun différent, de 3 communes ne 
doivent pas empêcher de faire de bons choix pour 36 000 autres.



*? start_date=2016-01-01 ou end_date ou autre chose***
Mettre la plage temporelle dans le tag, ça les rend fort inutilisables 
si ce n'est pas rendu plus générique. J'avais proposé quelque chose du 
genre il y a un bout de temps, mais l'allergie ambiante aux données 
"historiques" avait eu raison de cette proposition.

Les tags que tu présente me semble une fausse bonne idée.

Quelqu'un a regardé comment c'est géré dans d'autres pays ?

Je ne fais que reprendre une idée venue d'ailleurs.
La personne la plus allergique en France sur les données historiques 
n'est pas sur cette liste il me semble ;-).
Le format est générique (attribut:dateISO=valeur, et en conservant le 
attribut=valeur pour la valeur actuelle).


admin_level=9 + disused:admin_level=8 ça pourrait aussi le faire, mais 
on n'a pas d'info sur la date de changement.

C'est bien le problème.
Maintenant si on met start_date=2016-01-01, admin_level=9, 
disused:admin_level=8, un humain comprendra sans doute ce qu'il doit 
comprendre.

Mais un ordinateur risque de ne rien afficher avant le 1er janvier.

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

> Cette différenciation est peut-être superflue (je ne l'ai pas vu dans 
les mairies annexes de Nantes par exemple).


Sur celles de Brest idem :
amenity <http://wiki.openstreetmap.org/wiki/FR:Key:amenity?uselang=fr> 
townhall 
<http://wiki.openstreetmap.org/wiki/FR:Tag:amenity=townhall?uselang=fr>

Seul le nom indique qu'il s'agit d'une mairie de quartier.

Sur le wiki allemand ils disent de mettre le type suivant si c'est une 
ville ou un district. Sans objet pour la France.


Spezifiziere auch näher: townhall:type 
<http://wiki.openstreetmap.org/w/index.php?title=Key:townhall:type=edit=1>=village 
für das Gemeindeamt einer Gemeinde townhall:type 
<http://wiki.openstreetmap.org/w/index.php?title=Key:townhall:type=edit=1>=city 
für das Rathaus einer Stadt.



Le 30/12/2015 20:10, Florent RICHARD - florentrich...@hotmail.fr a écrit :
En parlant de mairie, ne faudrait-il pas modifier les mairies 
(bâtiment) sur ces communes fusionnées?


Je pensais à modifier le tag name
name=Mairie de  pour la mairie principale
name=Mairie annexe de  pour les autres 
mairies


Je pensais également à différencier la mairie principale et les 
mairies annexes par un tag spécifique.
J'ai vu qu'il existe un tag "townhall:type" sur le wiki anglais 
(http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtownhall) mais je ne 
suis pas sur que les valeurs "city" et "village" soient pertinentes.
Cette différenciation est peut-être superflue (je ne l'ai pas vu dans 
les mairies annexes de Nantes par exemple).


-Message d'origine- From: Tony Emery
Sent: Wednesday, December 30, 2015 4:08 PM
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

On a bien à faire à de futures mairies annexes des nouvelles communes...

"Ces communes déléguées n’ont pas le statut de collectivité territoriale,
seule la commune nouvelle est dotée de cette qualité. La mise en place de
ces communes déléguées permet également de créer une annexe de la mairie
dans laquelle sont établis les actes de l’état civil concernant les
habitants de la commune déléguée.

Ainsi, les bâtiments abritant actuellement les communes futures 
membres de

la commune nouvelle garderaient une utilité évidente et permettraient de
conserver un lien de proximité avec les habitants de l’ancienne commune."

courrierdesmaires.fr
<http://www.courrierdesmaires.fr/48010/communes-nouvelles-mode-demploi/>



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-nouvelles-fusion-de-communes-tp5862292p5863524.html

Sent from the France mailing list archive at Nabble.com.

___
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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Par sujet Vincent de Château-Thierry


> De: "Tyndare" 
> 
> Sur tous les exemples que j'ai vu le tag ref:INSEE était indiqué sur
> le nœud place, (admin_center)
> Si le noeud place correspond au panneau
> du village et non a la commune le tag ref:INSEE n'a pas de sens ici,
> il faudrait le déplacer systématiquement sur la relation admin (pour
> toutes les communes de France)

La généralisation du tag ref:INSEE sur les nodes place=* date de 2012 [1], 
l'idée, comme rappelé par Stéphane, était de pallier l'absence des contours 
admins. C'est du passé, et en effet l'existence exaustive des contours 
permettrait de faire un peu de ménage. 

> Je suis mitigé pour basculer les codes INSEE historiques en old_ref
> Même si il ne sont plus actifs ils restent toujours plus ou moins
> valides.

Je les garderais aussi volontiers en ref:INSEE (et non old_ref:INSEE) mais il 
faut être conscient d'une nouvelle situation : une même valeur de code INSEE va 
s'appliquer à 2 emprises : une commune nouvelle, _et_ la commune déléguée qui 
prend le rôle de chef-lieu. Donc une requête sur uniquement le code INSEE ne 
ramènera plus un résultat unique, mais 2 emprises, l'une imbriquée dans 
l'autre, sauf à préciser l'admin_level qu'on cherche : admin_level=8 ramènera 
la commune nouvelle, admin_level=9 ramènera une commune déléguée.

vincent

[1] : https://lists.openstreetmap.org/pipermail/talk-fr/2012-April/042521.html

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne pas
mettre la date ou l'intervalle de dates entre parenthèses après la
référence, avec en plus la possibilités de plusieurs refs anciennes
séparées par point-virgule avec chacune la mention de dates? Un seul tag
alors...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne pas
mettre la date ou l'intervalle de dates entre parenthèses après la
référence, avec en plus la possibilités de plusieurs refs anciennes
séparées par point-virgule avec chacune la mention de dates? Un seul tag
alors...
Le 30 déc. 2015 10:45, <osm.sanspourr...@spamgourmet.com> a écrit :

> pour les *old_ref:INSEE*, je serais plus pour des
> old_ref:INSEE:-2016-01-01=
> (millésimons ! ;-))
>
> Pour le *admin_level=9*, je ne vois pas à quoi tu fais référence : je
> trouve (j'ai regardé uniquement dans l'ouest) et je tombe sur des communes
> associées, déléguées..., bref des choses homogènes qui existent déjà, les
> outils existants ne devraient pas avoir des comportement inattendus.
> Tu ne penses pas au niveau ComCom qui n'est pas (plus) un niveau
> administratif et qui n'est pas de niveau 9 ?
> Les exceptions sont les arrondissements municipaux et ils sont bien une
> subdivision des trois communes PLM comme le sont les communes déléguées,
> donc au même niveau. Pas de même nature, d'où l'autre attribut.
>
> En ajoutant sur les communes devenues déléguées un tag spécifique style :
> *? **admin_type:FR=commune déléguée*
> on a moyen de changer sans problème.
>
> Ma requête :
> *relation[admin_level=9]({{bbox}})*
> * ); out center;*
>
> *? source=le JO ou l’arrêté préfectoral*
> Le JO c'est plutôt mieux, mais pour Audierne il n'était pas sorti
> (maintenant c'est JORFTEXT31690191)
>
> dep,nouvelle,anciennes,date,population,chflieu,jorf
> 29,Audierne,Audierne|Esquibien,,3839,Audierne,JORFTEXT31690191
>
>
> *? start_date=2016-01-01 ou end_date ou autre chose*
> (pour les communes déléguées)
> Comme c'est "seulement" le niveau administratif qui change, ça ma gène un
> peu de mettre un start_date ou un end_date.
> C'est pour cela que je proposais :
> admin_level:-2016-01-01=8
> admin_level:2016-01-01-=9
> (plus un admin_level=8 jusqu'à demain soir et 9 au delà,
> admin_level=8 et
> admin_level:proposed=9 permettent de scripter le changement à minuit)
> Comme ça les outils marchent (admin_level est correct) et on ne perd pas
> l'information.
> Mais comme dit Vincent, ça crée des tags en plus. Ceci dit, ça permet
> d'affiner. Allez, des volontaires pour faire une animation en CSS par
> exemple pour visualiser les changements ? Ça pourrait être parlant pour la
> promotion d'OSM auprès de la PQR ou des voisins de bureau de Christian.
>
> Jean-Yvon
>
>
> Le 30/12/2015 08:23, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Franchement, le admin_level=9 me gène pour la confusion qu'il va créer
> pour les outils l'utilisant déjà actuellement (et il y en a vu que ces
> découpages étaient exhaustifs).
>
> Je ne me battrais pas là dessus, mais ne vous étonnez pas si il y a des
> trucs qui merdent à court terme ici ou là.
>
> Sur le process, je propose de faire ça en deux temps et via le script que
> j'ai écrit:
> 1) création des nouvelles relations avec admin_level:proposed=8 /
> start_date=2016-01-01
> ça laisse un peu de temps pour vérifier...
> 2) bascule en admin_level=8 et modif des anciennes communes
>
> L'important étant d'avoir le CSV global bien propre. Le script permet
> d'être homogène et ne mobilise plus de temps humain qu'on peut remettre à
> profit sur le contrôle du résultat.
>
>
> relation commune délégués :
> type=boundary
> boundary=administrative
> name=*
> ? admin_level=9
> ? source=le JO ou l’arrêté préfectoral
> ? admin_type:FR=commune déléguée
> ? start_date=2016-01-01 ou end_date ou autre chose
>
> il faut bien sur tomber d'accord sur
> quel admin_level?
> tag spécifique oui(lequel?) ou non?
> le truc c'est que le tag spécial commune déléguée peut être facilement
> supprimé plus tard si on décide qu'il est inutile mais plus difficile a
> ajouté quant tous sera fini.
>
>
> Le 30 décembre 2015 à 00:46, Donat ROBAUX <dona...@gmail.com> a écrit :
>
>> Merci Jérome pour le lien. J'avoue ne même pas avoir pensé à consulter
>> WP... Ils sont vachement plus à jour que nous. Donc nous on est carrément à
>> la ramasse. Ils ont fouillé dans tous les RAA (pas eu le temps de passer
>> partout). Faut dire qu'ils ne sont pas très pratique à consulter.
>> Va falloir aller faire du pompage chez WP ;)
>>
>> Pour info et comme je disais dans un précédent mail: sur Légifrance, les
>> arrêtés étant publiés par date d'arrêté et non par publication au JO, j'ai
>> dû remonter jusqu'à la page 7. Des arrêtés datent de juillet et sont
>> publiés seulement le 29/12/2015. Tu m'étonnes que l'INSEE ne peut pas être
>> à jour... (re clin d’œil à Christian dans le cadre de la BAN).
>>
>

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes


- parce que ce n'est pas un schéma conseillé
- parce que tu es obligé d'analyser de manière spécifique ces tags
- parce que les outils existants ne marcheront pas
- parce que la tendance est à avoir des attributs spécifiques et non des 
valeurs à rallonge. Ça s'analyse mieux.
- parce que lire des dates ISO, ce n'est déjà pas évident, alors des 
dates imbriquées dans des tags style admin_level=8 
(-2016-01-01);9(2016-01-01-)...
C'est comme les heures d'ouverture, sans un programme spécifique c'est 
inutilisable sauf que les heures d'ouvertures sont soit ignorées soit 
gérées. Le faire sur le code INSEE passe encore mais sur des données qui 
sont utilisées pour la visualisation des couches classiques...


Ma proposition suit un des schémas de cycle de vie proposés.


Le 30/12/2015 11:09, Philippe Verdy - verd...@wanadoo.fr a écrit :


Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne 
pas mettre la date ou l'intervalle de dates entre parenthèses après la 
référence, avec en plus la possibilités de plusieurs refs anciennes 
séparées par point-virgule avec chacune la mention de dates? Un seul 
tag alors...


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Par sujet Christian Quest

On 30/12/2015 10:43, osm.sanspourr...@spamgourmet.com wrote:
> pour les *old_ref:INSEE*, je serais plus pour des
> old_ref:INSEE:-2016-01-01=
> (millésimons ! ;-))
>
> Pour le *admin_level=9*, je ne vois pas à quoi tu fais référence : je
> trouve (j'ai regardé uniquement dans l'ouest) et je tombe sur des
> communes associées, déléguées..., bref des choses homogènes qui
> existent déjà, les outils existants ne devraient pas avoir des
> comportement inattendus.

Des choses assez récentes, justement liées au grand bazar actuel des
fusions.
Quelques mois en arrière on n'en avait aucune et pour récupérer les
arrondissements municipaux admin_level=9 + ref:INSEE suffisait... là on
récupère plein d'autre choses qui n'ont pas de rapport.

> Tu ne penses pas au niveau ComCom qui n'est pas (plus) un niveau
> administratif et qui n'est pas de niveau 9 ?
> Les exceptions sont les arrondissements municipaux et ils sont bien
> une subdivision des trois communes PLM comme le sont les communes
> déléguées, donc au même niveau. Pas de même nature, d'où l'autre attribut.
>

Je pense mal me faire comprendre... je ne parle pas d'une modélisation
dans l'absolu "ex-nihilo" où oui, admin_level=9 me semblerait adapté. Je
parle d'une utilisation actuelle des données qui va être potentiellement
impactée si on ne prend pas en compte de nouveaux tags, impact qui
serait beaucoup plus limité si on faisait ça sur admin_level=10 qui
n'avait pas l'homogénéité de admin_level=9

> En ajoutant sur les communes devenues déléguées un tag spécifique style :
> *? **admin_type:FR=commune déléguée*
> on a moyen de changer sans problème.
>

Si on connait ce tag... or les scripts et traitement existant ne le
connaissent pas. Il faut les modifier pour qu'ils ne soient pas impactés...

> Ma requête :
> /relation[admin_level=9]({{bbox}})//
> // ); out center;/
>
> *? source=le JO ou l’arrêté préfectoral**
> ***Le JO c'est plutôt mieux, mais pour Audierne il n'était pas sorti
> (maintenant c'est JORFTEXT31690191)
> dep,nouvelle,anciennes,date,population,chflieu,jorf
> 29,Audierne,Audierne|Esquibien,,3839,Audierne,JORFTEXT31690191
>
> *? start_date=2016-01-01 ou end_date ou autre chose**
> *(pour les communes déléguées)
> Comme c'est "seulement" le niveau administratif qui change, ça ma gène
> un peu de mettre un start_date ou un end_date.
> C'est pour cela que je proposais :
> admin_level:-2016-01-01=8
> admin_level:2016-01-01-=9
> (plus un admin_level=8 jusqu'à demain soir et 9 au delà,
> admin_level=8 et
> admin_level:proposed=9 permettent de scripter le changement à minuit)
> Comme ça les outils marchent (admin_level est correct) et on ne perd
> pas l'information.
> Mais comme dit Vincent, ça crée des tags en plus. Ceci dit, ça permet
> d'affiner. Allez, des volontaires pour faire une animation en CSS par
> exemple pour visualiser les changements ? Ça pourrait être parlant
> pour la promotion d'OSM auprès de la PQR ou des voisins de bureau de
> Christian.
>
> Jean-Yvon
>

Mettre la plage temporelle dans le tag, ça les rend fort inutilisables
si ce n'est pas rendu plus générique. J'avais proposé quelque chose du
genre il y a un bout de temps, mais l'allergie ambiante aux données
"historiques" avait eu raison de cette proposition.
Les tags que tu présente me semble une fausse bonne idée.

Quelqu'un a regardé comment c'est géré dans d'autres pays ?

admin_level=9 + disused:admin_level=8 ça pourrait aussi le faire, mais
on n'a pas d'info sur la date de changement.

J'avance sur le script... il prend maintenant en compte les nouvelles
communes déjà présentes.
J'ai aussi continué à compléter le CSV. Vous pouvez faire des pull
requests...

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

L'analyse spécifique des tags est moins compliquée que de savoir quels tags
chercher pour trouver les objets. Maintenant dans les deux cas tu auras du
traitement spécifique. C'est une limite d'osm qui ne permet toujours pas
des valeurs structurée et de vrais schémas d'analyse. Il est limite au
couple clé valeur avec une recherche exacte sur la clé. Hors ta proposition
implique de toute façon une clé spécifique pour chaque date. On ne trouvera
donc cette clé que si on a trouve l'objet dans une liste sans regarder
cette clé et charge tous les tags de l'objet pour savoir si on le prend ou
pas.
Je ne vois de toute façon aucune bonne solution.
Le 30 déc. 2015 11:32,  a écrit :

> - parce que ce n'est pas un schéma conseillé
> - parce que tu es obligé d'analyser de manière spécifique ces tags
> - parce que les outils existants ne marcheront pas
> - parce que la tendance est à avoir des attributs spécifiques et non des
> valeurs à rallonge. Ça s'analyse mieux.
> - parce que lire des dates ISO, ce n'est déjà pas évident, alors des dates
> imbriquées dans des tags style admin_level=8 (-2016-01-01);9(2016-01-01-)...
> C'est comme les heures d'ouverture, sans un programme spécifique c'est
> inutilisable sauf que les heures d'ouvertures sont soit ignorées soit
> gérées. Le faire sur le code INSEE passe encore mais sur des données qui
> sont utilisées pour la visualisation des couches classiques...
>
> Ma proposition suit un des schémas de cycle de vie proposés.
>
>
> Le 30/12/2015 11:09, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne pas
> mettre la date ou l'intervalle de dates entre parenthèses après la
> référence, avec en plus la possibilités de plusieurs refs anciennes
> séparées par point-virgule avec chacune la mention de dates? Un seul tag
> alors...
>
>
> ___
> 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] Communes nouvelles - fusion de communes

2015-12-30 Par sujet Tyndare


Sur tous les exemples que j'ai vu le tag ref:INSEE était indiqué sur le nœud 
place, (admin_center)
Si le noeud place correspond au panneau 
du village et non a la commune le tag ref:INSEE n'a pas de sens ici, il 
faudrait le déplacer systématiquement sur la relation admin (pour toutes les 
communes de France)

Je suis mitigé pour basculer les codes INSEE historiques en old_ref
Même si il ne sont plus actifs ils restent toujours plus ou moins valides.





Le 30 décembre 2015 08:05:15 GMT+01:00, "Vincent de Château-Thierry" 
 a écrit :

>Un point qui reste à fixer est le devenir du tag ref:INSEE des communes
>
>déléguées :
>- est-ce qu'elles gardent le tag ref:INSEE sur leur relation admin ?
>ou
>- est-ce qu'on change plutôt ce tag en old_ref:INSEE ? (Rigolez-pas
>dans 
>le fond, on en a déjà ! 
>http://taginfo.openstreetmap.org/keys/old_ref%3AINSEE :) )
>
>vincent



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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes


pour les *old_ref:INSEE*, je serais plus pour des old_ref:INSEE:-2016-01-01=
(millésimons ! ;-))

Pour le *admin_level=9*, je ne vois pas à quoi tu fais référence : je 
trouve (j'ai regardé uniquement dans l'ouest) et je tombe sur des 
communes associées, déléguées..., bref des choses homogènes qui existent 
déjà, les outils existants ne devraient pas avoir des comportement 
inattendus.
Tu ne penses pas au niveau ComCom qui n'est pas (plus) un niveau 
administratif et qui n'est pas de niveau 9 ?
Les exceptions sont les arrondissements municipaux et ils sont bien une 
subdivision des trois communes PLM comme le sont les communes déléguées, 
donc au même niveau. Pas de même nature, d'où l'autre attribut.


En ajoutant sur les communes devenues déléguées un tag spécifique style :
*? **admin_type:FR=commune déléguée*
on a moyen de changer sans problème.

Ma requête :
/relation[admin_level=9]({{bbox}})//
// ); out center;/

*? source=le JO ou l’arrêté préfectoral**
***Le JO c'est plutôt mieux, mais pour Audierne il n'était pas sorti 
(maintenant c'est JORFTEXT31690191)


dep,nouvelle,anciennes,date,population,chflieu,jorf
29,Audierne,Audierne|Esquibien,,3839,Audierne,JORFTEXT31690191


*? start_date=2016-01-01 ou end_date ou autre chose**
*(pour les communes déléguées)
Comme c'est "seulement" le niveau administratif qui change, ça ma gène 
un peu de mettre un start_date ou un end_date.

C'est pour cela que je proposais :
admin_level:-2016-01-01=8
admin_level:2016-01-01-=9
(plus un admin_level=8 jusqu'à demain soir et 9 au delà,
admin_level=8 et
admin_level:proposed=9 permettent de scripter le changement à minuit)
Comme ça les outils marchent (admin_level est correct) et on ne perd pas 
l'information.
Mais comme dit Vincent, ça crée des tags en plus. Ceci dit, ça permet 
d'affiner. Allez, des volontaires pour faire une animation en CSS par 
exemple pour visualiser les changements ? Ça pourrait être parlant pour 
la promotion d'OSM auprès de la PQR ou des voisins de bureau de Christian.


Jean-Yvon


Le 30/12/2015 08:23, Christian Quest - cqu...@openstreetmap.fr a écrit :
Franchement, le admin_level=9 me gène pour la confusion qu'il va créer 
pour les outils l'utilisant déjà actuellement (et il y en a vu que ces 
découpages étaient exhaustifs).


Je ne me battrais pas là dessus, mais ne vous étonnez pas si il y a 
des trucs qui merdent à court terme ici ou là.


Sur le process, je propose de faire ça en deux temps et via le script 
que j'ai écrit:
1) création des nouvelles relations avec admin_level:proposed=8 / 
start_date=2016-01-01

ça laisse un peu de temps pour vérifier...
2) bascule en admin_level=8 et modif des anciennes communes

L'important étant d'avoir le CSV global bien propre. Le script permet 
d'être homogène et ne mobilise plus de temps humain qu'on peut 
remettre à profit sur le contrôle du résultat.



relation commune délégués :
type=boundary
boundary=administrative
name=*
? admin_level=9
? source=le JO ou l’arrêté préfectoral
? admin_type:FR=commune déléguée
? start_date=2016-01-01 ou end_date ou autre chose

il faut bien sur tomber d'accord sur
quel admin_level?
tag spécifique oui(lequel?) ou non?
le truc c'est que le tag spécial commune déléguée peut être facilement 
supprimé plus tard si on décide qu'il est inutile mais plus difficile 
a ajouté quant tous sera fini.



Le 30 décembre 2015 à 00:46, Donat ROBAUX <dona...@gmail.com 
<mailto:dona...@gmail.com>> a écrit :


Merci Jérome pour le lien. J'avoue ne même pas avoir pensé à
consulter WP... Ils sont vachement plus à jour que nous. Donc nous
on est carrément à la ramasse. Ils ont fouillé dans tous les RAA
(pas eu le temps de passer partout). Faut dire qu'ils ne sont pas
très pratique à consulter.
Va falloir aller faire du pompage chez WP ;)

Pour info et comme je disais dans un précédent mail: sur
Légifrance, les arrêtés étant publiés par date d'arrêté et non par
publication au JO, j'ai dû remonter jusqu'à la page 7. Des arrêtés
datent de juillet et sont publiés seulement le 29/12/2015. Tu
m'étonnes que l'INSEE ne peut pas être à jour... (re clin d’œil à
Christian dans le cadre de la BAN).

Donat


-- Message transféré --
From: "Jérôme Amagat" <jerome.ama...@gmail.com
<mailto:jerome.ama...@gmail.com>>
To: "Discussions sur OSM en français"
<talk-fr@openstreetmap.org <mailto:talk-fr@openstreetmap.org>>
Cc:
        Date: Tue, 29 Dec 2015 20:56:15 +0100
Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
pour la liste des communes nouvelles la page wikipedia :

https://fr.wikipedia.org/wiki/Projet_de_communes_fran%C3%A7aises_nouvelles_en_2016
basée sur les arrêtés préfectoraux, me semble bien mieux et
plus à jour le JO vu qu'il faut attendre que ces même arrêté
soit publié au JO


__

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Par sujet Jérôme Amagat

j'ai vu plusieurs fois sur cette liste dire qu'en gros, le passé n'a pas sa
place dans osm, seul le présent compte. Et c'est vrai que dans osm rien
n'est fait pour intégrer facilement les choses qui ont disparues.
Moi je verrais bien :
admin_level=9
start_date=2016-01-01 (c'est bien le début de la commune déléguée)
et pourquoi pas :
disused:admin_level=8 ce qui permet de garder une trace de son ancien
niveau administratif
ça permet de garder dans osm la date de changement et l'ancien tag.

(ou alors avoir 2 relations : l'ancienne en changer admin_level=8 en
disused:admin_level=8 et la nouvelle avec admin_level=9. mais c'est pas
terrible...)

Pour ce qui est du choix d'admin_level et de la création d'un tag
supplémentaire.
admin_level et un tag qui pour un niveau donné représente des choses
différentes vu qu'il est utiliser dans le monde entier mais même au sein
d'un pays il peut représenter différentes choses. on ne peut pas réserver
admin_level=9 aux arrondissements communaux sur la France entière alors
qu'ils sont présents dans 3 communes. Si d'autres "choses" sont plus ou
moins équivalent aux arrondissements communaux en dehors de ces 3 communes
je pense qu'il faut utiliser admin_level=9.

arrondissements communaux vs communes déléguées :
un maire qui a les mêmes pouvoirs pour les 2
une mairie annexe pour les 2
un conseil d'arrondissement vs un *possible* conseil municipal si la
commune nouvelle le décide
le maire et le conseil donne un avis sur les question d'urbanisme, de
voirie pour les 2
peuvent gérer des équipement et donc un budget pour les 2
maire et conseil élus au sein de l’arrondissement (sauf marseille où c'est
un regroupement d'arrondissements) vs maire et conseil issu du conseil
municipale de la commune nouvelle

pour les autre quartiers ailleurs en france, c'est au mieux :
un conseil de quartier qui donne un avis sur les question d'urbanisme, de
voirie

Dans la plupart des communes, je pense que c'est surtout la présence d'un
maire et d'une mairie qui fera la différence entre une commune déléguée et
un simple quartier.

J'ai pas l'impression qu'à l'étranger ils utilisent beaucoup de tag pour
faire la différence entre différent "truc" au sein d'un admin_level. il y a
le tag border_type qui est utiliser dans certain pays (USA, Allemagne)
mais rien de spécifique à un pays.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

On est du même avis. Les trois seules communes de France ont pas a
s'accaparer un tag quand elles fonctionnent de toute façon avec des statuts
particuliers (Marseille compliquant les choses avec ses mairies de
"secteur" qui groupe des arrondissements, Lyon étant en pleine
restructuration aussi) quand on a des centaines de communes a classer en
France. Il y en avait près de 700 avant le changement annonce qui en ajoute
près de 300. Les 1000 l'emportent sur la poignée spécifique pour PLM (dont
les arrondissements respectifs ne sont même pas équivalents entre les trois
villes). En on peut s'attendre a vite en compter des centaines d'autres.
Personne n'a montre qu'une requête du niveau 9 au plan national est utile
et il ne s'agit même pas de changer lés arrondissement existants, qu'on
peut pourtant compléter avec un tag pour bien indiquer que ce sont des
arrondissements municipaux et ce sera vite fait.
Je doute qu'il y ait le moindre problème en pratique, personne ne l'a
montré en fait. Mais si quelqu'un se manifeste on pourra toujours lui dire
de filtrer sur un tag supplémentaire au delà du seul admin_level.
Bref mettons tout de suite ce tag dans ces trois villes et n'en parlons
plus. On a ce qu'ilbfaur alors pour toutes les autres communes délégués et
associées
Le 30 déc. 2015 15:22, "Jérôme Amagat"  a écrit :

> j'ai vu plusieurs fois sur cette liste dire qu'en gros, le passé n'a pas
> sa place dans osm, seul le présent compte. Et c'est vrai que dans osm rien
> n'est fait pour intégrer facilement les choses qui ont disparues.
> Moi je verrais bien :
> admin_level=9
> start_date=2016-01-01 (c'est bien le début de la commune déléguée)
> et pourquoi pas :
> disused:admin_level=8 ce qui permet de garder une trace de son ancien
> niveau administratif
> ça permet de garder dans osm la date de changement et l'ancien tag.
>
> (ou alors avoir 2 relations : l'ancienne en changer admin_level=8 en
> disused:admin_level=8 et la nouvelle avec admin_level=9. mais c'est pas
> terrible...)
>
> Pour ce qui est du choix d'admin_level et de la création d'un tag
> supplémentaire.
> admin_level et un tag qui pour un niveau donné représente des choses
> différentes vu qu'il est utiliser dans le monde entier mais même au sein
> d'un pays il peut représenter différentes choses. on ne peut pas réserver
> admin_level=9 aux arrondissements communaux sur la France entière alors
> qu'ils sont présents dans 3 communes. Si d'autres "choses" sont plus ou
> moins équivalent aux arrondissements communaux en dehors de ces 3 communes
> je pense qu'il faut utiliser admin_level=9.
>
> arrondissements communaux vs communes déléguées :
> un maire qui a les mêmes pouvoirs pour les 2
> une mairie annexe pour les 2
> un conseil d'arrondissement vs un *possible* conseil municipal si la
> commune nouvelle le décide
> le maire et le conseil donne un avis sur les question d'urbanisme, de
> voirie pour les 2
> peuvent gérer des équipement et donc un budget pour les 2
> maire et conseil élus au sein de l’arrondissement (sauf marseille où c'est
> un regroupement d'arrondissements) vs maire et conseil issu du conseil
> municipale de la commune nouvelle
>
> pour les autre quartiers ailleurs en france, c'est au mieux :
> un conseil de quartier qui donne un avis sur les question d'urbanisme, de
> voirie
>
> Dans la plupart des communes, je pense que c'est surtout la présence d'un
> maire et d'une mairie qui fera la différence entre une commune déléguée et
> un simple quartier.
>
> J'ai pas l'impression qu'à l'étranger ils utilisent beaucoup de tag pour
> faire la différence entre différent "truc" au sein d'un admin_level. il y a
> le tag border_type qui est utiliser dans certain pays (USA, Allemagne)
> mais rien de spécifique à un pays.
>
>
> ___
> 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] Communes nouvelles - fusion de communes

2015-12-30 Par sujet Tony Emery

Vous savez qu'il faut aussi prendre en compte un aspect de ces fusions de
communes avec communes déléguées ?

A mon avis, elles sont vouées à disparaître car je ne vois pas l'intérêt à
ce qu'elles se rajoutent entre les communes et les EPCI. Il faut bien avoir
en tête 2 choses :
- Ce système a été mis en place pour gérer les égos des maires de ces
communes déléguées
- Lors des prochaines élections municipales, il y a fort a parier qu'elles
disparaissent...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-nouvelles-fusion-de-communes-tp5862292p5863522.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Par sujet Vincent de Château-Thierry


> De: "Philippe Verdy" 
> 
> Bref mettons tout de suite ce tag dans ces trois villes et n'en
> parlons plus. 

C'est fait.

Paris : https://www.openstreetmap.org/changeset/36263868
Marseille : https://www.openstreetmap.org/changeset/36263888
Lyon  : https://www.openstreetmap.org/changeset/36263911

vincent

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Par sujet Tony Emery

On a bien à faire à de futures mairies annexes des nouvelles communes...

"Ces communes déléguées n’ont pas le statut de collectivité territoriale,
seule la commune nouvelle est dotée de cette qualité. La mise en place de
ces communes déléguées permet également de créer une annexe de la mairie
dans laquelle sont établis les actes de l’état civil concernant les
habitants de la commune déléguée.

Ainsi, les bâtiments abritant actuellement les communes futures membres de
la commune nouvelle garderaient une utilité évidente et permettraient de
conserver un lien de proximité avec les habitants de l’ancienne commune."

courrierdesmaires.fr
  



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-nouvelles-fusion-de-communes-tp5862292p5863524.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Communes nouvelles - script de fusion...


> De: "Christian Quest" 
> 
> Je crains (très) fort que admin_level=9 casse quelques scripts
> existants
> qui s'appuient là dessus pour les arrondissement municipaux
> (exhaustifs). Ces scripts n'iront pas vérifier un nouveau tag sans
> qu'on
> change leur code...
> 
> admin_level=10 me semble moins poser de problème car c'est peu
> utilisé
> (car pas exhaustif du tout) et c'est ce qui a été utilisé jusque là
> pour
> les précédentes fusions.
> Lui adjoindre un admin_type me semble une bonne idée pour préciser de
> quoi il s'agit.

Admin_type est justement là pour permettre le distingo à admin_level égal. 
Aligner l'admin_level des arrondissements municipaux et des communes déléguées 
serait au passage raccord avec ce qu'on peut lire sur WP[1] :

"Les communes nouvelles ont les mêmes compétences que les autres communes. Leur 
fonctionnement est inspiré de celui instauré par la Loi PLM, les communes 
déléguées ayant des compétences proches de celles des arrondissements 
municipaux"

Pour la compatibilité avec les outils existants, admin_type est là pour ça : 
pour cibler les arrondissements, les requêtes existantes peuvent être 
augmentées d'une clause "admin_type=FR:arrondissement municipal" pour retomber 
sur leurs pieds. Rien d'insurmontable, et au final pas de régression.

Quant à la reprise des communes tagguées auparavant en admin_level=10, ça ne 
doit pas être bien long à modifier. Il faut juste ne pas embarquer au passage 
les _quartiers_ ayant le même tag. Ce qui rendra la situation plus claire en ne 
mélangeant plus quartiers et communes fusionnées sous le même tag, sachant que 
ces dernières peuvent contenir des quartiers, comme par exemple :
http://www.ville-cherbourg.fr/themes/ma-ville/democratie-participative/conseils-de-quartier/

vincent

[1] : https://fr.wikipedia.org/wiki/Commune_nouvelle#Fonctionnement

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes postaux)

Sauf que les communautés de communes, hormi l'usage adminsitratif, bien peu
de monde les connait, et recherche dessus. On ne les voit même pas
facilement sur le terrain hormi les bureaux de la structure communautaire.
Ca intéresse alors les statisticiens surtout. En plus leurs noms officiels
sont souvent "imbittables", beaucoup trop longs pour être retenus et épelés
correctement.
Pour les communes nouvelles, il faudra du temps pour les reconniatre à
moins qu'elles reprennent le nom d'une de la commune déléguée chef-lieu.

Pour 2016 on aura aussi du mal à situer avec les noms actuels (provisoires
jusqu'à juillet prochain) des nouvelles régions. Pendant longtemps on
cherchera encore sur les noms et limites actuelles des régions, sauf si ces
nouvelles régions optent pour des noms simples (pas évident de concilier
les intérets de chacune des anciennes régions qui ne vont plus se
reconniatre, et en attendant un beau merdier pour les offices de tourisme).

Il faudra donc garder les régions actuelles dans leurs limites pour les
recherches, mais avec des tags permettant de les trouver malgré tout. Comme
ce ne seront plus des régions "administrartives" au sens propre, ce seront
des "région culturelles" pendant longtemps. Mais on n'a pas de tag pour ces
régions culturelles (boundary=cultural?) et la solution des "ol_*" ,ne
permet pas les recherches facilement.

Le 29 décembre 2015 à 17:31,  a écrit :

> Je ne vois pas en quoi les réponses de Philippe et de Jérôme, correctes au
> demeurant, répondent à la remarque de Tyndare.
> Et pour moi les nouveaux noms doivent apparaître comme le suggère Tyndare
> (et effectivement contrairement aux communautés de communes).
>
> Pour Audierne et Esquibien, les communes avaient déjà un même code postal.
> Mais ça promet un joli... Fantoir pour les homonymies.
> Je doute que nos moteurs d'adresse soient à jour pour suivre la règle
> indiquée par Tyndare.
>
> Millefeuille administratif, vous en reprendrez bien un peu ?
>
> Jean-Yvon
>
> Le 29/12/2015 17:12, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Le 29 décembre 2015 à 16:53, Jérôme Amagat  a
> écrit :
>
>> pour une adresse il y a besoin du code postal aussi et  il n’apparaît pas
>> sur les rendu.
>>
>
> le code postal apparait dans les recherches Nominatim, je ne pense pas que
> c'est pertinent sur la carte elle-même (du moins un fond de carte
> générique), il ne sert jamais pour la navigation, on ne le voit pas plus
> sur les GPS automobiles, sauf justement dans la fonction de recherche
> d'adresse qui permet de choisir une ville de destination ou un point
> d'intérêt avec son adresse complète... avant de localiser le lieu sur la
> carte.
>
> Un code postal pourra en revanche apparaitre sur uen carte proposant une
> liste de POI cliquables: c'est sur le panneau d'information du POI qu'on
> trouve ces détails, jamais sur la carte (et pour l'instant je n'ai jamais
> vu non plus de carte de France des codes postaux, ni même ailleurs dans
> aucun pays.
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes


Tyndare,
Bah, tu sais j'ai bien contacté les Romains (habitants de Rome) et 
modifié Washington pour que ces capitales apparaissent assez rapidement.
L'affichage des textes est un sujet complexe et les moteurs de rendus ne 
sont pas parfaits... voir loin d'être parfaits.
Même le moteur français (qui est un des moins mauvais) affiche St-Avé 
plutôt que Lorient, Vannes ou Auray dans la coin.
La raison ? Un peu au nord de Vannes il est affiché avant et masque donc 
Vannes.
Là manquait le capital=6 sur Vannes (Vannes est le siège de la 
préfecture du Morbihan).
Je viens de corriger (au fait, le Morbihan 
 est 
devenu un département en pointillé !)


Christian te dira : http://overpass-turbo.eu/s/dsc ;-)

> Quel rendu existant l'affiche correctement ?
J'ai fait un pot-pourri de représentations de données OSM (autour 
d'Audierne) : les informations affichées / vies en évidence sont très 
différentes :

http://mc.bbbike.org/mc/?lon=-4.606605=48.039063=11=12=osmfr=geofabrik-german=geofabrik-topo=mapbox-hybrid=osm-administrative-boundaries=comic-sans=osmfr=osmfr-hot=osmfr-openriverboatmap=osm-roads=osm-semitransparent=wanderreitkarte=

Comme conseillé sur 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Arrondissements_municipaux_ou_communes_associ.C3.A9es 
:



 /Sur la relation/

//

 * /type =boundary
   /
 * /boundary
   =administrative
   /

//

/Propositions : /

//

 * /admin_level =9
   /
 * /ref:INSEE =*//(le
   code INSEE de l'arrondissement municipal, attention « INSEE » est
   bien en majuscule) /

//


 /Sur les membres/

//


   /Chemins/

//

 * /admin_level =9
   /
 * /boundary
   =administrative
   /


   Et pour les communes :


   /Nœuds/

//

/En proposition : Le chef-lieu : /

//

 * /role : admin_centre
   //Le rôle
   admin_centre sera positionné sur le nœud représentant la chef-lieu
   de la commune, par ex. //*La Combe*//pour la commune //*Les
   Déserts*//, ou //*Paris*//pour la commune //*Paris*//. Pour des
   explications sur ce rôle, voir //la page décrivant la relation
   boundary
   
/


Tu disais place, je pensais admin_centre.
Tu dois avoir un chef-lieu ayant pour nom l'endroit en question.

Sinon il existe aussi capital 
=8 qui 
permet de rendre visible la donnée avec d'autres moteurs.
Oui c'est pour du rendu ;-) mais si on n'indique pas l'importance de la 
relation par des admin_level et de la population, c'est difficile de 
bien représenter.



Il y a de nombreux cas où ajouter un tag place n'aura pas vraiment de
sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce
"place" ?
http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691
Au niveau du chef-lieu ? Ça ne pas de sens


Ce serait un doublon avec admin_centre et l'un cacherait l'autre.
Donc nécessairement ailleurs.
C'est justement là que le "place" peut avoir sa raison d'être. Près du 
barycentre, là où il ne masquera pas d'informations importantes Je 
dirais environ en 47.1109, -1.0758

Actuellement la réponse est que la relation n'est pas affichée :
http://mc.bbbike.org/mc/?lat=47.1109=-1.0758=11=12=osmfr=geofabrik-german=geofabrik-topo=mapbox-hybrid=osm-administrative-boundaries=comic-sans=osmfr=osmfr-hot=osmfr-openriverboatmap=osm-roads=osm-semitransparent=wanderreitkarte=


Jean-Yvon

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

pour une adresse il y a besoin du code postal aussi et  il n’apparaît pas
sur les rendu.

Le 29 décembre 2015 à 16:48, Tyndare  a écrit :

> Non la situation est à l'opposé des communautés de communes, les gens
> extérieurs auront au contraire à tout pris besoin de connaitre le nom des
> communes nouvelles car il sera utilisé pour les adresses:
>
>
> http://www.amf.asso.fr/document/fichier.asp?FTP=AMF_13703TELECHARGER_LA_NOTE.pdf_DOC=13703_N_ID=7
>
>
>
>
> Le 29 décembre 2015 14:47:35 GMT+01:00, "Jérôme Amagat" <
> jerome.ama...@gmail.com> a écrit :
>>
>>
>>
>> Le 29 décembre 2015 à 14:15, Tyndare  a écrit :
>>
>>>
>>>
>>> Le 29 décembre 2015 12:46:21 GMT+01:00, "Stéphane Péneau" <
>>> stephane.pen...@wanadoo.fr> a écrit :
>>> >Le 29/12/2015 11:49, Tyndare a écrit :
>>> >> Pour résumer si je n'étais pas claire: Contrairement a ce qui semble
>>> >> être l'avis majoritaire et ce qui a été fait jusqu'à maintenant pour
>>> >> les communes nouvelles j'aurais voulu rajouter un tag place avec le
>>> >> nom des communes nouvelles créés.
>>> >
>>> >Il y a de nombreux cas où ajouter un tag place n'aura pas vraiment de
>>> >sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce
>>> >"place" ?
>>> >http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691
>>> >
>>> >Au niveau du chef-lieu ? Ça ne pas de sens
>>>
>>> Pour moi si ça aurait tout son sens de le mettre au niveau du chef-lieu,
>>> où se trouve la mairie de la commune.
>>>
>>
>> donc tu mettrai au même endroit le nom de la commune et le nom de la
>> ville mais s'ils sont différents? le fait que c'est le chef lieu c'est
>> inscrit dans la relation avec le rôle admin_centre.
>>
>>
>>> Mais je veux bien admettre que je soit influencé par le rendu, zapper
>>> une commune de plus de 20'000 habitants et n'afficher que le nom des
>>> quartiers (admin level = 10) ce n'est pas super pratique comme carte ;-)
>>>
>>> le nom de la commune de 2 habitants n’apparaît peut être pas sur le
>> rendu mais la ville de 15000 habitant au milieu de la commune apparaît bien
>> et c'est ce qui est important pour la plupart des gens et il me semble pas
>> que les admin_level=10 sont plus indiqué que les 8, si il y a un node
>> place=suburb avec son nom ou un truc du genre il apparaîtra sinon non.
>>
>> Pour les communes qui vont être créer ou celle déjà créé par fusion le
>> plus important c'est le nom des ville et village, le nom de la commune
>> apparaît beaucoup moins et est beaucoup moins utilisé. c'est comme les
>> communauté de commune, à part la tienne est t il important et utile dans la
>> vie de tous les jours de connaître le nom et la composition des autres
>> communauté de communes.
>>
>>
>>
>>
>>
>>> Quel rendu existant l'affiche correctement ?
>>>
>>>
>>> ___
>>> 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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes


> Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
> Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté 
qui le justifie.
Regarde justement la définition de la relation Douarnenez : elle est 
basée sur les communes.
Et comme on change les communes, afin que le canton ne change pas il 
faut changer le canton.

Je parle de http://www.openstreetmap.org/relation/4028420
Le JO précise :
/
//Le canton n° 10 (Douarnenez) comprend les communes suivantes : 
*Audierne*, Beuzec-Cap-Sizun, Cléden-Cap-Sizun, Confort-Meilars, 
Douarnenez, *Esquibien*, Goulien, Ile-de-Sein, Le Juch, Kerlaz, Mahalon, 
Plogoff, Plouhinec, Pont-Croix, Pouldergat, Poullan-sur-Mer, Primelin.//
//Le bureau centralisateur de ce canton est le bureau centralisateur de 
la commune de Douarnenez.//

/
La commune d'/*Esquibien*/ disparaît, la commune d'Audierne comprend au 
1er janvier les anciennes communes d'Audierne et d'Esquibien.
Le canton n°10 reste donc a périmètre constant et perd la commune 
d'Esquibien.
À moins que tu considères que le canton perde Esquibien sans qu'Audierne 
n'épouse les nouvelles frontières.

Pas très cohérent.

Donc je maintiens :
Audierne (ancien) + Esquibien jusqu'à la fin de l'année et Audierne 
(nouveau) au delà, pas besoin de modification au JO pour le canton 10.


Jean-Yvon

Le 29/12/2015 15:38, Philippe Verdy - verd...@wanadoo.fr a écrit :

Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
Les communes découpées par les cantons sont légion en France, ils 
n'ont aucune obligation à inclure des communes entières (d'autant plus 
que les communes déléguées sont encore des communes).
Rien ne justifie de modifier les cantons qui sont formés sur des 
comptes de population.
Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté 
qui le justifie.




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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Philippe, tu bases si tu veux le canton sur la base de communes qui 
n'existeront plus dans 3 jours, de facto, la définition basée sur les 17 
communes de l'époque ou sur les 16 communes d'aujourd'hui, tu obtiens le 
même découpage et si tu cherches ce à quoi correspond le canton en 
question, il vaut mieux qu'on te parle en Euro qu'en anciens Francs.


Florent, dans le cas du canton de Douarnenez, il n'y aura probablement 
jamais de décret, d'arrêté ou ce que tu veux car les limites ne changent 
pas dans la pratique. Dans l'arrêtédu 16 octobre 2015 portant création 
de la commune nouvelle d'Audierne 
 
il est précisé qu'"il est créé une commune nouvelle en lieu et place des 
communes d'Audierne et d'Esquibien (canton de Douarnenez, arrondissement 
de Quimper)".

Les anciennes communes faisaient du canton 10, la nouvelle aussi.
Pour moi, ça suffit pour faire la (non) modification.

Jean-Yvon

Le 29/12/2015 17:55, Philippe Verdy - verd...@wanadoo.fr a écrit :
Non ! Le décret est daté et mentionne les communes dans leurs limites 
à la date de l'arrêté (et si ce n'est pas les limties de communes ce 
sont des lites de rues ou cordonnées géographiques pour découper les 
communes, ou les noms d'anciennes communes.


Toute extension de canton sur les limites de nouvelles commune 
nécessitera le temps venu un nouvel arrêté, pour le découpage 
cantonnal suivant. Les arrêtes de cération de commune nouvelle n'ont 
AUCUN effet sur les cantons! Ce n'est pas du tout le même dispositif 
légal d'ailleurs, les cantons étant pour les élections départementales 
et sans aucun effet sur les communes (sauf que les communes sont 
chargées d'organiser les élections au nom de l'Etat et maintenir les 
listes électorales à jour quel que soit le type de scrutin national ou 
local).


Le 29 décembre 2015 à 17:35, > a écrit :


> Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
> Merci d'annuler ta modif des cantons, il n'y a aucun décret ou
arrêté qui le justifie.
Regarde justement la définition de la relation Douarnenez : elle
est basée sur les communes.
Et comme on change les communes, afin que le canton ne change pas
il faut changer le canton.
Je parle de http://www.openstreetmap.org/relation/4028420
Le JO précise :
/
//Le canton n° 10 (Douarnenez) comprend les communes suivantes :
*Audierne*, Beuzec-Cap-Sizun, Cléden-Cap-Sizun, Confort-Meilars,
Douarnenez, *Esquibien*, Goulien, Ile-de-Sein, Le Juch, Kerlaz,
Mahalon, Plogoff, Plouhinec, Pont-Croix, Pouldergat,
Poullan-sur-Mer, Primelin.//
//Le bureau centralisateur de ce canton est le bureau
centralisateur de la commune de Douarnenez.//
/
La commune d'/*Esquibien*/ disparaît, la commune d'Audierne
comprend au 1er janvier les anciennes communes d'Audierne et
d'Esquibien.
Le canton n°10 reste donc a périmètre constant et perd la commune
d'Esquibien.
À moins que tu considères que le canton perde Esquibien sans
qu'Audierne n'épouse les nouvelles frontières.
Pas très cohérent.

Donc je maintiens :
Audierne (ancien) + Esquibien jusqu'à la fin de l'année et
Audierne (nouveau) au delà, pas besoin de modification au JO pour
le canton 10.

Jean-Yvon

Le 29/12/2015 15:38, Philippe Verdy - verd...@wanadoo.fr
 a écrit :

Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
Les communes découpées par les cantons sont légion en France, ils
n'ont aucune obligation à inclure des communes entières (d'autant
plus que les communes déléguées sont encore des communes).
Rien ne justifie de modifier les cantons qui sont formés sur des
comptes de population.
Merci d'annuler ta modif des cantons, il n'y a aucun décret ou
arrêté qui le justifie.




___
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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes postaux)

ce que je voulais dire quand j'ai parler des codes postaux invisible sur
les rendu c'est que même si les noms des communes nouvelles apparaissent
sur le rendu il te manquera toujours des info pour avoir une adresse (le
code postal) et pourtant personne ne demande qu'il apparaissent sur le
rendu.
le truc important c'est que les données dans osm soit le plus proche de la
réalité, les communes ont une surface connue et fixe donc dans osm elle
sont representé par une relation avec les frontière comme membres. Les
villes et villages c'est un groupe d'habitation sans surface très claire
(quelque point sont matérialisé sur le terain, les panneaux d'entrée
d'agglo) et sont représenté dans osm le plus souvent par un point avec
place=town village
Pour le nom, si a l'entrée du village le panneau indique comme nom "machin"
"commune de truc" alors on doit avoir un place=village name=machin et une
relation pour la commune avec name=truc

Après c'est la ou les personnes qui créée le rendu qui décide ce qu'il va
apparaître sur le rendu.

Le 29 décembre 2015 à 17:42, Philippe Verdy  a écrit :

> Sauf que les communautés de communes, hormi l'usage adminsitratif, bien
> peu de monde les connait, et recherche dessus. On ne les voit même pas
> facilement sur le terrain hormi les bureaux de la structure communautaire.
> Ca intéresse alors les statisticiens surtout. En plus leurs noms officiels
> sont souvent "imbittables", beaucoup trop longs pour être retenus et épelés
> correctement.
> Pour les communes nouvelles, il faudra du temps pour les reconniatre à
> moins qu'elles reprennent le nom d'une de la commune déléguée chef-lieu.
>
> Pour 2016 on aura aussi du mal à situer avec les noms actuels (provisoires
> jusqu'à juillet prochain) des nouvelles régions. Pendant longtemps on
> cherchera encore sur les noms et limites actuelles des régions, sauf si ces
> nouvelles régions optent pour des noms simples (pas évident de concilier
> les intérets de chacune des anciennes régions qui ne vont plus se
> reconniatre, et en attendant un beau merdier pour les offices de tourisme).
>
> Il faudra donc garder les régions actuelles dans leurs limites pour les
> recherches, mais avec des tags permettant de les trouver malgré tout. Comme
> ce ne seront plus des régions "administrartives" au sens propre, ce seront
> des "région culturelles" pendant longtemps. Mais on n'a pas de tag pour ces
> régions culturelles (boundary=cultural?) et la solution des "ol_*" ,ne
> permet pas les recherches facilement.
>
> Le 29 décembre 2015 à 17:31,  a écrit :
>
>> Je ne vois pas en quoi les réponses de Philippe et de Jérôme, correctes
>> au demeurant, répondent à la remarque de Tyndare.
>> Et pour moi les nouveaux noms doivent apparaître comme le suggère Tyndare
>> (et effectivement contrairement aux communautés de communes).
>>
>> Pour Audierne et Esquibien, les communes avaient déjà un même code postal.
>> Mais ça promet un joli... Fantoir pour les homonymies.
>> Je doute que nos moteurs d'adresse soient à jour pour suivre la règle
>> indiquée par Tyndare.
>>
>> Millefeuille administratif, vous en reprendrez bien un peu ?
>>
>> Jean-Yvon
>>
>> Le 29/12/2015 17:12, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> Le 29 décembre 2015 à 16:53, Jérôme Amagat  a
>> écrit :
>>
>>> pour une adresse il y a besoin du code postal aussi et  il n’apparaît
>>> pas sur les rendu.
>>>
>>
>> le code postal apparait dans les recherches Nominatim, je ne pense pas
>> que c'est pertinent sur la carte elle-même (du moins un fond de carte
>> générique), il ne sert jamais pour la navigation, on ne le voit pas plus
>> sur les GPS automobiles, sauf justement dans la fonction de recherche
>> d'adresse qui permet de choisir une ville de destination ou un point
>> d'intérêt avec son adresse complète... avant de localiser le lieu sur la
>> carte.
>>
>> Un code postal pourra en revanche apparaitre sur uen carte proposant une
>> liste de POI cliquables: c'est sur le panneau d'information du POI qu'on
>> trouve ces détails, jamais sur la carte (et pour l'instant je n'ai jamais
>> vu non plus de carte de France des codes postaux, ni même ailleurs dans
>> aucun pays.
>>
>>
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Les membres de relation ne devraient même pas bouger non plus: les communes
nouvelles sont de nouvelles entités indépendantes des anceinnes communes
qui restent liés à la définition initiale des cantons, même si leur statut
a changé (mais pas leur frontière ni même leur état de "commune" même si
leurs compétences propres sont transférées à la nouvelle entité dans la
plupart des domaines... mais pas tous).

Bref pour les communes nouvelles ce devraient être de nouvelles relations,
les actuelles devraient rester mais avec des tags différents (adminj_lvel
passé à 9 et plus 8, plus un tag encore en projet pour les statuts des
communes déléguées différents de celui d'un arrondissement, bien que ce
soit pratiquement la même chose à la terminologie prêt). Donc pas de
modification des membres non plus pouir les cantons (pas plus que leurs
ways frontières membres).

Le 29 décembre 2015 à 18:44, Jérôme Amagat  a
écrit :

> ce que veux dire Philippe c'est qu'il ne faut pas modifié les frontière
> des cantons sauf si un décret le dit clairement.
> Mais la ce n’était pas le problème les limite du cantons ne bougeaient pas
> mais un membre de la relation avec le role subarea.
> Donc je pense que vous êtes tous d’accord en fait!
>
> Le 29 décembre 2015 à 18:24,  a écrit :
>
>> Philippe, tu bases si tu veux le canton sur la base de communes qui
>> n'existeront plus dans 3 jours, de facto, la définition basée sur les 17
>> communes de l'époque ou sur les 16 communes d'aujourd'hui, tu obtiens le
>> même découpage et si tu cherches ce à quoi correspond le canton en
>> question, il vaut mieux qu'on te parle en Euro qu'en anciens Francs.
>>
>> Florent, dans le cas du canton de Douarnenez, il n'y aura probablement
>> jamais de décret, d'arrêté ou ce que tu veux car les limites ne changent
>> pas dans la pratique. Dans l'arrêté du 16 octobre 2015 portant création
>> de la commune nouvelle d'Audierne
>> 
>> il est précisé qu'"il est créé une commune nouvelle en lieu et place des
>> communes d'Audierne et d'Esquibien (canton de Douarnenez, arrondissement de
>> Quimper)".
>> Les anciennes communes faisaient du canton 10, la nouvelle aussi.
>> Pour moi, ça suffit pour faire la (non) modification.
>>
>> Jean-Yvon
>>
>>
>> Le 29/12/2015 17:55, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> Non ! Le décret est daté et mentionne les communes dans leurs limites à
>> la date de l'arrêté (et si ce n'est pas les limties de communes ce sont des
>> lites de rues ou cordonnées géographiques pour découper les communes, ou
>> les noms d'anciennes communes.
>>
>> Toute extension de canton sur les limites de nouvelles commune
>> nécessitera le temps venu un nouvel arrêté, pour le découpage cantonnal
>> suivant. Les arrêtes de cération de commune nouvelle n'ont AUCUN effet sur
>> les cantons! Ce n'est pas du tout le même dispositif légal d'ailleurs, les
>> cantons étant pour les élections départementales et sans aucun effet sur
>> les communes (sauf que les communes sont chargées d'organiser les élections
>> au nom de l'Etat et maintenir les listes électorales à jour quel que soit
>> le type de scrutin national ou local).
>>
>> Le 29 décembre 2015 à 17:35,  a écrit :
>>
>>> > Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
>>> > Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté
>>> qui le justifie.
>>> Regarde justement la définition de la relation Douarnenez : elle est
>>> basée sur les communes.
>>> Et comme on change les communes, afin que le canton ne change pas il
>>> faut changer le canton.
>>> Je parle de http://www.openstreetmap.org/relation/4028420
>>> Le JO précise :
>>>
>>> *Le canton n° 10 (Douarnenez) comprend les communes suivantes :
>>> Audierne, Beuzec-Cap-Sizun, Cléden-Cap-Sizun, Confort-Meilars, Douarnenez,
>>> Esquibien, Goulien, Ile-de-Sein, Le Juch, Kerlaz, Mahalon, Plogoff,
>>> Plouhinec, Pont-Croix, Pouldergat, Poullan-sur-Mer, Primelin.*
>>> * Le bureau centralisateur de ce canton est le bureau centralisateur de
>>> la commune de Douarnenez.*
>>>
>>> La commune d'*Esquibien* disparaît, la commune d'Audierne comprend au
>>> 1er janvier les anciennes communes d'Audierne et d'Esquibien.
>>> Le canton n°10 reste donc a périmètre constant et perd la commune
>>> d'Esquibien.
>>> À moins que tu considères que le canton perde Esquibien sans qu'Audierne
>>> n'épouse les nouvelles frontières.
>>> Pas très cohérent.
>>>
>>> Donc je maintiens :
>>> Audierne (ancien) + Esquibien jusqu'à la fin de l'année et Audierne
>>> (nouveau) au delà, pas besoin de modification au JO pour le canton 10.
>>>
>>> Jean-Yvon
>>>
>>> Le 29/12/2015 15:38, Philippe Verdy - 
>>> verd...@wanadoo.fr a écrit :
>>>
>>> Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
>>> Les communes découpées par les cantons sont

Re: [OSM-talk-fr] Communes nouvelles - script de fusion...

Le 29 décembre 2015 à 16:04, Christian Quest  a
écrit :

> Je crains (très) fort que admin_level=9 casse quelques scripts existants
> qui s'appuient là dessus pour les arrondissement municipaux
> (exhaustifs). Ces scripts n'iront pas vérifier un nouveau tag sans qu'on
> change leur code...
>

C'est une cainte très théorique qui n'est appuyée par aucun outil visible.
S'il y en a c'est très confidentiel mais comme personne ne les a signalés,
on peut ignorer. Ce n'est de toute façon pas pire que les niveaux 6 et 8 en
France (si ces scripts croient n'accéder que strictement à des départements
ou des communes simples).

Et Franchement pour les communes déléguées ou associées, on ne s'attend pas
à les trouver au milieu de listes de quartiers. Cela a un sens en revanche
de chercher toutes les communes ayant un maire, même si ce ne sont pas (ou
ne sont plus) des collectivités locales autonomes, et d'y trouver alors des
arrondissements de PLM et des communes déléguées ou associées ailleurs, et
de créer une liste de toutes les communes (quel que soit leur statut ou
leur autonomie) en prenant tous les niveau 8 et 9, et ensuite pouvoir y
chercher les état-civils correspondants, et tous les maires élus (même
s'ils ne président pas le conseil municipal). Sinon avec le niveau 10, il
faudrait faire l'union des niveau 8,9,10 sans pouvoir non plus éliminer
facielemtn les quartiers de villes (avec cette union on aurait alors
mélangés non seulement la commune de Paris, et ses 20 arrondissements, mais
aussi tous ses quartiers qui n'ont rien du tout d'une commune et aucun élu
propre dans lke conseil municipal, contraitrement aux élus
d'arrondissements)

Bref je pense que ta crainte est vraiement celle de celui d'un coupeurt de
cheveux en 4: si ta crainte est fondée, il n'y a pas plus de raison non
plus de mettres les communes déléguées ou associées au niveau 10, et il
manque alors un niveau. Mais pas question de mettre des niveaux
"fractionnaires".
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes postaux)

Je ne vois pas en quoi les réponses de Philippe et de Jérôme, correctes 
au demeurant, répondent à la remarque de Tyndare.
Et pour moi les nouveaux noms doivent apparaître comme le suggère 
Tyndare (et effectivement contrairement aux communautés de communes).


Pour Audierne et Esquibien, les communes avaient déjà un même code postal.
Mais ça promet un joli... Fantoir pour les homonymies.
Je doute que nos moteurs d'adresse soient à jour pour suivre la règle 
indiquée par Tyndare.


Millefeuille administratif, vous en reprendrez bien un peu ?

Jean-Yvon

Le 29/12/2015 17:12, Philippe Verdy - verd...@wanadoo.fr a écrit :
Le 29 décembre 2015 à 16:53, Jérôme Amagat > a écrit :


pour une adresse il y a besoin du code postal aussi et  il
n’apparaît pas sur les rendu.


le code postal apparait dans les recherches Nominatim, je ne pense pas 
que c'est pertinent sur la carte elle-même (du moins un fond de carte 
générique), il ne sert jamais pour la navigation, on ne le voit pas 
plus sur les GPS automobiles, sauf justement dans la fonction de 
recherche d'adresse qui permet de choisir une ville de destination ou 
un point d'intérêt avec son adresse complète... avant de localiser le 
lieu sur la carte.


Un code postal pourra en revanche apparaitre sur uen carte proposant 
une liste de POI cliquables: c'est sur le panneau d'information du POI 
qu'on trouve ces détails, jamais sur la carte (et pour l'instant je 
n'ai jamais vu non plus de carte de France des codes postaux, ni même 
ailleurs dans aucun pays.




___
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] Communes nouvelles - fusion de communes

Non ! Le décret est daté et mentionne les communes dans leurs limites à la
date de l'arrêté (et si ce n'est pas les limties de communes ce sont des
lites de rues ou cordonnées géographiques pour découper les communes, ou
les noms d'anciennes communes.

Toute extension de canton sur les limites de nouvelles commune nécessitera
le temps venu un nouvel arrêté, pour le découpage cantonnal suivant. Les
arrêtes de cération de commune nouvelle n'ont AUCUN effet sur les cantons!
Ce n'est pas du tout le même dispositif légal d'ailleurs, les cantons étant
pour les élections départementales et sans aucun effet sur les communes
(sauf que les communes sont chargées d'organiser les élections au nom de
l'Etat et maintenir les listes électorales à jour quel que soit le type de
scrutin national ou local).

Le 29 décembre 2015 à 17:35,  a écrit :

> > Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
> > Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté
> qui le justifie.
> Regarde justement la définition de la relation Douarnenez : elle est basée
> sur les communes.
> Et comme on change les communes, afin que le canton ne change pas il faut
> changer le canton.
> Je parle de 
> http://www.openstreetmap.org/relation/4028420
> Le JO précise :
>
> *Le canton n° 10 (Douarnenez) comprend les communes suivantes : Audierne,
> Beuzec-Cap-Sizun, Cléden-Cap-Sizun, Confort-Meilars, Douarnenez, Esquibien,
> Goulien, Ile-de-Sein, Le Juch, Kerlaz, Mahalon, Plogoff, Plouhinec,
> Pont-Croix, Pouldergat, Poullan-sur-Mer, Primelin.*
> * Le bureau centralisateur de ce canton est le bureau centralisateur de la
> commune de Douarnenez.*
>
> La commune d'*Esquibien* disparaît, la commune d'Audierne comprend au 1er
> janvier les anciennes communes d'Audierne et d'Esquibien.
> Le canton n°10 reste donc a périmètre constant et perd la commune
> d'Esquibien.
> À moins que tu considères que le canton perde Esquibien sans qu'Audierne
> n'épouse les nouvelles frontières.
> Pas très cohérent.
>
> Donc je maintiens :
> Audierne (ancien) + Esquibien jusqu'à la fin de l'année et Audierne
> (nouveau) au delà, pas besoin de modification au JO pour le canton 10.
>
> Jean-Yvon
>
> Le 29/12/2015 15:38, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
> Les communes découpées par les cantons sont légion en France, ils n'ont
> aucune obligation à inclure des communes entières (d'autant plus que les
> communes déléguées sont encore des communes).
> Rien ne justifie de modifier les cantons qui sont formés sur des comptes
> de population.
> Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté qui
> le justifie.
>
>
>
> ___
> 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] Communes nouvelles - fusion de communes


Le 29/12/2015 10:26, Vincent de Château-Thierry - osm.v...@free.fr a écrit :

Bonjour,


De: "osm sanspourriel" 
 * admin_level = 9

Ça me semble logique et cohérent : c'est le niveau en dessous.
Si vous voulez ajouter un tag pour préciser le lien dans la relation
admin=8 (commune associée, arrondissement de commune), pourquoi
pas.

Tu veux dire dans la relation admin=9 ? Sinon je ne comprends pas ta 
proposition.
On est d’accord, je parlais du rôle de la relation d'admin_level=9 (ou 
10 ou 11) (la commune déléguée, l'arrondissement municipal) dans la 
relation d'admin_level=8 (la nouvelle commune).
On le met au niveau dans la pratique au niveau de l'objet en dessous, 
comme tu dis, mais la commune n'est déléguée que par rapport à la 
commune nouvelle (elle n'exista pas ex-nihilo : une commune déléguée 
fait forcément d'une commune nouvelle) : je parle bien de son rôle dans 
la nouvelle commune (qui est de niveau 8).

Mais je ne vois pas l'intérêt de mettre des niveaux fictifs (il n'y a
pas de communes associées à l'intérieur de PLM sauf erreur, de même
il n'y a pas d'arrondissement de commune dans les commune
fusionnées).

Idem, je ne comprends pas de quels niveaux fictifs tu parles.

vincent
Les niveaux "commune déléguées" ou les niveaux "arrondissement 
municipaux" sont de même niveau (logiquement 9, un de moins que les 
communes de plein exercice) mettre des niveaux 9, 10 ou 11 suivant les 
cas n'apporte pas de clarté au contraire, il semble qu'on a oublié un 
niveau (je sais, dans les niveaux supérieurs il y a des trous).
Je suis plus pour garder des niveaux naturels (càd sans trous) et 
d'ajouter des balises style local_authority:FR 
=* 
pour préciser le type de relation (commune déléguée ou arrondissement 
municipal).


Donat, c'est pire que ça : certains arrêtés (comme celui sur Audierne) 
n'y figuraient pas. Je vois que l'administration peut être efficace car 
je l'ai signalé hier et aujourd'hui il y figure. Peut-être tout 
simplement parce que la génération de la pagé datait d'avant Noël (la 
parution au KO dans de 26 décembre, on n'est pas les seuls à la bourre).


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Le 29 décembre 2015 à 16:53, Jérôme Amagat  a
écrit :

> pour une adresse il y a besoin du code postal aussi et  il n’apparaît pas
> sur les rendu.
>

le code postal apparait dans les recherches Nominatim, je ne pense pas que
c'est pertinent sur la carte elle-même (du moins un fond de carte
générique), il ne sert jamais pour la navigation, on ne le voit pas plus
sur les GPS automobiles, sauf justement dans la fonction de recherche
d'adresse qui permet de choisir une ville de destination ou un point
d'intérêt avec son adresse complète... avant de localiser le lieu sur la
carte.

Un code postal pourra en revanche apparaitre sur uen carte proposant une
liste de POI cliquables: c'est sur le panneau d'information du POI qu'on
trouve ces détails, jamais sur la carte (et pour l'instant je n'ai jamais
vu non plus de carte de France des codes postaux, ni même ailleurs dans
aucun pays.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Je peux vous dire que ce n'est pas aussi binaire que ça et que La Poste
n'a pas vraiment de plan de bataille précis.
C'est un sujet tellement flou qu'on botte en touche dès qu'on l'aborde
dans nos réunion BAN.

On peut revoir tout les référentiels, remettre à plat les noms de
communes, les codes postaux, les bureaux distributeurs (libellés
d'acheminement), etc... les "gens" continueront encore à utiliser les
anciennes adresses pendant bien longtemps !

En fait, La Poste gère dans ses systèmes de tri tout un historique.

Autre sujet hyper sensibles... les voies et lieux-dits homonymes.
J'avais fait un "fusiometre" lors de l'opération libre à Chéméré (qui va
devenir Chaumes-en-Retz avec sa fusion avec Arthon-en-Retz) et on avait
une moyenne d'une vingtaine d'homonymes sur les voies et lieux-dits
habités sur l'ensemble des communes du 44 prises juste 2 à 2.

Le nom de l'ancienne commune sera donc encore utilisé pendant pas mal de
temps pour distinguer les deux "Place de l'Église"...


On 29/12/2015 16:48, Tyndare wrote:
> Non la situation est à l'opposé des communautés de communes, les gens
> extérieurs auront au contraire à tout pris besoin de connaitre le nom
> des communes nouvelles car il sera utilisé pour les adresses:
>
> http://www.amf.asso.fr/document/fichier.asp?FTP=AMF_13703TELECHARGER_LA_NOTE.pdf_DOC=13703_N_ID=7
>
>
>
> Le 29 décembre 2015 14:47:35 GMT+01:00, "Jérôme Amagat"
>  a écrit :
>
>
>
> Le 29 décembre 2015 à 14:15, Tyndare  > a écrit :
>
>
>
> Le 29 décembre 2015 12:46:21 GMT+01:00, "Stéphane Péneau"
>  > a écrit :
> >Le 29/12/2015 11:49, Tyndare a écrit :
> >> Pour résumer si je n'étais pas claire: Contrairement a ce
> qui semble
> >> être l'avis majoritaire et ce qui a été fait jusqu'à
> maintenant pour
> >> les communes nouvelles j'aurais voulu rajouter un tag place
> avec le
> >> nom des communes nouvelles créés.
> >
> >Il y a de nombreux cas où ajouter un tag place n'aura pas
> vraiment de
> >sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce
> >"place" ?
> >http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691
> >
> >Au niveau du chef-lieu ? Ça ne pas de sens
>
> Pour moi si ça aurait tout son sens de le mettre au niveau du
> chef-lieu, où se trouve la mairie de la commune.
>
>
> donc tu mettrai au même endroit le nom de la commune et le nom de
> la ville mais s'ils sont différents? le fait que c'est le chef
> lieu c'est inscrit dans la relation avec le rôle admin_centre.
>  
>
> Mais je veux bien admettre que je soit influencé par le rendu,
> zapper une commune de plus de 20'000 habitants et n'afficher
> que le nom des quartiers (admin level = 10) ce n'est pas super
> pratique comme carte ;-)
>
> le nom de la commune de 2 habitants n’apparaît peut être pas
> sur le rendu mais la ville de 15000 habitant au milieu de la
> commune apparaît bien et c'est ce qui est important pour la
> plupart des gens et il me semble pas que les admin_level=10 sont
> plus indiqué que les 8, si il y a un node place=suburb avec son
> nom ou un truc du genre il apparaîtra sinon non.
>
> Pour les communes qui vont être créer ou celle déjà créé par
> fusion le plus important c'est le nom des ville et village, le nom
> de la commune apparaît beaucoup moins et est beaucoup moins
> utilisé. c'est comme les communauté de commune, à part la tienne
> est t il important et utile dans la vie de tous les jours de
> connaître le nom et la composition des autres communauté de communes.
>  
>
>
>  
>
> Quel rendu existant l'affiche correctement ?
>
>
> ___
> 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
-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes postaux)

Et en quoi le changement de statut des communes affecte les codes postaux ?
En rien du tout. Les codes postaux restent les mêmes (tant que la Poste ne
change pas son propre système). De toute façon les codes postaux ne sont
pas des codes admionistratifs, ils sont juste connus du public plus que les
codes INSEE.
Bref pas besoin de toucher aux codes postaux, sauf si pour être complet
dans la relation de la commune nouvelle, on mentionne une liste de codes
postaux applicables (ce qui a peu d'interêt). On verra bien si la Poste a
besoin de modifier ses codes postaux, mais de toute façon ils ne sont pas
liés aux xcommunes depuis longtemps, avec déjà des exceptions très
nombreuses un peu partout.

De quoi remette au gout du jour la délimitation des zones postales
(boundary=postal), en lieu et place des tags de codes postaux ambigus
portés par les communes.

Le 29 décembre 2015 à 18:38, Jérôme Amagat  a
écrit :

> ce que je voulais dire quand j'ai parler des codes postaux invisible sur
> les rendu c'est que même si les noms des communes nouvelles apparaissent
> sur le rendu il te manquera toujours des info pour avoir une adresse (le
> code postal) et pourtant personne ne demande qu'il apparaissent sur le
> rendu.
> le truc important c'est que les données dans osm soit le plus proche de la
> réalité, les communes ont une surface connue et fixe donc dans osm elle
> sont representé par une relation avec les frontière comme membres. Les
> villes et villages c'est un groupe d'habitation sans surface très claire
> (quelque point sont matérialisé sur le terain, les panneaux d'entrée
> d'agglo) et sont représenté dans osm le plus souvent par un point avec
> place=town village
> Pour le nom, si a l'entrée du village le panneau indique comme nom
> "machin" "commune de truc" alors on doit avoir un place=village name=machin
> et une relation pour la commune avec name=truc
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-29 Par sujet Tyndare

Non la situation est à l'opposé des communautés de communes, les gens 
extérieurs auront au contraire à tout pris besoin de connaitre le nom des 
communes nouvelles car il sera utilisé pour les adresses:

http://www.amf.asso.fr/document/fichier.asp?FTP=AMF_13703TELECHARGER_LA_NOTE.pdf_DOC=13703_N_ID=7



Le 29 décembre 2015 14:47:35 GMT+01:00, "Jérôme Amagat" 
 a écrit :
>Le 29 décembre 2015 à 14:15, Tyndare  a écrit :
>
>>
>>
>> Le 29 décembre 2015 12:46:21 GMT+01:00, "Stéphane Péneau" <
>> stephane.pen...@wanadoo.fr> a écrit :
>> >Le 29/12/2015 11:49, Tyndare a écrit :
>> >> Pour résumer si je n'étais pas claire: Contrairement a ce qui
>semble
>> >> être l'avis majoritaire et ce qui a été fait jusqu'à maintenant
>pour
>> >> les communes nouvelles j'aurais voulu rajouter un tag place avec
>le
>> >> nom des communes nouvelles créés.
>> >
>> >Il y a de nombreux cas où ajouter un tag place n'aura pas vraiment
>de
>> >sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce
>> >"place" ?
>> >http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691
>> >
>> >Au niveau du chef-lieu ? Ça ne pas de sens
>>
>> Pour moi si ça aurait tout son sens de le mettre au niveau du
>chef-lieu,
>> où se trouve la mairie de la commune.
>>
>
>donc tu mettrai au même endroit le nom de la commune et le nom de la
>ville
>mais s'ils sont différents? le fait que c'est le chef lieu c'est
>inscrit
>dans la relation avec le rôle admin_centre.
>
>
>> Mais je veux bien admettre que je soit influencé par le rendu, zapper
>une
>> commune de plus de 20'000 habitants et n'afficher que le nom des
>quartiers
>> (admin level = 10) ce n'est pas super pratique comme carte ;-)
>>
>> le nom de la commune de 2 habitants n’apparaît peut être pas sur
>le
>rendu mais la ville de 15000 habitant au milieu de la commune apparaît
>bien
>et c'est ce qui est important pour la plupart des gens et il me semble
>pas
>que les admin_level=10 sont plus indiqué que les 8, si il y a un node
>place=suburb avec son nom ou un truc du genre il apparaîtra sinon non.
>
>Pour les communes qui vont être créer ou celle déjà créé par fusion le
>plus
>important c'est le nom des ville et village, le nom de la commune
>apparaît
>beaucoup moins et est beaucoup moins utilisé. c'est comme les
>communauté de
>commune, à part la tienne est t il important et utile dans la vie de
>tous
>les jours de connaître le nom et la composition des autres communauté
>de
>communes.
>
>
>
>
>
>> Quel rendu existant l'affiche correctement ?
>>
>>
>> ___
>> 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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

ce que veux dire Philippe c'est qu'il ne faut pas modifié les frontière des
cantons sauf si un décret le dit clairement.
Mais la ce n’était pas le problème les limite du cantons ne bougeaient pas
mais un membre de la relation avec le role subarea.
Donc je pense que vous êtes tous d’accord en fait!

Le 29 décembre 2015 à 18:24,  a écrit :

> Philippe, tu bases si tu veux le canton sur la base de communes qui
> n'existeront plus dans 3 jours, de facto, la définition basée sur les 17
> communes de l'époque ou sur les 16 communes d'aujourd'hui, tu obtiens le
> même découpage et si tu cherches ce à quoi correspond le canton en
> question, il vaut mieux qu'on te parle en Euro qu'en anciens Francs.
>
> Florent, dans le cas du canton de Douarnenez, il n'y aura probablement
> jamais de décret, d'arrêté ou ce que tu veux car les limites ne changent
> pas dans la pratique. Dans l'arrêté du 16 octobre 2015 portant création
> de la commune nouvelle d'Audierne
> 
> il est précisé qu'"il est créé une commune nouvelle en lieu et place des
> communes d'Audierne et d'Esquibien (canton de Douarnenez, arrondissement de
> Quimper)".
> Les anciennes communes faisaient du canton 10, la nouvelle aussi.
> Pour moi, ça suffit pour faire la (non) modification.
>
> Jean-Yvon
>
>
> Le 29/12/2015 17:55, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Non ! Le décret est daté et mentionne les communes dans leurs limites à la
> date de l'arrêté (et si ce n'est pas les limties de communes ce sont des
> lites de rues ou cordonnées géographiques pour découper les communes, ou
> les noms d'anciennes communes.
>
> Toute extension de canton sur les limites de nouvelles commune nécessitera
> le temps venu un nouvel arrêté, pour le découpage cantonnal suivant. Les
> arrêtes de cération de commune nouvelle n'ont AUCUN effet sur les cantons!
> Ce n'est pas du tout le même dispositif légal d'ailleurs, les cantons étant
> pour les élections départementales et sans aucun effet sur les communes
> (sauf que les communes sont chargées d'organiser les élections au nom de
> l'Etat et maintenir les listes électorales à jour quel que soit le type de
> scrutin national ou local).
>
> Le 29 décembre 2015 à 17:35,  a écrit :
>
>> > Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
>> > Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté
>> qui le justifie.
>> Regarde justement la définition de la relation Douarnenez : elle est
>> basée sur les communes.
>> Et comme on change les communes, afin que le canton ne change pas il faut
>> changer le canton.
>> Je parle de http://www.openstreetmap.org/relation/4028420
>> Le JO précise :
>>
>> *Le canton n° 10 (Douarnenez) comprend les communes suivantes : Audierne,
>> Beuzec-Cap-Sizun, Cléden-Cap-Sizun, Confort-Meilars, Douarnenez, Esquibien,
>> Goulien, Ile-de-Sein, Le Juch, Kerlaz, Mahalon, Plogoff, Plouhinec,
>> Pont-Croix, Pouldergat, Poullan-sur-Mer, Primelin.*
>> * Le bureau centralisateur de ce canton est le bureau centralisateur de
>> la commune de Douarnenez.*
>>
>> La commune d'*Esquibien* disparaît, la commune d'Audierne comprend au
>> 1er janvier les anciennes communes d'Audierne et d'Esquibien.
>> Le canton n°10 reste donc a périmètre constant et perd la commune
>> d'Esquibien.
>> À moins que tu considères que le canton perde Esquibien sans qu'Audierne
>> n'épouse les nouvelles frontières.
>> Pas très cohérent.
>>
>> Donc je maintiens :
>> Audierne (ancien) + Esquibien jusqu'à la fin de l'année et Audierne
>> (nouveau) au delà, pas besoin de modification au JO pour le canton 10.
>>
>> Jean-Yvon
>>
>> Le 29/12/2015 15:38, Philippe Verdy - 
>> verd...@wanadoo.fr a écrit :
>>
>> Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
>> Les communes découpées par les cantons sont légion en France, ils n'ont
>> aucune obligation à inclure des communes entières (d'autant plus que les
>> communes déléguées sont encore des communes).
>> Rien ne justifie de modifier les cantons qui sont formés sur des comptes
>> de population.
>> Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté qui
>> le justifie.
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-29 Par sujet Florent RICHARD

Il y a un cas de changement de canton, défini par arrêté 
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT31690124=id
 pour Le Fresne-sur-Loire
Mais il semblerait que ce cas reste exceptionnel.
(de toute façon Le Fresne-sur-Loire a toujours été exceptionnel)

Pour les autres cas, mieux vaut ne pas se mélanger les pinceaux et attendre la 
publication avant de faire les modifications.

Florent

From: Philippe Verdy 
Sent: Tuesday, December 29, 2015 5:55 PM
To: Discussions sur OSM en français 
Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Non ! Le décret est daté et mentionne les communes dans leurs limites à la date 
de l'arrêté (et si ce n'est pas les limties de communes ce sont des lites de 
rues ou cordonnées géographiques pour découper les communes, ou les noms 
d'anciennes communes. 

Toute extension de canton sur les limites de nouvelles commune nécessitera le 
temps venu un nouvel arrêté, pour le découpage cantonnal suivant. Les arrêtes 
de cération de commune nouvelle n'ont AUCUN effet sur les cantons! Ce n'est pas 
du tout le même dispositif légal d'ailleurs, les cantons étant pour les 
élections départementales et sans aucun effet sur les communes (sauf que les 
communes sont chargées d'organiser les élections au nom de l'Etat et maintenir 
les listes électorales à jour quel que soit le type de scrutin national ou 
local).

Le 29 décembre 2015 à 17:35, <osm.sanspourr...@spamgourmet.com> a écrit :

  > Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
  > Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté qui 
le justifie. 
  Regarde justement la définition de la relation Douarnenez : elle est basée 
sur les communes.
  Et comme on change les communes, afin que le canton ne change pas il faut 
changer le canton.
  Je parle de http://www.openstreetmap.org/relation/4028420
  Le JO précise :

  Le canton n° 10 (Douarnenez) comprend les communes suivantes : Audierne, 
Beuzec-Cap-Sizun, Cléden-Cap-Sizun, Confort-Meilars, Douarnenez, Esquibien, 
Goulien, Ile-de-Sein, Le Juch, Kerlaz, Mahalon, Plogoff, Plouhinec, Pont-Croix, 
Pouldergat, Poullan-sur-Mer, Primelin.
  Le bureau centralisateur de ce canton est le bureau centralisateur de la 
commune de Douarnenez.

  La commune d'Esquibien disparaît, la commune d'Audierne comprend au 1er 
janvier les anciennes communes d'Audierne et d'Esquibien.
  Le canton n°10 reste donc a périmètre constant et perd la commune d'Esquibien.
  À moins que tu considères que le canton perde Esquibien sans qu'Audierne 
n'épouse les nouvelles frontières.
  Pas très cohérent.

  Donc je maintiens :
  Audierne (ancien) + Esquibien jusqu'à la fin de l'année et Audierne (nouveau) 
au delà, pas besoin de modification au JO pour le canton 10.

  Jean-Yvon



  Le 29/12/2015 15:38, Philippe Verdy - verd...@wanadoo.fr a écrit :

Non, les cantons ne CHANGENT PAS même en cas de fusion de commune. 
Les communes découpées par les cantons sont légion en France, ils n'ont 
aucune obligation à inclure des communes entières (d'autant plus que les 
communes déléguées sont encore des communes).
Rien ne justifie de modifier les cantons qui sont formés sur des comptes de 
population.
Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté qui 
le justifie.




  ___
  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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-29 Par sujet Donat ROBAUX

Merci Jérome pour le lien. J'avoue ne même pas avoir pensé à consulter
WP... Ils sont vachement plus à jour que nous. Donc nous on est carrément à
la ramasse. Ils ont fouillé dans tous les RAA (pas eu le temps de passer
partout). Faut dire qu'ils ne sont pas très pratique à consulter.
Va falloir aller faire du pompage chez WP ;)

Pour info et comme je disais dans un précédent mail: sur Légifrance, les
arrêtés étant publiés par date d'arrêté et non par publication au JO, j'ai
dû remonter jusqu'à la page 7. Des arrêtés datent de juillet et sont
publiés seulement le 29/12/2015. Tu m'étonnes que l'INSEE ne peut pas être
à jour... (re clin d’œil à Christian dans le cadre de la BAN).

Donat



>
> -- Message transféré --
> From: "Jérôme Amagat" <jerome.ama...@gmail.com>
> To: "Discussions sur OSM en français" <talk-fr@openstreetmap.org>
> Cc:
> Date: Tue, 29 Dec 2015 20:56:15 +0100
> Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
> pour la liste des communes nouvelles la page wikipedia :
>
> https://fr.wikipedia.org/wiki/Projet_de_communes_fran%C3%A7aises_nouvelles_en_2016
> basée sur les arrêtés préfectoraux, me semble bien mieux et plus à jour le
> JO vu qu'il faut attendre que ces même arrêté soit publié au JO
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

sur la page récapitulant les communes nouvelles ça pourrait être bien de
mettre tous les tag a mettre, changer ou enlevé sur la nouvelle commune et
les anciennes pour que tous le monde soit sur la même longueur d'onde.
J'ai vu que christian parlait des ref:INSEE je comprenais pas pourquoi et
je viens de voir que les communes qui ont un an ont repris le ref:insee de
la commune chef lieu et c'est aussi ce qui est indiquer là :
http://www.collectivites-locales.gouv.fr/faq-sur-loi-ndeg-2015-292-16-mars-2015-relative-a-lamelioration-regime-commune-nouvelle-pour-des#insee

relation commune nouvelle :
type=boundary
boundary=administrative
admin_level=8
name=*
start_date=2016-01-01

? source=le JO ou l’arrêté préfectoral
? addr:postcode= le code postal des communes s'il est le même dans toutes
les anciennes communes
wikipedia

relation commune délégués :
type=boundary
boundary=administrative
name=*
? admin_level=9
? source=le JO ou l’arrêté préfectoral
? admin_type:FR=commune déléguée
? start_date=2016-01-01 ou end_date ou autre chose

il faut bien sur tomber d'accord sur
quel admin_level?
tag spécifique oui(lequel?) ou non?
le truc c'est que le tag spécial commune déléguée peut être facilement
supprimé plus tard si on décide qu'il est inutile mais plus difficile a
ajouté quant tous sera fini.


Le 30 décembre 2015 à 00:46, Donat ROBAUX <dona...@gmail.com> a écrit :

> Merci Jérome pour le lien. J'avoue ne même pas avoir pensé à consulter
> WP... Ils sont vachement plus à jour que nous. Donc nous on est carrément à
> la ramasse. Ils ont fouillé dans tous les RAA (pas eu le temps de passer
> partout). Faut dire qu'ils ne sont pas très pratique à consulter.
> Va falloir aller faire du pompage chez WP ;)
>
> Pour info et comme je disais dans un précédent mail: sur Légifrance, les
> arrêtés étant publiés par date d'arrêté et non par publication au JO, j'ai
> dû remonter jusqu'à la page 7. Des arrêtés datent de juillet et sont
> publiés seulement le 29/12/2015. Tu m'étonnes que l'INSEE ne peut pas être
> à jour... (re clin d’œil à Christian dans le cadre de la BAN).
>
> Donat
>
>
>
>>
>> -- Message transféré --
>> From: "Jérôme Amagat" <jerome.ama...@gmail.com>
>> To: "Discussions sur OSM en français" <talk-fr@openstreetmap.org>
>> Cc:
>> Date: Tue, 29 Dec 2015 20:56:15 +0100
>> Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
>> pour la liste des communes nouvelles la page wikipedia :
>>
>> https://fr.wikipedia.org/wiki/Projet_de_communes_fran%C3%A7aises_nouvelles_en_2016
>> basée sur les arrêtés préfectoraux, me semble bien mieux et plus à jour
>> le JO vu qu'il faut attendre que ces même arrêté soit publié au JO
>>
>>
> ___
> 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] Communes nouvelles - fusion de communes

pour la liste des communes nouvelles la page wikipedia :
https://fr.wikipedia.org/wiki/Projet_de_communes_fran%C3%A7aises_nouvelles_en_2016
basée sur les arrêtés préfectoraux, me semble bien mieux et plus à jour le
JO vu qu'il faut attendre que ces même arrêté soit publié au JO

Je suis tombé sur un cas spécial, Chalmazel-Jeansagnière, dans la loire,
les 2 communes n'appartiennent pas à la même communauté de communes.
l’arrêté pref (http://www.loire.gouv.fr/IMG/pdf/RAA_du_29_octobre_2015.pdf)
dit qu'ils ont un mois pour se décider mais ça a l'air d’être fait d’après
le site  d'une comcom (
http://www.loireforez.fr/site/haut/bloc_tetiere_haut/accueil/zoom_et_actualites/actualites/chalmazel_jeansagniere_l_union_fait_la_force
)
j'ai pas touché au 2 comcom
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

J'ai complété mon CSV à partir ce la page wikipédia:
https://github.com/cquest/fusion-communes-2016/blob/master/fusion.csv

Il y a 274 fusions dans le CSV... de quoi faire tourner le script :)

Le 29 décembre 2015 à 20:56, Jérôme Amagat  a
écrit :

> pour la liste des communes nouvelles la page wikipedia :
>
> https://fr.wikipedia.org/wiki/Projet_de_communes_fran%C3%A7aises_nouvelles_en_2016
> basée sur les arrêtés préfectoraux, me semble bien mieux et plus à jour le
> JO vu qu'il faut attendre que ces même arrêté soit publié au JO
>
> Je suis tombé sur un cas spécial, Chalmazel-Jeansagnière, dans la loire,
> les 2 communes n'appartiennent pas à la même communauté de communes.
> l’arrêté pref (http://www.loire.gouv.fr/IMG/pdf/RAA_du_29_octobre_2015.pdf)
> dit qu'ils ont un mois pour se décider mais ça a l'air d’être fait d’après
> le site  d'une comcom (
> http://www.loireforez.fr/site/haut/bloc_tetiere_haut/accueil/zoom_et_actualites/actualites/chalmazel_jeansagniere_l_union_fait_la_force
> )
> j'ai pas touché au 2 comcom
>
> ___
> 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] Communes nouvelles - fusion de communes place !)


Je descends du camion ;-).
Pour indiquer l'"endroit" ou placer le nom d'une commune nouvelle, c'est 
le rôle label dans la relation commune nouvelle qui peut le faire.

On crée un nœud assez au centre, loin de points névralgiques.
On tâtonne un peu, et hop.

Merci à Jérôme : sa requête sur les régions m'a fait retrouver cela 
(c'est utilisé pour l'Île-de-France dont le texte s'affiche normalement 
au milieu de nulle part et non à Paris).
Même principe pour les communes fusionnées dont le nouveau nom n'est pas 
un des anciens noms.


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Bonjour,

Le 30/12/2015 02:14, Jérôme Amagat a écrit :

sur la page récapitulant les communes nouvelles ça pourrait être bien de
mettre tous les tag a mettre, changer ou enlevé sur la nouvelle commune
et les anciennes pour que tous le monde soit sur la même longueur d'onde.
J'ai vu que christian parlait des ref:INSEE je comprenais pas pourquoi
et je viens de voir que les communes qui ont un an ont repris le
ref:insee de la commune chef lieu et c'est aussi ce qui est indiquer là :
http://www.collectivites-locales.gouv.fr/faq-sur-loi-ndeg-2015-292-16-mars-2015-relative-a-lamelioration-regime-commune-nouvelle-pour-des#insee

relation commune nouvelle :
type=boundary
boundary=administrative
admin_level=8
name=*
start_date=2016-01-01

? source=le JO ou l’arrêté préfectoral
? addr:postcode= le code postal des communes s'il est le même dans
toutes les anciennes communes
wikipedia

relation commune délégués :
type=boundary
boundary=administrative
name=*
? admin_level=9
? source=le JO ou l’arrêté préfectoral
? admin_type:FR=commune déléguée
? start_date=2016-01-01 ou end_date ou autre chose

il faut bien sur tomber d'accord sur
quel admin_level?
tag spécifique oui(lequel?) ou non?
le truc c'est que le tag spécial commune déléguée peut être facilement
supprimé plus tard si on décide qu'il est inutile mais plus difficile a
ajouté quant tous sera fini.

Merci pour la synthèse (on avance :) )
Pour les raisons discutées depuis 2 jours je suis favorable à ce que tu
proposes, y compris admin_level=9, _avec_ le tag admin_type. Il faudra
propager ce tag sur les arrondissements de PLM.

Un point qui reste à fixer est le devenir du tag ref:INSEE des communes
déléguées :

- est-ce qu'elles gardent le tag ref:INSEE sur leur relation admin ?
ou
- est-ce qu'on change plutôt ce tag en old_ref:INSEE ? (Rigolez-pas dans
le fond, on en a déjà !
http://taginfo.openstreetmap.org/keys/old_ref%3AINSEE :) )

vincent

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Franchement, le admin_level=9 me gène pour la confusion qu'il va créer pour
les outils l'utilisant déjà actuellement (et il y en a vu que ces
découpages étaient exhaustifs).

Je ne me battrais pas là dessus, mais ne vous étonnez pas si il y a des
trucs qui merdent à court terme ici ou là.

Sur le process, je propose de faire ça en deux temps et via le script que
j'ai écrit:
1) création des nouvelles relations avec admin_level:proposed=8 /
start_date=2016-01-01
ça laisse un peu de temps pour vérifier...
2) bascule en admin_level=8 et modif des anciennes communes

L'important étant d'avoir le CSV global bien propre. Le script permet
d'être homogène et ne mobilise plus de temps humain qu'on peut remettre à
profit sur le contrôle du résultat.

L'objectif que je vois serait d'annoncer si possible le 1er janvier, que
tout est "déjà" à jour dans OSM et sortir un nouveau fichier du découpage
communal pour le diffuser sur data.gouv.fr.
On pourra communiquer là dessus pour enfoncer le clou sur le merdier qui
consiste à publier au dernier moment au JORF ces infos, à ne pas avoir de
COG à jour, etc...


Le 30 décembre 2015 à 02:14, Jérôme Amagat <jerome.ama...@gmail.com> a
écrit :

> sur la page récapitulant les communes nouvelles ça pourrait être bien de
> mettre tous les tag a mettre, changer ou enlevé sur la nouvelle commune et
> les anciennes pour que tous le monde soit sur la même longueur d'onde.
> J'ai vu que christian parlait des ref:INSEE je comprenais pas pourquoi et
> je viens de voir que les communes qui ont un an ont repris le ref:insee de
> la commune chef lieu et c'est aussi ce qui est indiquer là :
>
> http://www.collectivites-locales.gouv.fr/faq-sur-loi-ndeg-2015-292-16-mars-2015-relative-a-lamelioration-regime-commune-nouvelle-pour-des#insee
>
> relation commune nouvelle :
> type=boundary
> boundary=administrative
> admin_level=8
> name=*
> start_date=2016-01-01
>
> ? source=le JO ou l’arrêté préfectoral
> ? addr:postcode= le code postal des communes s'il est le même dans toutes
> les anciennes communes
> wikipedia
>
> relation commune délégués :
> type=boundary
> boundary=administrative
> name=*
> ? admin_level=9
> ? source=le JO ou l’arrêté préfectoral
> ? admin_type:FR=commune déléguée
> ? start_date=2016-01-01 ou end_date ou autre chose
>
> il faut bien sur tomber d'accord sur
> quel admin_level?
> tag spécifique oui(lequel?) ou non?
> le truc c'est que le tag spécial commune déléguée peut être facilement
> supprimé plus tard si on décide qu'il est inutile mais plus difficile a
> ajouté quant tous sera fini.
>
>
> Le 30 décembre 2015 à 00:46, Donat ROBAUX <dona...@gmail.com> a écrit :
>
>> Merci Jérome pour le lien. J'avoue ne même pas avoir pensé à consulter
>> WP... Ils sont vachement plus à jour que nous. Donc nous on est carrément à
>> la ramasse. Ils ont fouillé dans tous les RAA (pas eu le temps de passer
>> partout). Faut dire qu'ils ne sont pas très pratique à consulter.
>> Va falloir aller faire du pompage chez WP ;)
>>
>> Pour info et comme je disais dans un précédent mail: sur Légifrance, les
>> arrêtés étant publiés par date d'arrêté et non par publication au JO, j'ai
>> dû remonter jusqu'à la page 7. Des arrêtés datent de juillet et sont
>> publiés seulement le 29/12/2015. Tu m'étonnes que l'INSEE ne peut pas être
>> à jour... (re clin d’œil à Christian dans le cadre de la BAN).
>>
>> Donat
>>
>>
>>
>>>
>>> -- Message transféré --
>>> From: "Jérôme Amagat" <jerome.ama...@gmail.com>
>>> To: "Discussions sur OSM en français" <talk-fr@openstreetmap.org>
>>> Cc:
>>> Date: Tue, 29 Dec 2015 20:56:15 +0100
>>> Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
>>> pour la liste des communes nouvelles la page wikipedia :
>>>
>>> https://fr.wikipedia.org/wiki/Projet_de_communes_fran%C3%A7aises_nouvelles_en_2016
>>> basée sur les arrêtés préfectoraux, me semble bien mieux et plus à jour
>>> le JO vu qu'il faut attendre que ces même arrêté soit publié au JO
>>>
>>>
>> ___
>> 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] Communes nouvelles - fusion de communes


Plus complètement :
8=boundary of communes like Paris, Montpellier, Perpignan. Use name=* to 
indicate the name of the commune, and ref:INSEE=* to indicate the unique 
identifier given by INSEE (COG).

9=boundary of "Arrondissement municipal" (in Paris, Lyon, Marseille only)
10=Used for the local democracy : quartier

Et en français :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Arrondissements_municipaux_ou_communes_associ.C3.A9es
Arrondissements municipaux *ou communes associées*

 * admin_level =9
   

Ça me semble logique et cohérent : c'est le niveau en dessous.
Si vous voulez ajouter un tag pour préciser le lien dans la relation 
admin=8 (commune associée, arrondissement de commune), pourquoi pas.
Mais je ne vois pas l'intérêt de mettre des niveaux fictifs (il n'y a 
pas de communes associées à l'intérieur de PLM sauf erreur, de même il 
n'y a pas d'arrondissement de commune dans les commune fusionnées).


Jean-Yvon

Le 29/12/2015 07:46, Philippe Verdy - verd...@wanadoo.fr a écrit :
Non les quartiers sont en 10, les sous-quartiers en 11 (on en trouve 
dans les grandes villes uniquement, dont Paris, Nantes, Rennes, etc)


Le 28 décembre 2015 à 22:33, David Crochet > a écrit :


Bonjour

Le 28/12/2015 19:43, Vincent de Château-Thierry a écrit :

en admin_level=10 empêche la définition de quartiers


Les quartiers, c'est pas du 11 ?

Cordialement

-- 
David Crochet



___
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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Bonjour,

> De: "osm sanspourriel" 
> * admin_level = 9
> 
> Ça me semble logique et cohérent : c'est le niveau en dessous.
> Si vous voulez ajouter un tag pour préciser le lien dans la relation
> admin=8 (commune associée, arrondissement de commune), pourquoi
> pas.

Tu veux dire dans la relation admin=9 ? Sinon je ne comprends pas ta 
proposition.

> Mais je ne vois pas l'intérêt de mettre des niveaux fictifs (il n'y a
> pas de communes associées à l'intérieur de PLM sauf erreur, de même
> il n'y a pas d'arrondissement de commune dans les commune
> fusionnées).

Idem, je ne comprends pas de quels niveaux fictifs tu parles.

vincent

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Tyndare, pourquoi dis-tu qu'on ne devrait pas mettre de place avec le 
nom associé (sachant que tu n'es pas d'accord avec) ?

Comme toi, ça me semble tellement évident.
Il y a des cas simples (Fusion Audierne-Esquibien donne Audierne avec 
comme chef-lieu Audierne).


Pour les panneaux, il y bien aussi des endroits où il est indiqué des 
noms de "quartier" avec en dessous et plus petit le nom de la commune.
Ça ne veut pas dire qu'il y a un "admin_level" spécifique, simplement 
que cette zone urbaine est (ou pas) contigüe avec une autre.
Par exemple "Les Cinq Chemins, commune de Guidel" (et le panneau de fin 
d'agglomération fait suite à un panneau d'entrée dans Guidel).

Au niveau d'OSM c'est un simple nœud car il n'y a pas de limite nette.

Un "Chanos-Curson" entre Chanos et Curson voir un à la place de Chanos 
ça me semble bon.

Et c'est ce qui figure sur OSM http://www.openstreetmap.org/relation/77510
Dernière modification (pas sur le sujet) un certain Verdy_p.

Dans le genre petits détails qui tuent : Audierne et Esquibien faisaient 
partie du canton de Douarnenez.

J'ai ajouté la nouvelle relation Audierne à la relation canton Douarnenez.
Afin d'éviter les duplicatas, j'ai changé le canton "Douarnenez 
(4028420)" :
Relation Audierne (280462) 
 avec le rôle 
subarea:-2016-01-01
Relation Esquibien (278707) 
 avec le rôle 
subarea:-2016-01-01
Relation Audierne (5806724) 
 avec le rôle subarea
(JOSM râle mais avec subarea:-2016-01-01 je ne casse rien et c'est 
compréhensible - à supprimer au le 1er janvier ?)


Sauf que je vois :
que la relation Finistère - cantons (mars 2015) (4022330) 
 s'appelle "mars 2015"

Est-ce que la relation canton Douarnenez n'est pas à laisser telle quelle ?

Sinon grâce à cette fusion j'ai vu que des traits de côte étaient encore 
incorrects. JOSM le dit mais ne propose pas la solution (les chemin 
doivent être en sens trigonométrique autour d'une terre). Corrigé 
rapidement quand j'ai compris ce que signifiait le message sur la 
discontinuité du littoral).



 Finistère

Arrêté du 16 octobre 2015 portant création de la commune nouvelle 
d'Audierne 



 * Relation 
   Audierne (280462) 
   (XML ,
   Potlatch2
   ,
   iD ,
   JOSM
   
,
   history
   ,
   analyze ,
   manage , gpx
   ) (chef-lieu et
   commune déléguée)
 * Relation 
   Esquibien (278707) 
   (XML ,
   Potlatch2
   ,
   iD ,
   JOSM
   
,
   history
   ,
   analyze ,
   manage , gpx
   ) (commune déléguée)

Fait : Relation  
Audierne (5806724)  (XML 
, Potlatch2 
, 
iD , JOSM 
, 
history 
, 
analyze , 
manage , gpx 
)




Jean-Yvon

Le 29/12/2015 08:02, Philippe Verdy - verd...@wanadoo.fr a écrit :



Le 29 décembre 2015 à 00:32, Tyndare > a écrit :



Je relance le sujet sur le node place de la commune nouvelle.
Ça m'embête qu'il n'y en ai pas.

A partir du moment ou la commune existe et que l'emplacement de
son chef lieu est  connu je ne voie pas pourquoi on

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-29 Par sujet Stéphane Péneau


Le 29/12/2015 11:49, Tyndare a écrit :
Pour résumer si je n'étais pas claire: Contrairement a ce qui semble 
être l'avis majoritaire et ce qui a été fait jusqu'à maintenant pour 
les communes nouvelles j'aurais voulu rajouter un tag place avec le 
nom des communes nouvelles créés.


Il y a de nombreux cas où ajouter un tag place n'aura pas vraiment de 
sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce "place" ?

http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691

Au niveau du chef-lieu ? Ça ne pas de sens
Au centre de la commune nouvelle ? Pas de sens non plus.

Dans la même zone, il y a eu en 2000 une fusion de communes :
Montigné-sur-Moine et Montfaucon-sur-Moine 
 ont formé la 
commune de Montfaucon-Montigné 

Quelqu'un a ajouté un tag place pour Montfaucon-Montigné, avec le rôle 
admin_center, mais il ne correspond à rien dans la réalité, enfin si... 
à une école.


Si on ne le fait pas je constate une incohérence avec toutes les 
communes (non nouvelles) dans OSM qui ont toutes leur tag place avec 
la population associée (sans avoir toujours de cohérence avec les 
panneaux sur le terrain et la distribution de la population dans les 
différents hameaux/villages qui composent les communes)



Je suis plutôt d'accord sur le fait que la population devrait être sur 
la relation. J'imagine qu'il y a des arguments pour la laisser sur le 
node admin_center, et qu'ils ont déjà été discutés (facilité de 
réutilisation ? On n'avait pas encore toutes les limites communales ?), 
mais ce n'est pas parce que ça n'a pas de sens actuellement qu'il faut 
continuer dans cette direction.




Je constate aussi un défaut de visibilité sur les rendus des commune 
nouvelles sans tag place, c'est embêtant car l'adressage se fait 
d'abord par le nom des communes nouvelles.


Il y avait la possibilité d'un node avec le rôle label dans la relation, 
mais je ne sais pas si c'est vraiment utilisé, et je n'en ai pas 
retrouvé beaucoup de traces sur le wiki.


Stf

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

Re: [OSM-talk-fr] Communes nouvelles - script de fusion...

Mon petit script de fusion commence à prendre forme et être bien efficace :)

J'ai ajouté la télécommande de JOSM, du coup toutes les manips sont
faites localement, visualisables et contrôlables dans JOSM avant envoi
vers OSM.

Après récupération des données via overpass, il passe en admin_level=10
les frontières internes et les relations des communes fusionnées, puis
crée la relation de la nouvelle en admin_level=8 avec les tags minimums.

Chaque fusion est créée dans une couche séparée dans JOSM à partir du
fichier fusion.csv

Je dois encore ajouter la prise en compte des communes fusionnées déjà
présentes pour ne pas créer de doublons...

Vous pouvez déjà tester, j'ai même mis les 3 lignes pour l'install
(besoin de python3 et testé uniquement sous Linux).

Le plus efficace est de compléter le fichier CSV pour permettre un
traitement rapide et automatique. Surtout, le traitement peut être
adapté pour contrôler qu'on a un résultat homogène.

Les pull-requests sont les bienvenues !

https://github.com/cquest/fusion-communes-2016

-- 
Christian Quest - OpenStreetMap France



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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

on ne tag pas pour le rendu! :)
les tag place c'est pour les villes villages hameaux s'ils ne portent pas
le nom de la commune alors il ne faut pas leur donner le nom de la commune.
c'est vrai que la plupart des communes porte le nom de la ville ou village
le plus important de leur territoire mais pas toujours (surtout lorsque la
commune est issu d'une fusion).
pour la population, je suis d'accord il y a un problème, mais le problème
c'est que le tag devrait être toujours sur la relation représentant la
commune et pas sur le tag place.

j'ai modifié plusieurs communes dans ce cas, sur les tag place j'ai mis le
vrai nom des villages et j'ai  déplacé la population sur la relation et
l'admin_centre de la relation c'est le "place=" où il y a la mairie.

Le 29 décembre 2015 à 11:49, Tyndare  a écrit :

> Pour résumer si je n'étais pas claire: Contrairement a ce qui semble être
> l'avis majoritaire et ce qui a été fait jusqu'à maintenant pour les
> communes nouvelles j'aurais voulu rajouter un tag place avec le nom des
> communes nouvelles créés.
>
> Si on ne le fait pas je constate une incohérence avec toutes les communes
> (non nouvelles) dans OSM qui ont toutes leur tag place avec la population
> associée (sans avoir toujours de cohérence avec les panneaux sur le terrain
> et la distribution de la population dans les différents hameaux/villages
> qui composent les communes)
>
> Je constate aussi un défaut de visibilité sur les rendus des commune
> nouvelles sans tag place, c'est embêtant car l'adressage se fait d'abord
> par le nom des communes nouvelles.
>
>
> Le 29 décembre 2015 10:28:30 GMT+01:00, osm.sanspourr...@spamgourmet.com
> a écrit :
>>
>> Tyndare, pourquoi dis-tu qu'on ne devrait pas mettre de place avec le nom
>> associé (sachant que tu n'es pas d'accord avec) ?
>> Comme toi, ça me semble tellement évident.
>> Il y a des cas simples (Fusion Audierne-Esquibien donne Audierne avec
>> comme chef-lieu Audierne).
>>
>> Pour les panneaux, il y bien aussi des endroits où il est indiqué des
>> noms de "quartier" avec en dessous et plus petit le nom de la commune.
>> Ça ne veut pas dire qu'il y a un "admin_level" spécifique, simplement que
>> cette zone urbaine est (ou pas) contigüe avec une autre.
>> Par exemple "Les Cinq Chemins, commune de Guidel" (et le panneau de fin
>> d'agglomération fait suite à un panneau d'entrée dans Guidel).
>> Au niveau d'OSM c'est un simple nœud car il n'y a pas de limite nette.
>>
>> Un "Chanos-Curson" entre Chanos et Curson voir un à la place de Chanos ça
>> me semble bon.
>> Et c'est ce qui figure sur OSM
>> 
>> http://www.openstreetmap.org/relation/77510
>> Dernière modification (pas sur le sujet) un certain Verdy_p.
>>
>> Dans le genre petits détails qui tuent : Audierne et Esquibien faisaient
>> partie du canton de Douarnenez.
>> J'ai ajouté la nouvelle relation Audierne à la relation canton Douarnenez.
>> Afin d'éviter les duplicatas, j'ai changé le canton "Douarnenez
>> (4028420)" :
>> Relation Audierne (280462)
>>  avec le rôle
>> subarea:-2016-01-01
>> Relation Esquibien (278707)
>>  avec le rôle
>> subarea:-2016-01-01
>> Relation Audierne (5806724)
>>  avec le rôle subarea
>> (JOSM râle mais avec subarea:-2016-01-01 je ne casse rien et c'est
>> compréhensible - à supprimer au le 1er janvier ?)
>>
>> Sauf que je vois :
>> que la relation Finistère - cantons (mars 2015) (4022330)
>>  s'appelle "mars 2015"
>> Est-ce que la relation canton Douarnenez n'est pas à laisser telle quelle
>> ?
>>
>> Sinon grâce à cette fusion j'ai vu que des traits de côte étaient encore
>> incorrects. JOSM le dit mais ne propose pas la solution (les chemin doivent
>> être en sens trigonométrique autour d'une terre). Corrigé rapidement quand
>> j'ai compris ce que signifiait le message sur la discontinuité du littoral).
>> Finistère
>>
>> Arrêté du 16 octobre 2015 portant création de la commune nouvelle
>> d'Audierne
>> 
>>
>>- [image: Relation]
>> Audierne
>>(280462)  (XML
>>, Potlatch2
>>
>> ,
>>iD , JOSM
>>
>> ,
>>history
>>,
>>analyze ,
>>manage , gpx
>>

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-29 Par sujet Tyndare



Le 29 décembre 2015 12:46:21 GMT+01:00, "Stéphane Péneau" 
 a écrit :
>Le 29/12/2015 11:49, Tyndare a écrit :
>> Pour résumer si je n'étais pas claire: Contrairement a ce qui semble 
>> être l'avis majoritaire et ce qui a été fait jusqu'à maintenant pour 
>> les communes nouvelles j'aurais voulu rajouter un tag place avec le 
>> nom des communes nouvelles créés.
>
>Il y a de nombreux cas où ajouter un tag place n'aura pas vraiment de 
>sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce
>"place" ?
>http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691
>
>Au niveau du chef-lieu ? Ça ne pas de sens

Pour moi si ça aurait tout son sens de le mettre au niveau du chef-lieu, où se 
trouve la mairie de la commune.
Mais je veux bien admettre que je soit influencé par le rendu, zapper une 
commune de plus de 20'000 habitants et n'afficher que le nom des quartiers 
(admin level = 10) ce n'est pas super pratique comme carte ;-)

Quel rendu existant l'affiche correctement ?


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

Re: [OSM-talk-fr] Communes nouvelles - script de fusion...


> De: "Christian Quest" 
> 
> Après récupération des données via overpass, il passe en
> admin_level=10 les frontières internes et les relations des communes 
> fusionnées,
> puis crée la relation de la nouvelle en admin_level=8 avec les tags
> minimums.

On parlait ici même hier soir d'un classement en admin_level=9 (et non 10) avec 
un tag admin_type=* pour distinguer les communes déléguées des arrondissements 
municipaux. Il faudrait qu'on se mette d'accord là-dessus avant que les outils 
émergent...

vincent

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-29 Par sujet Tyndare

Pour résumer si je n'étais pas claire: Contrairement a ce qui semble être 
l'avis majoritaire et ce qui a été fait jusqu'à maintenant pour les communes 
nouvelles j'aurais voulu rajouter un tag place avec le nom des communes 
nouvelles créés.

Si on ne le fait pas je constate une incohérence avec toutes les communes (non 
nouvelles) dans OSM qui ont toutes leur tag place avec la population associée 
(sans avoir toujours de cohérence avec les panneaux sur le terrain et la 
distribution de la population dans les différents hameaux/villages qui 
composent les communes)

Je constate aussi un défaut de visibilité sur les rendus des commune nouvelles 
sans tag place, c'est embêtant car l'adressage se fait d'abord par le nom des 
communes nouvelles.

Le 29 décembre 2015 10:28:30 GMT+01:00, osm.sanspourr...@spamgourmet.com a 
écrit :
>Tyndare, pourquoi dis-tu qu'on ne devrait pas mettre de place avec le 
>nom associé (sachant que tu n'es pas d'accord avec) ?
>Comme toi, ça me semble tellement évident.
>Il y a des cas simples (Fusion Audierne-Esquibien donne Audierne avec 
>comme chef-lieu Audierne).
>
>Pour les panneaux, il y bien aussi des endroits où il est indiqué des 
>noms de "quartier" avec en dessous et plus petit le nom de la commune.
>Ça ne veut pas dire qu'il y a un "admin_level" spécifique, simplement 
>que cette zone urbaine est (ou pas) contigüe avec une autre.
>Par exemple "Les Cinq Chemins, commune de Guidel" (et le panneau de fin
>
>d'agglomération fait suite à un panneau d'entrée dans Guidel).
>Au niveau d'OSM c'est un simple nœud car il n'y a pas de limite nette.
>
>Un "Chanos-Curson" entre Chanos et Curson voir un à la place de Chanos 
>ça me semble bon.
>Et c'est ce qui figure sur OSM
>http://www.openstreetmap.org/relation/77510
>Dernière modification (pas sur le sujet) un certain Verdy_p.
>
>Dans le genre petits détails qui tuent : Audierne et Esquibien
>faisaient 
>partie du canton de Douarnenez.
>J'ai ajouté la nouvelle relation Audierne à la relation canton
>Douarnenez.
>Afin d'éviter les duplicatas, j'ai changé le canton "Douarnenez 
>(4028420)" :
>Relation Audierne (280462) 
> avec le rôle 
>subarea:-2016-01-01
>Relation Esquibien (278707) 
> avec le rôle 
>subarea:-2016-01-01
>Relation Audierne (5806724) 
> avec le rôle subarea
>(JOSM râle mais avec subarea:-2016-01-01 je ne casse rien et c'est 
>compréhensible - à supprimer au le 1er janvier ?)
>
>Sauf que je vois :
>que la relation Finistère - cantons (mars 2015) (4022330) 
> s'appelle "mars 2015"
>Est-ce que la relation canton Douarnenez n'est pas à laisser telle
>quelle ?
>
>Sinon grâce à cette fusion j'ai vu que des traits de côte étaient
>encore 
>incorrects. JOSM le dit mais ne propose pas la solution (les chemin 
>doivent être en sens trigonométrique autour d'une terre). Corrigé 
>rapidement quand j'ai compris ce que signifiait le message sur la 
>discontinuité du littoral).
>
>
>  Finistère
>
>Arrêté du 16 octobre 2015 portant création de la commune nouvelle 
>d'Audierne 
>
>
>  * Relation 
>Audierne (280462) 
>(XML ,
>Potlatch2
>,
>iD ,
>JOSM
>,
>history
>,
>analyze ,
>manage , gpx
>) (chef-lieu et
>commune déléguée)
>  * Relation 
>Esquibien (278707) 
>(XML ,
>Potlatch2
>,
>iD ,
>JOSM
>,
>history
>,
>analyze ,
>manage , gpx
>  ) (commune déléguée)
>
>Fait : Relation 
>
>Audierne (5806724) 
>(XML

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Le 29 décembre 2015 à 14:15, Tyndare  a écrit :

>
>
> Le 29 décembre 2015 12:46:21 GMT+01:00, "Stéphane Péneau" <
> stephane.pen...@wanadoo.fr> a écrit :
> >Le 29/12/2015 11:49, Tyndare a écrit :
> >> Pour résumer si je n'étais pas claire: Contrairement a ce qui semble
> >> être l'avis majoritaire et ce qui a été fait jusqu'à maintenant pour
> >> les communes nouvelles j'aurais voulu rajouter un tag place avec le
> >> nom des communes nouvelles créés.
> >
> >Il y a de nombreux cas où ajouter un tag place n'aura pas vraiment de
> >sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce
> >"place" ?
> >http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691
> >
> >Au niveau du chef-lieu ? Ça ne pas de sens
>
> Pour moi si ça aurait tout son sens de le mettre au niveau du chef-lieu,
> où se trouve la mairie de la commune.
>

donc tu mettrai au même endroit le nom de la commune et le nom de la ville
mais s'ils sont différents? le fait que c'est le chef lieu c'est inscrit
dans la relation avec le rôle admin_centre.


> Mais je veux bien admettre que je soit influencé par le rendu, zapper une
> commune de plus de 20'000 habitants et n'afficher que le nom des quartiers
> (admin level = 10) ce n'est pas super pratique comme carte ;-)
>
> le nom de la commune de 2 habitants n’apparaît peut être pas sur le
rendu mais la ville de 15000 habitant au milieu de la commune apparaît bien
et c'est ce qui est important pour la plupart des gens et il me semble pas
que les admin_level=10 sont plus indiqué que les 8, si il y a un node
place=suburb avec son nom ou un truc du genre il apparaîtra sinon non.

Pour les communes qui vont être créer ou celle déjà créé par fusion le plus
important c'est le nom des ville et village, le nom de la commune apparaît
beaucoup moins et est beaucoup moins utilisé. c'est comme les communauté de
commune, à part la tienne est t il important et utile dans la vie de tous
les jours de connaître le nom et la composition des autres communauté de
communes.





> Quel rendu existant l'affiche correctement ?
>
>
> ___
> 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] Communes nouvelles - fusion de communes

Non, les cantons ne CHANGENT PAS même en cas de fusion de commune.
Les communes découpées par les cantons sont légion en France, ils n'ont
aucune obligation à inclure des communes entières (d'autant plus que les
communes déléguées sont encore des communes).
Rien ne justifie de modifier les cantons qui sont formés sur des comptes de
population.
Merci d'annuler ta modif des cantons, il n'y a aucun décret ou arrêté qui
le justifie.

Le 29 décembre 2015 à 10:28,  a écrit :

> Tyndare, pourquoi dis-tu qu'on ne devrait pas mettre de place avec le nom
> associé (sachant que tu n'es pas d'accord avec) ?
> Comme toi, ça me semble tellement évident.
> Il y a des cas simples (Fusion Audierne-Esquibien donne Audierne avec
> comme chef-lieu Audierne).
>
> Pour les panneaux, il y bien aussi des endroits où il est indiqué des noms
> de "quartier" avec en dessous et plus petit le nom de la commune.
> Ça ne veut pas dire qu'il y a un "admin_level" spécifique, simplement que
> cette zone urbaine est (ou pas) contigüe avec une autre.
> Par exemple "Les Cinq Chemins, commune de Guidel" (et le panneau de fin
> d'agglomération fait suite à un panneau d'entrée dans Guidel).
> Au niveau d'OSM c'est un simple nœud car il n'y a pas de limite nette.
>
> Un "Chanos-Curson" entre Chanos et Curson voir un à la place de Chanos ça
> me semble bon.
> Et c'est ce qui figure sur OSM
> 
> http://www.openstreetmap.org/relation/77510
> Dernière modification (pas sur le sujet) un certain Verdy_p.
>
> Dans le genre petits détails qui tuent : Audierne et Esquibien faisaient
> partie du canton de Douarnenez.
> J'ai ajouté la nouvelle relation Audierne à la relation canton Douarnenez.
> Afin d'éviter les duplicatas, j'ai changé le canton "Douarnenez (4028420)"
> :
> Relation Audierne (280462) 
> avec le rôle subarea:-2016-01-01
> Relation Esquibien (278707)
>  avec le rôle
> subarea:-2016-01-01
> Relation Audierne (5806724)
>  avec le rôle subarea
> (JOSM râle mais avec subarea:-2016-01-01 je ne casse rien et c'est
> compréhensible - à supprimer au le 1er janvier ?)
>
> Sauf que je vois :
> que la relation Finistère - cantons (mars 2015) (4022330)
>  s'appelle "mars 2015"
> Est-ce que la relation canton Douarnenez n'est pas à laisser telle quelle ?
>
> Sinon grâce à cette fusion j'ai vu que des traits de côte étaient encore
> incorrects. JOSM le dit mais ne propose pas la solution (les chemin doivent
> être en sens trigonométrique autour d'une terre). Corrigé rapidement quand
> j'ai compris ce que signifiait le message sur la discontinuité du littoral).
> Finistère
>
> Arrêté du 16 octobre 2015 portant création de la commune nouvelle
> d'Audierne
> 
>
>- [image: Relation]
> Audierne
>(280462)  (XML
>, Potlatch2
>
> ,
>iD , JOSM
>
> ,
>history
>,
>analyze ,
>manage , gpx
>) (chef-lieu et
>commune déléguée)
>- [image: Relation]
> Esquibien
>(278707)  (XML
>, Potlatch2
>
> ,
>iD , JOSM
>
> ,
>history
>,
>analyze ,
>manage , gpx
>) (commune déléguée)
>
> Fait : [image: Relation]
>  Audierne (5806724)
>  (XML
> , Potlatch2
> ,
> iD , JOSM
>

Re: [OSM-talk-fr] Communes nouvelles - script de fusion...

Je crains (très) fort que admin_level=9 casse quelques scripts existants
qui s'appuient là dessus pour les arrondissement municipaux
(exhaustifs). Ces scripts n'iront pas vérifier un nouveau tag sans qu'on
change leur code...

admin_level=10 me semble moins poser de problème car c'est peu utilisé
(car pas exhaustif du tout) et c'est ce qui a été utilisé jusque là pour
les précédentes fusions.
Lui adjoindre un admin_type me semble une bonne idée pour préciser de
quoi il s'agit.

On 29/12/2015 15:48, Vincent de Château-Thierry wrote:
>> De: "Christian Quest" 
>>
>> Après récupération des données via overpass, il passe en
>> admin_level=10 les frontières internes et les relations des communes 
>> fusionnées,
>> puis crée la relation de la nouvelle en admin_level=8 avec les tags
>> minimums.
> On parlait ici même hier soir d'un classement en admin_level=9 (et non 10) 
> avec un tag admin_type=* pour distinguer les communes déléguées des 
> arrondissements municipaux. Il faudrait qu'on se mette d'accord là-dessus 
> avant que les outils émergent...
>
> vincent
>
> ___
> 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] Communes nouvelles - fusion de communes

2015-12-29 Par sujet Donat ROBAUX

Bonjour à tous,

Je viens de voir que de nouvelles communes ont été publiées au JO.
http://www.legifrance.gouv.fr/affichSarde.do?reprise=true=2070031329=SARDOBJT07104406=1

Et par là même occasion, je vois que le JO les classe par date d'arrêté
préfectoral et non par date de publication au JO.  Ce qui veut dire que
les nouvelles communes publiées sont mélangées avec les autres que j'ai
déjà enregistrées sur le wiki.
Et je ne suis pas contre un peu d'aide ;) parce que y en a vraiment
beaucoup.

Donat, forçat de la réforme territoriale... ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-28 Par sujet David Crochet


Bonjour

Le 28/12/2015 19:43, Vincent de Château-Thierry a écrit :

en admin_level=10 empêche la définition de quartiers


Les quartiers, c'est pas du 11 ?

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-28 Par sujet Christian Quest

J'ai commencé à écrire un script pour simplifier la tâche de création de
ces nouvelles communes...

Il s'appuie sur un fichier CSV contenant:
- N° du département,
- nom de la nouvelle commune
- noms des communes la composant
- nom de la commune chef-lieu
- population totale

J'ai aussi une colonne avec la date de l'arrêté, pas utilisé pour l'instant.

Exemple:
https://github.com/cquest/fusion-communes-2016/blob/master/fusion.csv

Vous pouvez le compléter directement, ça permettra d'automatiser soit la
mise à jour en mode 'bot' (pas très chaud pour ça), soit le contrôle final
par un bot.

Demain je m'attaque à télécommander JOSM pour faire le plus de manip
automatiquement.

Pour l'instant le script récupère:
- les id des ways 'outer' de la nouvelle commune
- les id des ways "internes" qui vont devoir passer de admin_level=8 à
autre chose
- l'id du node du chef-lieu
- les différents codes postaux rencontrés
- le total de la population à utiliser si il n'est pas fournit dans le CSV

C'est ici:
https://github.com/cquest/fusion-communes-2016/blob/master/fusion2016.py

Attention,ça peut piquer les yeux... ce n'est que mon 4ème script python ;)


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Encore une fois je ne suis pas d'accord sur l'admin_level 10 qui n'est pas
pour ça. Ce devrait être admin_level 9 pour TOUTES ces communes membres de
communes nouvelles. Le  niveau 10 est uniquement pour les subdivisions
INFRA-communales, mais les communes membres de comune nouvelles restent des
communes avec leur propre quartiers.
>
> C'est récurernt mais certains bloquent encore sur le fait que les niveau 9
> est aussi utilisé à Paris/Lyon/Marseille pour leurs arrondissements
> communaux mais il n'y a aucune commune membre dedans et ce ne sont pas des
> communes nouvelles. Bref aucuine confusion possible.


J'insiste, c'est le niveau 9, pas le niveau 10 qui restent pour les
quartiers et les communes membres de communes nouvelles ne sont pas de
simples quartiers, et conservent même leur propre découpage administratif
en quartiers.

Le 28 décembre 2015 à 18:49, Stéphane Péneau  a
écrit :

> Le 28/12/2015 17:57, Christian Quest a écrit :
>
>> Les étapes que je vois à réaliser:
>> - création de la nouvelle relation type=boundary de la nouvelle commune
>>- admin_level=8
>>- start_date=2016-01-01
>>- ref:INSEE = celui du chef lieu
>>- population= celle indiquée dans les arrêtés... ou somme des
>> population des communes fusionnées
>>- membres: outer=way frontière + admin_centre le noeud place=* du chef
>> lieu
>>
>> - déclassement des anciennes communes en admin_level=10
>>- ajouter un tag pour spécifier communes associée ou autre ? (j'avoue
>> n'avoir pas creusé les différents cas)
>>
>> - déclassement en admin_level=10 des frontières entre les communes
>> fusionnées
>>
>> Autre chose ?
>>
>
> Dans la relation :
> name = nom de la commune nouvelle
> boundary=admin
> Tag wikipedia si un article existe
>
> Il y a les cas où la commune nouvelle remplace la communauté de
> commune/aglo/... Il ne faut donc pas créer une relation, mais modifier
> celle de la comcom. Enfin je pense
>
> Pour le ref:INSEE, c'est vraiment celui du chef-lieu qu'il faut utiliser ?
>
> Stf
>
>
> ___
> 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] Communes nouvelles - fusion de communes

2015-12-28 Par sujet Stéphane Péneau


Le 28/12/2015 17:57, Christian Quest a écrit :

Les étapes que je vois à réaliser:
- création de la nouvelle relation type=boundary de la nouvelle commune
   - admin_level=8
   - start_date=2016-01-01
   - ref:INSEE = celui du chef lieu
   - population= celle indiquée dans les arrêtés... ou somme des
population des communes fusionnées
   - membres: outer=way frontière + admin_centre le noeud place=* du chef
lieu

- déclassement des anciennes communes en admin_level=10
   - ajouter un tag pour spécifier communes associée ou autre ? (j'avoue
n'avoir pas creusé les différents cas)

- déclassement en admin_level=10 des frontières entre les communes
fusionnées

Autre chose ?


Dans la relation :
name = nom de la commune nouvelle
boundary=admin
Tag wikipedia si un article existe

Il y a les cas où la commune nouvelle remplace la communauté de 
commune/aglo/... Il ne faut donc pas créer une relation, mais modifier 
celle de la comcom. Enfin je pense


Pour le ref:INSEE, c'est vraiment celui du chef-lieu qu'il faut utiliser ?

Stf

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-28 Par sujet Christian Quest

Vu le volume à traiter d'ici le 1er janvier, j'ai commencé les modifs.
Je vais voir comment automatiser un max le process ce qui permettra
aussi de faire des vérifications automatiques.

J'ai mis à jour le wiki:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Modifications_planifi%C3%A9es#Fusions_au_01.2F01.2F2016


-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-28 Par sujet Christian Quest

Les étapes que je vois à réaliser:
- création de la nouvelle relation type=boundary de la nouvelle commune
  - admin_level=8
  - start_date=2016-01-01
  - ref:INSEE = celui du chef lieu
  - population= celle indiquée dans les arrêtés... ou somme des
population des communes fusionnées
  - membres: outer=way frontière + admin_centre le noeud place=* du chef
lieu

- déclassement des anciennes communes en admin_level=10
  - ajouter un tag pour spécifier communes associée ou autre ? (j'avoue
n'avoir pas creusé les différents cas)

- déclassement en admin_level=10 des frontières entre les communes
fusionnées

Autre chose ?


On 28/12/2015 16:40, Christian Quest wrote:
> Vu le volume à traiter d'ici le 1er janvier, j'ai commencé les modifs.
> Je vais voir comment automatiser un max le process ce qui permettra
> aussi de faire des vérifications automatiques.
>
> J'ai mis à jour le wiki:
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Modifications_planifi%C3%A9es#Fusions_au_01.2F01.2F2016
>
>

-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes



Le 28/12/2015 22:33, David Crochet a écrit :


Le 28/12/2015 19:43, Vincent de Château-Thierry a écrit :

en admin_level=10 empêche la définition de quartiers


Les quartiers, c'est pas du 11 ?


J'en suis resté à ce tableau :
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries

=> 10 : "Used for the local democracy : quartiers"

vincent

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Le 28 décembre 2015 à 19:43, Vincent de Château-Thierry 
a écrit :

> Bonsoir,
>
> Le 28/12/2015 19:17, Philippe Verdy a écrit :
>
>> Encore une fois je ne suis pas d'accord sur l'admin_level 10 qui n'est
>> pas pour ça. Ce devrait être admin_level 9 pour TOUTES ces communes
>> membres de communes nouvelles. Le  niveau 10 est uniquement pour les
>> subdivisions INFRA-communales, mais les communes membres de comune
>> nouvelles restent des communes avec leur propre quartiers.
>>
>> C'est récurernt mais certains bloquent encore sur le fait que les
>> niveau 9 est aussi utilisé à Paris/Lyon/Marseille pour leurs
>> arrondissements communaux mais il n'y a aucune commune membre dedans
>> et ce ne sont pas des communes nouvelles. Bref aucuine confusion
>> possible.
>>
>> J'insiste, c'est le niveau 9, pas le niveau 10 qui restent pour les
>> quartiers et les communes membres de communes nouvelles ne sont pas de
>> simples quartiers, et conservent même leur propre découpage
>> administratif en quartiers.
>>
>
L'ennui des admi_level c'est qu'on en aura jamais assez et si on regarde
déjà ils recouvrent déjà des statuts différents
Meme admin_level=8 pour une commune nouvelle c'est une surcharge de
l'admin_level=8 des communes simples.

On a encore les admin_level des COM et DOM et de la Nouvelle Calédonie qui
sont aussi des statuts spécifiques différents. On a encore une surcharge du
niveau 6 pour la métropole de Lyon depuis sa séparation du département du
Rhône.

Les admin_level sont juste une hiérarchie arbitraire propre à OSM destiné à
montrer ce qui est plus ou moins comparable même si les statuts réels sont
différents. Quoi qu'on fasse ce ne sera jamais parfait mais gardons ce qui
est comparable : le niveau 10 c'est pour les quartiers de toutes les
communes quel que soit leur statut, chacun a droit à ses quartiers, même si
c'est une commune déléguée ou associée. Comme on a promu la commune
nouvelle en niveau 8 (alors que c'est déjà une surcharge des communes
simples) on ne peut pas échapper alors au second tag pour codfifier le
statut précis qu'un admin_level ne peut pas coder seul.

On l'avait évoqué : admin_type=* avec en valeur nun ode propre à la France
admin_type=FR:* Mais c'est suelement pour ceux qui ne savent pas lire les
données (de toute façon qu'iy a-t-til de commun entre les arrondissements
municipaux de Paris, de Lyon ou de Marseille? Ces statuts sont déjà
spécifiques et en fait différents pour chacune de ces villes qui ont leur
statut particulier. Ce code est là pour couper les cheveux en 4 puisque
hiérarchiquement il n'y a de toute façon aucune confusion possible.

L'admin_level 10 c'est pour les quartiers administratifs qui correspondent
chacun à une ou plusieurs zones cadastrales (quand il y en a plusieurs
c'est que ces quartiers sont eux-même redécoupés en
sous-quartiers/micro-quartiers):; en gros c'est ce qui correspond aux
premières lettres du code de la planche cadastrales. (quand il y a des
chiffres avant c'est en fait un code INSEE sur 3 chiffres d'une ancienne
commune autonome qui a fusionné dans une autre, ou bien c'est 000 pour la
commune chef-lieu, les chiffres après les lettres osnt des numéros de
feuilles ou microquartiers selon le cas dans une même zone cadastrale
(lettres + le préfixe à 3 chiffres éventuel).

Et ce n'est pas parce qu'on n'a pas délimité encore tous les quartiers
administratifs (il en manque plein dans OSM mais ils existent) qu'on doit
les reléguer maintenant au niveau 11 parce que la commune a fusionné dans
une autre, ni qu'on doit en plus déplacer le niveau 11 des sous-quartiers
au nbiveau 12. Ce cschéma serait en fait encore moins homogène que la
solution simple d'utiliser le n iveau 9 pour les communes déléguées ou
associées d'une commune nouvelle.

LE tag complémentaire "pour couper les cheveux en 4" c'est juste pour
répondre à ta crainte, qui en pratique n'aé même pas lieu d'être. Si tu
crois qu'il en faiut un, alors uatant taguer tout de suite les
arrondissements munucipaux de PLM avec
admin_type=FR:arrondissement_municipal (en plus de l'admin_level=9) et le
problème est réglé, et on ne change pas la structure globale de la
hiérarchie qui reste homogène malgré les statuts légèrement différents. Les
arrondissements municipaux et communes déléguées ou associées ont tous en
commun d'avoir bel et bien un maire, un état-civil propre, un budget propre
(même s'il est décié par une autre entité) dans le conseil municipal de la
commune nouvelle qui les regroupe.

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-28 Par sujet osm . sanspourriel


je ne vois pas trop l'intérêt d'un tel attribut old_admin_level.
http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Date_namespace_suffix_as_.22keyname:DATESPEC.3D...22 
propose une solution propre et générique :


admin_level:-2016-01-01=8
admin_level:2016-01-01-=10

old_admin_level c'est du suisse ;-).


Le 28/12/2015 19:43, Vincent de Château-Thierry - osm.v...@free.fr a écrit :


Je verrais bien à la place de tout ça le recours au tag 
old_admin_level=8 couplé à un end_date. C'est utilisé en Suisse, mais 
je ne connais pas le contexte.


vincent



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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes


Bonsoir,

Le 28/12/2015 19:17, Philippe Verdy a écrit :

Encore une fois je ne suis pas d'accord sur l'admin_level 10 qui n'est
pas pour ça. Ce devrait être admin_level 9 pour TOUTES ces communes
membres de communes nouvelles. Le  niveau 10 est uniquement pour les
subdivisions INFRA-communales, mais les communes membres de comune
nouvelles restent des communes avec leur propre quartiers.

C'est récurernt mais certains bloquent encore sur le fait que les
niveau 9 est aussi utilisé à Paris/Lyon/Marseille pour leurs
arrondissements communaux mais il n'y a aucune commune membre dedans
et ce ne sont pas des communes nouvelles. Bref aucuine confusion
possible.

J'insiste, c'est le niveau 9, pas le niveau 10 qui restent pour les
quartiers et les communes membres de communes nouvelles ne sont pas de
simples quartiers, et conservent même leur propre découpage
administratif en quartiers.

Le 28 décembre 2015 à 18:49, Stéphane Péneau > a écrit :

Le 28/12/2015 17:57, Christian Quest a écrit :
Les étapes que je vois à réaliser:
- création de la nouvelle relation type=boundary de la nouvelle
commune
- admin_level=8
- start_date=2016-01-01
- ref:INSEE = celui du chef lieu
- population= celle indiquée dans les arrêtés... ou somme des
population des communes fusionnées
- membres: outer=way frontière + admin_centre le noeud
place=* du chef
lieu

- déclassement des anciennes communes en admin_level=10
- ajouter un tag pour spécifier communes associée ou autre ?
(j'avoue
n'avoir pas creusé les différents cas)

- déclassement en admin_level=10 des frontières entre les communes
fusionnées

Autre chose ?

Dans la relation :
name = nom de la commune nouvelle
boundary=admin
Tag wikipedia si un article existe

Il y a les cas où la commune nouvelle remplace la communauté de
commune/aglo/... Il ne faut donc pas créer une relation, mais
modifier celle de la comcom. Enfin je pense

Pour le ref:INSEE, c'est vraiment celui du chef-lieu qu'il faut
utiliser ?


Je trouverais dommage de mélanger 2 notions derrière le même tag 
admin_level=9. Soit on rajoute un tag (à trouver) pour spécifier qu'on a 
d'un côté des arrondissements municipaux, et de l'autre d'anciennes 
communes, soit on trouve autre chose qu'admin_level=9 pour les anciennes 
communes. Sachant que personnellement je suis contre l'idée de devoir 
"coder en dur" la distinction sur la foi des valeurs des codes, du style 
"si le code est 75112 alors c'est un arrondissement", etc.
D'un autre côté, passer les anciennes communes en admin_level=10 empêche 
la définition de quartiers à l'intérieur de ces emprises, puisque la 
modélisation des niveaux admins, en France (mais ailleurs a priori 
aussi), se fait sans recouvrement entre entités de même niveau.


Je verrais bien à la place de tout ça le recours au tag 
old_admin_level=8 couplé à un end_date. C'est utilisé en Suisse, mais je 
ne connais pas le contexte.


vincent

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes



Le 28/12/2015 20:36, osm.sanspourr...@spamgourmet.com a écrit :

je ne vois pas trop l'intérêt d'un tel attribut old_admin_level.
http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Date_namespace_suffix_as_.22keyname:DATESPEC.3D...22
propose une solution propre et générique :

admin_level:-2016-01-01=8
admin_level:2016-01-01-=10

old_admin_level c'est du suisse ;-).


Donc on aurait autant de _tags_ distincts que de jours de bascule entre 
ancien et nouveau statut. Pas très "générique".
Avec notre mécanisme de clé-valeur, on a toujours intérêt à garder côté 
valeur le spécifique, et côté tag le générique. Ce que tu proposes 
garantit au fil du temps une inflation du nombre de tags, mécaniquement. 
Pour moi c'est l'assurance de se retrouver avec une information 
inutilisable.


À côté de ça, pour être clair, je n'ai aucune action dans 
old_admin_level (ici ou en Suisse ;) )


vincent

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes



Le 28/12/2015 20:27, Philippe Verdy a écrit :


L'ennui des admi_level c'est qu'on en aura jamais assez et si on regarde
déjà ils recouvrent déjà des statuts différents
Meme admin_level=8 pour une commune nouvelle c'est une surcharge de
l'admin_level=8 des communes simples.


Surcharge ? J'ai plutôt compris qu'on parlait de substitution.


On a encore les admin_level des COM et DOM et de la Nouvelle Calédonie
qui sont aussi des statuts spécifiques différents. On a encore une
surcharge du niveau 6 pour la métropole de Lyon depuis sa séparation du
département du Rhône.



On l'avait évoqué : admin_type=* avec en valeur nun ode propre à la
France admin_type=FR:* Mais c'est suelement pour ceux qui ne savent pas
lire les données (de toute façon qu'iy a-t-til de commun entre les
arrondissements municipaux de Paris, de Lyon ou de Marseille? Ces
statuts sont déjà spécifiques et en fait différents pour chacune de ces
villes qui ont leur statut particulier. Ce code est là pour couper les
cheveux en 4 puisque hiérarchiquement il n'y a de toute façon aucune
confusion possible.



L'admin_level 10 c'est pour les quartiers administratifs qui
correspondent chacun à une ou plusieurs zones cadastrales (quand il y en
a plusieurs c'est que ces quartiers sont eux-même redécoupés en
sous-quartiers/micro-quartiers):; en gros c'est ce qui correspond aux
premières lettres du code de la planche cadastrales. (quand il y a des
chiffres avant c'est en fait un code INSEE sur 3 chiffres d'une ancienne
commune autonome qui a fusionné dans une autre, ou bien c'est 000 pour
la commune chef-lieu, les chiffres après les lettres osnt des numéros de
feuilles ou microquartiers selon le cas dans une même zone cadastrale
(lettres + le préfixe à 3 chiffres éventuel).

Et ce n'est pas parce qu'on n'a pas délimité encore tous les quartiers
administratifs (il en manque plein dans OSM mais ils existent) qu'on
doit les reléguer maintenant au niveau 11 parce que la commune a
fusionné dans une autre, ni qu'on doit en plus déplacer le niveau 11 des
sous-quartiers au nbiveau 12. Ce cschéma serait en fait encore moins
homogène que la solution simple d'utiliser le n iveau 9 pour les
communes déléguées ou associées d'une commune nouvelle.


Pour moi il n'y a aucun rapport entre les zonages admin_level=10 et les 
feuilles cadastrales. Il peut y avoir d'heureux hasards où les limites 
coïncident, mais sans plus. Le niveau 10 est par exemple celui, en zone 
urbaine, de "conseils de quartier", sans rapport avec le découpage 
cadastral.



LE tag complémentaire "pour couper les cheveux en 4" c'est juste pour
répondre à ta crainte, qui en pratique n'aé même pas lieu d'être. Si tu
crois qu'il en faiut un, alors uatant taguer tout de suite les
arrondissements munucipaux de PLM avec
admin_type=FR:arrondissement_municipal (en plus de l'admin_level=9) et
le problème est réglé, et on ne change pas la structure globale de la
hiérarchie qui reste homogène malgré les statuts légèrement différents.
Les arrondissements municipaux et communes déléguées ou associées ont
tous en commun d'avoir bel et bien un maire, un état-civil propre, un
budget propre (même s'il est décié par une autre entité) dans le conseil
municipal de la commune nouvelle qui les regroupe.


On a un début sur ce schéma, par Jérôme :
http://taginfo.openstreetmap.org/keys/admin_type%3AFR#values
Pourquoi pas en effet aller au bout de la logique avec
admin_type=FR:arrondissement_municipal
pour les arrondissements de PLM. Et dans ce cas on oublie mon 
old_admin_level.


vincent

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-28 Par sujet osm . sanspourriel

Oui, plus ou moins, mais avec une règle (j'ai oublié : tout en gardant 
le tag actuel admin_level=) et un logiciel peut exploiter ces clés avec 
des expressions régulières.


Et toi, tu comptes faire des old_old_admin_level ?
L'inconvénient des old_truc_much  c'est qu'on ne sait pas les dater.

Je n'ai aucune action non plus dans 
http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Date_namespace_suffix_as_.22keyname:DATESPEC.3D...22


admin_level:start_date=... a l'inconvénient de ne pas dire de quel 
niveau il s'agit.


Je vois que le cas d'Audierne et Esquibien qui deviennent Audierne avait 
été oublié, je vais mettre à jour le wiki.

Jean-Yvon


Le 28/12/2015 20:47, Vincent de Château-Thierry - osm.v...@free.fr a écrit :


Donc on aurait autant de _tags_ distincts que de jours de bascule 
entre ancien et nouveau statut. Pas très "générique".
Avec notre mécanisme de clé-valeur, on a toujours intérêt à garder 
côté valeur le spécifique, et côté tag le générique. Ce que tu 
proposes garantit au fil du temps une inflation du nombre de tags, 
mécaniquement. Pour moi c'est l'assurance de se retrouver avec une 
information inutilisable.


À côté de ça, pour être clair, je n'ai aucune action dans 
old_admin_level (ici ou en Suisse ;) )


vincent


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-28 Par sujet Tyndare


Je relance le sujet sur le node place de la commune nouvelle.
Ça m'embête qu'il n'y en ai pas.

A partir du moment ou la commune existe et que l'emplacement de son chef lieu 
est  connu je ne voie pas pourquoi on n'aurait pas de tag place avec le nom 
associé.
Sans ça on aura des centaines de communes qui n'apparaîtront sur quasiment 
aucun rendu.

Si on suit le raisonnement du tag place qui devrait uniquement correspondre aux 
panneau il y a  déjà beaucoup d'erreurs dans OSM.
Par exemple la commune de Chanos-Curson, sur le terrain il y a seulement un 
panneau Chanos et un paneau Curson mais en dehors du village quasiment personne 
ne fait la distinction entre les deux, si vous dites Chanos ça sera interpreté 
comme un diminutif et si vous dites Curson ça ne sera souvent pas compris.
Comme le systeme d'adressage change pour les communes nouvelles ça devrais être 
la même chose pour elles dans quelques années, le nom des anciennes communes 
perdra beaucoup en visibilité et les gens extérieurs chercherons d'abord la 
position de la commune nouvelle.

D'un autre cote si on admet que le tag place correspond a la zone du panneau et 
non a la commune il faudrait alors corriger ou à défaut supprimer sur les nœuds 
de tous les villages français les tags population issues de l'INSEE qui 
correspondent a la population de la commune entière et non à celle du village 
principal.




Le 12 décembre 2015 15:38:09 GMT+01:00, "Vincent de Château-Thierry" 
 a écrit :
>Bonjour,
>
>Le 12/12/2015 14:52, Stéphane Péneau a écrit :
>> Le 12/12/2015 14:32, Stéphane Péneau a écrit :
>>> Le 12/12/2015 13:51, Damien Boilley a écrit :

 Pour moi, le node "place=" de la commune déléguée qui est chef-lieu
 de la commune nouvelle doit prendre le nom de la commune nouvelle,
 avec en old_name le nom ancien. Sauf peut-être si le nom change
 beaucoup...
>>>
>>> Pas de mon point de vue.
>>> On change le nom de la commune dans la relation, mais on ne touche
>pas
>>> au reste, sauf s'il y changement des pancartes sur le terrain.
>
>D'accord avec Stéphane, il arrive qu'aucun node place=* ne porte le nom
>
>de la commune. Ce dernier nom est porté par la relation admin_level=8, 
>et dans le cas présent c'est bien à lui de changer, au moins à court
>terme.
>
>vincent


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

Non les quartiers sont en 10, les sous-quartiers en 11 (on en trouve dans
les grandes villes uniquement, dont Paris, Nantes, Rennes, etc)

Le 28 décembre 2015 à 22:33, David Crochet  a écrit :

> Bonjour
>
> Le 28/12/2015 19:43, Vincent de Château-Thierry a écrit :
>
>> en admin_level=10 empêche la définition de quartiers
>>
>
> Les quartiers, c'est pas du 11 ?
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] Communes nouvelles - fusion de communes

Le 28 décembre 2015 à 21:38, Vincent de Château-Thierry 
a écrit :

>
> Le 28/12/2015 20:27, Philippe Verdy a écrit :
>
>>
>> L'ennui des admi_level c'est qu'on en aura jamais assez et si on regarde
>> déjà ils recouvrent déjà des statuts différents
>> Meme admin_level=8 pour une commune nouvelle c'est une surcharge de
>> l'admin_level=8 des communes simples.
>>
>
> Surcharge ? J'ai plutôt compris qu'on parlait de substitution.


Non car il n'y a aucune substitution. Il s'agit bien d'une surcharge (au
sens programmation objet par exemple), une même information ayant plusieurs
rôles distincts qu'on doit distinguer par des infos supplémentaires codées
séparément (ou non codée... comme c'est déjà le cas en ce moment dans OSM
pour les admin_level),
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes