date:20151229


> 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] Requête overpass api & python

les parenthèses c'est pour créer une union de plusieurs ensembles d'objets
et donc éliminer les doublons éventuellement retournés entre les deux
requêtes. cela permet aussi de fournir les données de l'union avec un tri
cohérent.
Sinon les deux out meta retournent les deux ensembles sans les comparer,
c'est plus rapide sur le serveur, et ça lui demande moins de mémoire
temporaire. C'est au client ensuite et non au serveur d'éliminer les
doublons éventuels, et de trier les deux ensembles.

Le 29 décembre 2015 à 16:58, Etienne Trimaille 
a écrit :

> Tu peux remplacer :
> out meta;
> >;
> out meta;
> par
> (
>   ._;
>   >;
> );
> out meta;
>
> Faut pas me demander comment l'écrire. C'est du chinois pour moi :)
> Mais je sais que c'est comme ca qu'il faut supprimer les deux out.
> Entre les parenthèses, c'est pour ajouter les récursivités vers les nœuds.
>
> Le 29 décembre 2015 à 10:25, Tony Emery  a écrit :
>
>> Etienne Trimaille wrote
>> > Exactement comme pour le format, c'est dans la requête overpass qu'il
>> faut
>> > spécifier cela et non pas dans le script python ;-)
>> > Il faut mettre un out meta; au lieu de out body;
>>
>> Petite question supplémentaire, pourquoi doit-on écrire 2 fois "out meta"
>> :
>> );
>> out meta;
>> >;
>> out meta;
>>
>> A priori, le premier concerne les objets qui sont retournés mais je ne
>> vois
>> pas à quoi sert celui qui se trouve après >;
>>
>>
>>
>> -
>> 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/Requete-overpass-api-python-tp5863030p5863364.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


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] Limitation de poids et fin de limitation

intersection avec une voie publique uniquement
Les intersections avec des voies privées (comme les chemins de ferme, ou
les allées d'accès de propriétés privées ou d'aires commerciales privées ou
stations-services, ou parkings privés, même si elles sont ouvertes au
public) ne sont pas des fins de limites, sinon il faudrait des panneaux de
rappel partout. Mais une intersection avec une impasse publique (signalée
par un panneau de rue) est une intersection valide même si l'impasse a un
stop à l'intersection.

Malgré tout il y a des limitations de vitesse qui ne sont pas signalées
partout rue par rue, ce sont les celles des agglomération et zones 30 (si
la limite à 30 a un panneau et ne s'applique qu'à un tronçon de voie tel
qu'un franchissement de passages protégés pour piétons, il y a un panneau
de fin immédiatement après et on retourne à la limite standard de zone,
mais c'est souvent pour de très courtes sections, il est courant de voir
des fins de limite à 30 km/h pour un passage piéton en milieu de rue moins
de 50 mètres avant une nouvelle limitation pour le carrefour ou le
rond-point qui suit, mais il est presque matériellement impossible
d'arriver à la vitesse limite de zone entre les deux si on a respecté la
limite, le panneau de fin de limite ne sert en fait pas à grand chose sauf
polluer l'attention du conducteur qui a trop de panneaux à lire, les fins
de limitation sont alors très théoriques).

Le 29 décembre 2015 à 11:07, osmien  a écrit :

> Bonjour,
>
> En France la Réglementation indique que la fin d'une "réglementation" de
> circulation s'arrête à la prochaine intersection.
>
>  D'ailleurs c'est pour éviter la succession du panneaux "Priorité
> ponctuelle" AB2 qu'il existe le panneaux AB6 qui lui à strictement besoin
> d'un panneau de fin.
>
>
> https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_priorit%C3%A9_ponctuelle_en_France
> https://fr.wikipedia.org/wiki/Panneau_de_route_prioritaire_en_France
>
> Règlement rappelé en 2010
> http://www.senat.fr/questions/base/2010/qSEQ100513522.html
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Limitation-de-poids-et-fin-de-limitation-tp5863366p5863375.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

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] Requête overpass api & python

2015-12-29 Par sujet Etienne Trimaille

Tu peux remplacer :
out meta;
>;
out meta;
par
(
  ._;
  >;
);
out meta;

Faut pas me demander comment l'écrire. C'est du chinois pour moi :)
Mais je sais que c'est comme ca qu'il faut supprimer les deux out.
Entre les parenthèses, c'est pour ajouter les récursivités vers les nœuds.

Le 29 décembre 2015 à 10:25, Tony Emery  a écrit :

> Etienne Trimaille wrote
> > Exactement comme pour le format, c'est dans la requête overpass qu'il
> faut
> > spécifier cela et non pas dans le script python ;-)
> > Il faut mettre un out meta; au lieu de out body;
>
> Petite question supplémentaire, pourquoi doit-on écrire 2 fois "out meta" :
> );
> out meta;
> >;
> out meta;
>
> A priori, le premier concerne les objets qui sont retournés mais je ne vois
> pas à quoi sert celui qui se trouve après >;
>
>
>
> -
> 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/Requete-overpass-api-python-tp5863030p5863364.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

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] fusion de régions

des relations existent déjà, elle sont tagué :
boundary=administrative
admin_level:proposed=4

pour les voir :
http://overpass-turbo.eu/s/dti

Le 29 décembre 2015 à 19:02, Philippe Verdy  a écrit :

> On n'a aucune urgence d'autant que les nouvelles régions n'ont pas encore
> de nom définitif (sauf la Normandie où c'est déjà décidé depuis un moment
> et où tout le monde est d'accord sur le nom).
> Il y a en fait peu d'urgence sur les régions, moins que les comunes
> nouvelles (mais seulement si leur nouveau nom est vraiment original, sinon
> on continue d'utiliser les aanciens noms pour les recherches ou la
> géolocalisation).
>
> De plus le périmètre est connu largement. Ces grandes régions ont de toute
> façon peu d'intérêt pour les recherches, elles sont trop grandes).
>
> Là où ce sera le bordel ce sera avec la disparition des départements, pour
> promouvoir à la place les intercommunalités dans les régions, et supprimer
> le rôle des préfets de départements (et sous-préfets qui n'ont plus
> longtemps à vivre, ça viendra même avant la disparition des départements
> car cet échelon ne sert vraiment à rien meêm pour l'Etat ou ses services
> comme la police ou la justice; à la place des sous-préfets ce sera le
> modèle parisien des préfets de police, la carte des tribunaux va aussi
> changer encore, celles des services médicaux: en gros les services de
> l'Etat ne seront plus liés à la structure administrative actuelle, il y
> aura les collectivités locales et sinon les service répartis sur des zones
> selon leur spécialité et les besoins réels, une fois transdférés plein de
> services sur Internet de façon  dégéolocalisée.)
>
> On commence à voir la fin de la structure hiérarchique uniforme des
> services déconcentrés de l'Etat (qui assume en fait de moins en moins de
> choses en les transférant aux collectivités locales dont le rôle et les
> compétences s'accroit en même temps que leur périmètre terriotorial). Ca
> prend beaucoup de temps en France en comparaison des autres pays européens,
> mais le modèle hiérarchique a vécu. et localement on aura de plus en plus
> de compétences spécifiques et de "statuts particuliers", avec une plus
> grande spécialisation des domaines de compétence pour éviter des doublons
> de compétence. Et cette structure sera de plus en plus dyunamique avec des
> modes de fonctionnement de plus en plus diférents selon les territoires.
>
>
> Le 29 décembre 2015 à 17:57, Francescu GAROBY  a
> écrit :
>
>> Je retire ce que j'ai dit : j'ai l'impression que les relations des
>> (futures) région n'ont pas du tout été faites... En tout cas, je ne trouve
>> pas la relation Normandie (fusion de la Basse et de la Haute-Normandie).
>> Finalement, on n'est pas si en avance que ça...
>>
>> Francescu
>>
>> Le 29 décembre 2015 à 17:50, Francescu GAROBY  a
>> écrit :
>>
>>> Les fusions deviendront effectives au 01/01/2016. Tu es un peu en avance
>>> :-)
>>>
>>> Francescu
>>>
>>> Le 29 décembre 2015 à 17:40,  a écrit
>>> :
>>>
 juste pour rappeler que les régions apparaissent toujours sous leurs
 anciens contours.
 Bon, pour la Bretagne je m'occupe des changements - il n'y a pas de
 changement ;-).

 Jean-Yvon

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


