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

2015-12-28 Par sujet David Crochet 

Bonjour

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

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


Les quartiers, c'est pas du 11 ?

Cordialement

--
David Crochet

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

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

2015-12-28 Par sujet Christian Quest 
J'ai commencé à écrire un script pour simplifier la tâche de création de
ces nouvelles communes...

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

Autre chose ?


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

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


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

Stf

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

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

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

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


-- 
Christian Quest - OpenStreetMap France


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

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

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

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

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

Autre chose ?


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

-- 
Christian Quest - OpenStreetMap France


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

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

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


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


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

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


Les quartiers, c'est pas du 11 ?


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

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

vincent

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

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

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

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

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

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

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

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

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

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

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

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

2015-12-28 Par sujet osm . sanspourriel 

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


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

old_admin_level c'est du suisse ;-).


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


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


vincent



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

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

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

Bonsoir,

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

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

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

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

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

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

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

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

Autre chose ?

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

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

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


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


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


vincent

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

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

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


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

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

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

old_admin_level c'est du suisse ;-).


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


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


vincent

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

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

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


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


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


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


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



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



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

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


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



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


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


vincent

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

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

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


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

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


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


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

Jean-Yvon


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


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


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


vincent


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

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

2015-12-28 Par sujet Tyndare 

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

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

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

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




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

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


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

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

2015-12-28 Par sujet Philippe Verdy 
Non les quartiers sont en 10, les sous-quartiers en 11 (on en trouve dans
les grandes villes uniquement, dont Paris, Nantes, Rennes, etc)

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

> Bonjour
>
> Le 28/12/2015 19:43, Vincent de Château-Thierry a écrit :
>
>> en admin_level=10 empêche la définition de quartiers
>>
>
> Les quartiers, c'est pas du 11 ?
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

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

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


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

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

2015-12-28 Par sujet Philippe Verdy 
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 n'aurait pas de tag place avec
> le nom associé.
> Sans ça on aura des centaines de communes qui n'apparaîtront sur quasiment
> aucun rendu.
>
> Si on suit le raisonnement du tag place qui devrait uniquement
> correspondre aux panneau il y a  déjà beaucoup d'erreurs dans OSM.
> Par exemple la commune de Chanos-Curson, sur le terrain il y a seulement
> un panneau Chanos et un paneau Curson mais en dehors du village quasiment
> personne ne fait la distinction entre les deux, si vous dites Chanos ça
> sera interpreté comme un diminutif et si vous dites Curson ça ne sera
> souvent pas compris.
>

Sur le terrain du trouvera sur les panneaux d'entrée d'agglomération:
- "CHANOS (commune de CHANOS-CURSON)"
- "CURSON (commune de CHANOS-CURSON)"
L'indication de la commune entre parenthèses est en dessous, en plus
petit). Le nom local est bien là, en gros. On trouve même ces panneaux sans
sortir de l'agglomération (exemple Hellemes (commune de Lille).

Il y a plein d'exemple avec les communes associées ou déléguées, qui ont
plusieurs villages séparés (ou même autrefois séparés). Cette indication en
revanche n'est plus là en cas de fusion complète (sans commune déléguée ou
associée, sans mairies locales mais évetuellement juste des "mairies
annexes" sans élus). Pour les communes à arrondissements (PLM) il n'y a pas
ces panneaux d'agglomération mais l'arrondissement est indiqué sur les
plaques de rues.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr