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

Sam 15 Fév 03:36:30 UTC 2020

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

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

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

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

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

Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr <talk-fr at openstreetmap.org>
a écrit :

> Je voudrais proposer de modifier la façon de traiter les communes
> nouvelles françaises dans OSM.
>
> Je considère qu'une nouvelle commune devrait être enregistrée de la même
> façon qu'une ancienne commune issue de fusion de plusieurs communes.
>
> La possibilité de fusion des communes en France est très ancienne, elle
> a plus de 50 ans. Par exemple, certaines communes sont issues d'une
> campagne de fusion des années 1970. Ces dernières portent souvent le nom
> des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont
> pas distinguées des communes non issues de fusion (ou plutôt, celles
> dont on se souvient qu'elles ne sont pas issues de fusion ; si on
> remonte très loin, au Moyen-Âge, ces communes non issues de fusion
> doivent être assez rares).
>
> De façon que je considère arbitraire, les communes issues de fusion
> d'après 2010 (pourquoi ne pas prendre celles avant 2010 ?) , il a été
> décidé ici même de traiter à part les communes nouvelles en ne les
> enregistrant que par leur frontière et sous forme de relation avec leurs
> anciennes communes membres et leur admin_centre. Il a aussi été décidé
> de ne pas les repérer par un nœud place=* contrairement aux communes
> d'avant 2010 même issues de fusion (donc beaucoup comme on l'a vu).
>
> La conséquence la plus visible est que ces communes sont totalement
> invisibles dans le rendu officiel osm.org qui n'affiche pas le nom des
> zones englobées par une frontière sans place=*.  Il y a pourtant
> d'autres limites dont le nom est affiché comme les forêts, etc.
> Geoportail de l'IGN affiche bien, lui, ces nouvelles communes.
>
> On répond que les nouvelles communes ne sont que des délimitations
> administratives qui n'ont pas vocation à être des lieux-dits. Cette
> opinion est contestable car c'est pourtant comme cela que l'on note les
> anciennes communes issues ou non de fusion. De plus dans l'esprit du
> législateur, les nouvelles communes issues de fusions récentes ont
> vocation à fonctionner comme les autres communes en intégrant
> complètement les anciennes qui ne deviennent que des sortes de quartiers
> ou arrondissements. Ces anciennes communes peuvent être des villages et
> parfois des petites villes (plus de 10000 habitants aux abords d'une
> grande agglomération).
>
> Par exemple, une commune classique non issue de fusion récente comporte
> souvent un bourg qui est appelé Le Bourg par les habitants et est
> rarement repéré par ce nom dans Osm.org (alors que BANO peut le
> marquer). En général, la mairie décide de noter sur les panneaux
> d'entrées du bourg le nom de la commune. Donc la commune est aussi un
> lieu-dit qui devrait être noté par place=* au niveau du bourg ou de
> l'agglomération principale. Dans le cas d'une commune issue de fusion
> récente, certaines mairies n'affichent que le nom de la commune issue de
> fusion et pas l'ancienne. D'autres affichent le nom de l'ancienne
> commune avec mention du nom de la nouvelle dessous. Évidemment, quand le
> nom de la commune issue de la fusion est le même que celle de celui de
> la commune admin_centre, le problème est plus simple.
>
> Les habitants et autres partenaires des nouvelles communes récentes font
> de moins en moins la distinction avec le fonctionnement des communes non
> fusionnées récemment que ce soit pour leurs relations avec la mairie, la
> Poste, etc. (bien sûr après un temps d'adaptation plus ou moins facile
> et plus ou moins heureux). Ils ont donc de plus en plus besoin de
> repérer leur commune nouvelle sur une carte.
>
> En conséquence de ce que j'écris ci-dessus, ma proposition est la suivante
> :
>
> Traiter les nouvelles communes comme les anciennes avec une relation
> frontière (boundary) et un nœud place=* mis aux abords de l'admin-centre
> ou bien vers le centre de la commune.
>
> Garder le nœud place=* et la relation frontière (boundary) des anciennes
> communes comme on le fait déjà pour les place=village des lieux-dits
> d'agglomération de plus de 200 et de moins de 10000 habitants à
> l'intérieur d'une commune « non fusionnée » récemment.
>
> Cette proposition permet de simplifier les contributions ainsi que les
> moteurs de rendus.
>
> --
> Rpnpif
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200215/73cad7a7/attachment.htm>