>>>
>>>
>>> --
>>> Francescu
>>>
>>
>>
>>
>> --
>> Francescu
>>
>> ___
>> 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 ! 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] fusion de régions

On n'a aucune urgence d'autant que les nouvelles régions n'ont pas encore
de nom définitif (sauf la Normandie où c'est déjà décidé depuis un moment
et où tout le monde est d'accord sur le nom).
Il y a en fait peu d'urgence sur les régions, moins que les comunes
nouvelles (mais seulement si leur nouveau nom est vraiment original, sinon
on continue d'utiliser les aanciens noms pour les recherches ou la
géolocalisation).

De plus le périmètre est connu largement. Ces grandes régions ont de toute
façon peu d'intérêt pour les recherches, elles sont trop grandes).

Là où ce sera le bordel ce sera avec la disparition des départements, pour
promouvoir à la place les intercommunalités dans les régions, et supprimer
le rôle des préfets de départements (et sous-préfets qui n'ont plus
longtemps à vivre, ça viendra même avant la disparition des départements
car cet échelon ne sert vraiment à rien meêm pour l'Etat ou ses services
comme la police ou la justice; à la place des sous-préfets ce sera le
modèle parisien des préfets de police, la carte des tribunaux va aussi
changer encore, celles des services médicaux: en gros les services de
l'Etat ne seront plus liés à la structure administrative actuelle, il y
aura les collectivités locales et sinon les service répartis sur des zones
selon leur spécialité et les besoins réels, une fois transdférés plein de
services sur Internet de façon  dégéolocalisée.)

On commence à voir la fin de la structure hiérarchique uniforme des
services déconcentrés de l'Etat (qui assume en fait de moins en moins de
choses en les transférant aux collectivités locales dont le rôle et les
compétences s'accroit en même temps que leur périmètre terriotorial). Ca
prend beaucoup de temps en France en comparaison des autres pays européens,
mais le modèle hiérarchique a vécu. et localement on aura de plus en plus
de compétences spécifiques et de "statuts particuliers", avec une plus
grande spécialisation des domaines de compétence pour éviter des doublons
de compétence. Et cette structure sera de plus en plus dyunamique avec des
modes de fonctionnement de plus en plus diférents selon les territoires.


Le 29 décembre 2015 à 17:57, Francescu GAROBY  a écrit :

> Je retire ce que j'ai dit : j'ai l'impression que les relations des
> (futures) région n'ont pas du tout été faites... En tout cas, je ne trouve
> pas la relation Normandie (fusion de la Basse et de la Haute-Normandie).
> Finalement, on n'est pas si en avance que ça...
>
> Francescu
>
> Le 29 décembre 2015 à 17:50, Francescu GAROBY  a
> écrit :
>
>> Les fusions deviendront effectives au 01/01/2016. Tu es un peu en avance
>> :-)
>>
>> Francescu
>>
>> Le 29 décembre 2015 à 17:40,  a écrit :
>>
>>> juste pour rappeler que les régions apparaissent toujours sous leurs
>>> anciens contours.
>>> Bon, pour la Bretagne je m'occupe des changements - il n'y a pas de
>>> changement ;-).
>>>
>>> Jean-Yvon
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Francescu
>>
>
>
>
> --
> Francescu
>
> ___
> 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)

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] fusion de régions

2015-12-29 Par sujet Francescu GAROBY

Les fusions deviendront effectives au 01/01/2016. Tu es un peu en avance :-)

Francescu

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

> juste pour rappeler que les régions apparaissent toujours sous leurs
> anciens contours.
> Bon, pour la Bretagne je m'occupe des changements - il n'y a pas de
> changement ;-).
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Francescu
___
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] fusion de régions

2015-12-29 Par sujet Francescu GAROBY

Je retire ce que j'ai dit : j'ai l'impression que les relations des
(futures) région n'ont pas du tout été faites... En tout cas, je ne trouve
pas la relation Normandie (fusion de la Basse et de la Haute-Normandie).
Finalement, on n'est pas si en avance que ça...

Francescu

Le 29 décembre 2015 à 17:50, Francescu GAROBY  a écrit :

> Les fusions deviendront effectives au 01/01/2016. Tu es un peu en avance
> :-)
>
> Francescu
>
> Le 29 décembre 2015 à 17:40,  a écrit :
>
>> juste pour rappeler que les régions apparaissent toujours sous leurs
>> anciens contours.
>> Bon, pour la Bretagne je m'occupe des changements - il n'y a pas de
>> changement ;-).
>>
>> Jean-Yvon
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Francescu
>



-- 
Francescu
___
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,  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] Trouver le bati manquant

Et pour compléter le tout, je suis tombé un peu par hasard sur un 
comparateur de cartes pas mal fait, celui de mc/bbbike.org :
http://mc.bbbike.org/mc/?lon=-4.431575=48.230761=13=4=osmfr=esri-satellite=nokia-hybrid=yandex-satellite=ol_mapquest-labels=100=L%27Aber 


(remarquez ici le problème de calage de l'imagerie Yandex).

Non seulement il permet de comparer jusqu'à 8 cartes (plus une couche en 
superposition commune - et plus de 150 en utilisant le clavier) mais il 
propose en plus d'une liste déjà conséquente (voir ci-dessous) de 
couches prédéfinies qui cerise sur le gâteau et raison de ce message 
permet d'*ajouter des couches autres*. Ça permet par exemple de voir 
quelles couches utiliser dans JOSM.
En plus les jokers tels que ${z} sont automatiquement créés à partir 
d'une url "bête".
Par contre l'url générique du cadastre comprend une * et je n'ai pas 
réussi à la faire marcher.


Par exemple :

No.NameURL
1Buildings 
https://a.tiles.mapbox.com/v4/pratikyadav.332dd523/${z}/${x}/${y}.png?access_token=pk.eyJ1IjoicHJhdGlreWFkYXYiLCJhIjoiMTA2YWUxNjRkNmFmZGQ4YzAxZWFiNDk0NDM1YjE1YjAifQ.4P6N5dNmA_WQXd3BsJvu5w
2Roads 
https://a.tiles.mapbox.com/v4/pratikyadav.93f1df6f/${z}/${x}/${y}.png?access_token=pk.eyJ1IjoicHJhdGlreWFkYXYiLCJhIjoiMTA2YWUxNjRkNmFmZGQ4YzAxZWFiNDk0NDM1YjE1YjAifQ.4P6N5dNmA_WQXd3BsJvu5w
3Roads wthout names 
https://a.tiles.mapbox.com/v4/pratikyadav.640d9a4d/${z}/${x}/${y}.png?access_token=pk.eyJ1IjoicHJhdGlreWFkYXYiLCJhIjoiMTA2YWUxNjRkNmFmZGQ4YzAxZWFiNDk0NDM1YjE1YjAifQ.4P6N5dNmA_WQXd3BsJvu5w




here : nokia-map, nokia-satellite, nokia-hybrid, nokia-terrain, 
nokia-public_transit, nokia-traffic
google : google-map, google-map-mapmaker, google-physical, 
google-bicycle-map, google-satellite, google-hybrid, 
google-hybrid-mapmaker, google-weather-sat, google-traffic-map, 
google-transit-map, google-layers-physical, google-panoramio-physical
satellite : google-satellite, bing-satellite, mapquest-satellite, 
nokia-satellite, mapbox-satellite, yandex-satellite, baidu-satellite

mapnik : mapnik, mapnik-german, osm-no-labels, mapnik-bw
transit : transport, nokia-public_transit, google-transit-map, 
public_transport, public_transport_lines, openrailwaymap-standard, 
openrailwaymap-maxspeed, transport-dark, openmap-public-transport

bing : bing-map, bing-satellite, bing-hybrid
osm : mapnik, mapnik-german, mapnik-bw, toner, watercolor, cyclemap, 
osm-no-labels, transport, public_transport, hike_bike, wanderreitkarte, 
mapquest-eu, skobbler

cycle : bbbike-german, bbbike-smoothness, cyclemap, adfc-radwege, hike_bike
bbbike : bbbike, bbbike-german, bbbike-bbbike, bbbike-smoothness, 
bbbike-handicap, bbbike-cycle-routes, bbbike-cycleway, bbbike-green, 
bbbike-unlit, bbbike-unknown
topo : google-physical, google-layers-physical, esri-topo, esri, 
nokia-terrain, cyclemap, landscape, wanderreitkarte, maptoolkit-topo, 
opentopomap, landshaded, komoot, opensnowmap, mapbox-terrain, outdoors
berlin : bbbike-german, bbbike-smoothness, google-map, bvg, transport, 
nokia-public_transit, lgb-webatlas, lgb-topo-10, lgb-history-1902, 
lgb-history-1767
openmapsurfer : osm-roads, osm-roads-greyscale, osm-semitransparent, 
aster-gdem-srtm-hillshade, aster-gdem-contour-lines, 
osm-administrative-boundaries
esri : esri, esri-topo, esri-gray, esri-satellite, esri-physical, 
esri-shaded-relief, esri-terrain-base, esri-boundaries-places, 
esri-reference-overlay, esri-transportation, esri-natgeo, esri-ocean

boundaries : osm-administrative-boundaries, esri-boundaries-places
falk : falk-osm, falk-base
mapbox : mapbox-satellite, mapbox-transportation, mapbox-terrain, 
comic-sans, mapbox-runkeepers
geofabrik : geofabrik-standard, geofabrik-german, geofabrik-topo, 
geofabrik-night

ito : max-speed, ito-lit, ito-surface
retina : lyrk-retina, google-map, mapbox-transportation, mapbox-terrain, 
openrailwaymap-standard, toner-retina
waymarkedtrails : waymarkedtrails-hiking, waymarkedtrails-cycling, 
waymarkedtrails-mtb, waymarkedtrails-skating

mapquest : mapquest-eu, mapquest-labels, mapquest-satellite
russian : sputnik-map, yandex-map, yandex-satellite, yandex-hybrid, 
chepetsk-map, kosmosnimki-map, kosmosnimki-night

yandex : yandex-map, yandex-satellite, yandex-hybrid
bw : toner-retina, toner, osm-roads-greyscale, mapnik-bw
hillshading : hillshading, landshaded, aster-gdem-srtm-hillshade
extract : mapnik, google-map, nokia-map, mapbox-hybrid
night : geofabrik-night, transport-dark, osm-lights
thunderforest : cyclemap, landscape, transport, outdoors, transport-dark
uni-heidelberg : osm-roads, osm-roads-greyscale, osm-semitransparent, 
aster-gdem-srtm-hillshade, aster-gdem-contour-lines, 
osm-administrative-boundaries, osm-lights

baidu : baidu-map, baidu-satellite, baidu-labels
lgb : lgb-webatlas, lgb-topo-10, lgb-topo-50, lgb-history-1902, 
lgb-history-1767,

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" 
> To: "Discussions sur OSM en français" 
> 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  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" 
>> To: "Discussions sur OSM en français" 
>> 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] fusion de régions

Visiblement la Normandie a perdu bien des tags des régions Haute- et 
Basse-Normandie.

Par exemple les traductions.
Certaines sont faciles (name:en=Normandy).
Pour d'autres il faudra peut-être retrouver les auteurs des traductions 
des *-Normandie (ou sur Wikipedia).


Pour "Nord-Pas-de-Calais et Picardie" il doit suffire de savoir dire 
"et" ;-).


Jean-Yvon

Le 29/12/2015 19:52, Jérôme Amagat - jerome.ama...@gmail.com a écrit :

des relations existent déjà, elle sont tagué :
boundary=administrative
admin_level:proposed=4

pour les voir :
http://overpass-turbo.eu/s/dti


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

Re: [OSM-talk-fr] Trouver le bati manquant

2015-12-29 Par sujet Nicolas Moyroud

Excellentes ces couches ! Je viens de les ajouter aux couches 
disponibles dans le logiciel GPS Oruxmaps. Parfait pour repérer sur le 
terrain les rues non nommées. Il va falloir que j'intègre cette nouvelle 
stratégie pour la prochaine carto-partie avec mes étudiants. On va 
gagner en efficacité.

Sympa aussi le map compare de bbbike. Plus complet que celui de geofabrik.

Nicolas

Le 27/12/2015 10:03, Stéphane Péneau a écrit :

Hello !

Mapbox vient de donner accès à plusieurs couches TMS thématiques :
http://www.openstreetmap.org/user/pratikyadav/diary/37646

L'une d'elles concerne le bati intégré dans Osm, et permet de 
facilement retrouver ce qui manque en la superposant à la couche TMS 
du cadastre :

http://www.stemani.fr/public/Osm/mapbox_buildings_vs_cadastre.JPG

Stf



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

Re: [OSM-talk-fr] Limitation de poids et fin de limitation

2015-12-29 Par sujet Laurent Combe

juste pour partager avec vous
je vous donne la réponse de ma moitié qui m'a bien fait rire

"il n'y a pas de panneau de fin puisque les véhicules concernés ne rentrent
pas sur cette voie"

Le 29 décembre 2015 à 11:07, osmien  a écrit :

> Bonjour,
>
> En France la Réglementation indique que la fin d'une "réglementation" de
> circulation s'arrête à la prochaine intersection.
>
>  D'ailleurs c'est pour éviter la succession du panneaux "Priorité
> ponctuelle" AB2 qu'il existe le panneaux AB6 qui lui à strictement besoin
> d'un panneau de fin.
>
>
> https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_priorit%C3%A9_ponctuelle_en_France
> https://fr.wikipedia.org/wiki/Panneau_de_route_prioritaire_en_France
>
> Règlement rappelé en 2010
> http://www.senat.fr/questions/base/2010/qSEQ100513522.html
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Limitation-de-poids-et-fin-de-limitation-tp5863366p5863375.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

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] fusion de régions

Remember...
https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/068612.html

Au 1er Janvier, il suffira de vérifier que les relations sont toujours OK
et de mettre à jour les tags... et hop ;)

Le 29 décembre 2015 à 23:00,  a écrit :

> Visiblement la Normandie a perdu bien des tags des régions Haute- et
> Basse-Normandie.
> Par exemple les traductions.
> Certaines sont faciles (name:en=Normandy).
> Pour d'autres il faudra peut-être retrouver les auteurs des traductions
> des *-Normandie (ou sur Wikipedia).
>
> Pour "Nord-Pas-de-Calais et Picardie" il doit suffire de savoir dire "et"
> ;-).
>
> Jean-Yvon
>
> Le 29/12/2015 19:52, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> des relations existent déjà, elle sont tagué :
> boundary=administrative
> admin_level:proposed=4
>
> pour les voir :
> http://overpass-turbo.eu/s/dti
>
>
>
> ___
> 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

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  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  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" 
>>> To: "Discussions sur OSM en français" 
>>> 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] Requête overpass api & python

2015-12-29 Par sujet Tony Emery

Etienne Trimaille wrote
> Exactement comme pour le format, c'est dans la requête overpass qu'il faut
> spécifier cela et non pas dans le script python ;-)
> Il faut mettre un out meta; au lieu de out body;

Petite question supplémentaire, pourquoi doit-on écrire 2 fois "out meta" : 
);
out meta;
>;
out meta;

A priori, le premier concerne les objets qui sont retournés mais je ne vois
pas à quoi sert celui qui se trouve après >;



-
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/Requete-overpass-api-python-tp5863030p5863364.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

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

[OSM-talk-fr] Limitation de poids et fin de limitation

2015-12-29 Par sujet Ludovic Hirlimann

Bonjour,

C'est quoi le tag pour indiquer les limitations de poids (eg indertid au
plus de  6 tonnes) ?.

Enfin comment on determine une fin de zone. J'ai une rue ou un panneau
indique une limitation de vitesse, il n'y a pas de fin de cette
limitation, deux intersection plus loin 'ai la même limitation sans le
mot rappel  dans l'autre sens aucun panneau. Les intersections
forment-elles des fin de limite ?


Ludo
-- 
https://www.flickr.com/photos/lhirlimann/

___
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] Limitation de poids et fin de limitation

2015-12-29 Par sujet Francescu GAROBY

Bonjour,
Pour la limitation de poids, c'est le tag "maxweight=*
"

Pour les fins de limitation : si j'ai bien compris, c'est le cartouche
"rappel" qui est manquant. La limitation n'est levée que par un panneau de
fin de limitation ou un changement de "statut" de la route (en : une
nationale qui devient une route pour automobile entraîne implicitement un
changement de limitation de vitesse).

Francescu

Le 29 décembre 2015 à 10:26, Ludovic Hirlimann  a
écrit :

> Bonjour,
>
> C'est quoi le tag pour indiquer les limitations de poids (eg indertid au
> plus de  6 tonnes) ?.
>
> Enfin comment on determine une fin de zone. J'ai une rue ou un panneau
> indique une limitation de vitesse, il n'y a pas de fin de cette
> limitation, deux intersection plus loin 'ai la même limitation sans le
> mot rappel  dans l'autre sens aucun panneau. Les intersections
> forment-elles des fin de limite ?
>
>
> Ludo
> --
> https://www.flickr.com/photos/lhirlimann/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Francescu
___
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 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] Requête overpass api & python

2015-12-29 Par sujet Jo

d'abord pour les données résultant de la requête, puis >; veut dire que tu
veux tous les objets dépendants (les noeuds pour les ways, p.e.), puis tu
veux les données meta pour ceux-là aussi.

Polyglot

2015-12-29 10:25 GMT+01:00 Tony Emery :

> Etienne Trimaille wrote
> > Exactement comme pour le format, c'est dans la requête overpass qu'il
> faut
> > spécifier cela et non pas dans le script python ;-)
> > Il faut mettre un out meta; au lieu de out body;
>
> Petite question supplémentaire, pourquoi doit-on écrire 2 fois "out meta" :
> );
> out meta;
> >;
> out meta;
>
> A priori, le premier concerne les objets qui sont retournés mais je ne vois
> pas à quoi sert celui qui se trouve après >;
>
>
>
> -
> 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/Requete-overpass-api-python-tp5863030p5863364.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

Re: [OSM-talk-fr] Limitation de poids et fin de limitation

2015-12-29 Par sujet osmien

Bonjour,

En France la Réglementation indique que la fin d'une "réglementation" de
circulation s'arrête à la prochaine intersection.

 D'ailleurs c'est pour éviter la succession du panneaux "Priorité
ponctuelle" AB2 qu'il existe le panneaux AB6 qui lui à strictement besoin
d'un panneau de fin.

https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_priorit%C3%A9_ponctuelle_en_France
https://fr.wikipedia.org/wiki/Panneau_de_route_prioritaire_en_France

Règlement rappelé en 2010
http://www.senat.fr/questions/base/2010/qSEQ100513522.html



--
View this message in context: 
http://gis.19327.n5.nabble.com/Limitation-de-poids-et-fin-de-limitation-tp5863366p5863375.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

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...