Bonsoir, euh, quel est le rapport avec les routes ? Une erreur d’aiguillage je 
pense

Gaël

Le 24 nov. 2017 à 23:04, Philippe Verdy <[email protected]> a écrit :

Concernant les communes nouvelles (et les anciennes communes en 
fusion-association), elles ont pratiquement toujours un nouveau nom qui n'est 
pas celui de leur communes déléguées (ou associées), chacune conservant sa 
toponymie propre.
Les noeuds admin_centre de ces communes nouvelles ne devraient PAS être celui 
de la commune nouvelle mais celui de la commune déléguée. Osmose incite à 
changer les noms de ces noeuds et rouspète à tord concernant les codes INSEE 
qui sont toujours associés à chacune des communes membres (déléguées ou 
associées).
Osmose ne semble pas prendre en compte du tout les statuts et traite de façon 
indifférenciées celles en fusion-association ou les communes nouvelles qu'elles 
traitent comme si c'était des communes simples (ou complètement fusionnées sans 
association ni commune nouvelle, par annexion complète). Pourtant on a encore 
besoin de ces "anciens" codes INSEE qui font toujours référence.
La base COG utilisée par Osmose est donc incomplète et conduit soit à des 
faux-positifs soit à changer à tord les noms.
Je veux bien qu'on ajoute un noeud fictif pour l'admin_centre pour les communes 
nouvelles ou en fusion-association, à côté du noeud de sa commune membre siège 
de cette association, masi on ne devrait pas éliminer les anciens noms des 
communes membres, même si on les associee à un niveau inférieur pour la valeur 
donnée à place=*. Cependant nombre des communes en fusion-association ou 
communes nouvelles sont encore trop petites pour devenir des "place=town", 
elles restent "place=village" la plupart du temps, et il est difficile de dire 
que les communes membres sont des "place=hamlet" car la plupart du temps elles 
gardent une population largement supérieure à celle d'un simple hameau. comment 
faire pour différencier ces noms et ne pas les faire disparaître ?
Aussi je proposerais de ne plus associer les codes INSEE/SIREN/population du 
tout aux noeuds place, mais uniquement aux relations qui porteront les noms 
corrects et codes INSEE/SIREN des communes de plein exercice, comme aussi pour 
les communes membres. Et alors de ne garder pour "place=*" que le niveau 
d'importance relative de chaque localité : si c'est le principal bourg (au sens 
du découpage urbain), prendre la population de la commune membre correspondante 
dont elle est le principal bourg, mais pas celle de la commune entière (en 
fusion-association ou commune-nouvelle) et alors déterminer la valeur de 
place=* de façon  cohérente.

Reste ensuite si à savoir si on a réellement besoin de mettre un noeud place 
pour situer la commune entière et si on le fait, est-il seulement nécessaire de 
lui donner une valeur place=* ? A mon avis non! ce ne devrait servir qu'à 
redonner le nom de la commune entière, et ne serait utilisé que comme 
role="label" dans sa relation, alors que le chef-lieu (role=admin_centre) de 
cette commune continuera à référencer le vrai noeud place de la commune membre 
avec son nom propre (pas celui de la commune entière). Ce noeud "role=label" 
n'aura aucun "place=city/town/village" ou pourrait avoir une valeur spéciale 
(tel que "place=municipality") ne tenant PAS compte de sa population totale qui 
n'a pas non plus besoin d'être indiqué, mais on pourrait éventuellement lui 
attribuer un ref:INSEE (le même que celui de la commune membre) et un 
ref:FR:SIREN (celui de la nouvelle municipalité et non celui de la commune 
membre chef-lieu)

> Le 24 novembre 2017 à 20:23, Christian Quest <[email protected]> a 
> écrit :
> J'ai repris le dégommage de carreaux INSEE sans route à proximité (carreaux 
> rose magenta sur le rendu QA). Pour mémoire, l'INSEE publie la population 
> répartie sur des carreaux de 200m de côté... qui dit habitants, dit route 
> pour allez chez eux d'où ce croisement.
> 
> Les stats baissent doucement mais sûrement comme le montrent les graphes de 
> suivi: 
> http://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/osm_stats.html
> et http://osm2020.free.fr/qa-commune/suivi-cadastre.htm
> 
> Il n'en reste plus qu'environ 6000, de quoi faire un petit challenge à 
> terminer avant d'attaquer 2018, non ?
> 
> Ces carreaux INSEE sans route proche sont visibles dans le rendu QA, mais 
> aussi dans Osmose:
> 
> http://osmose.openstreetmap.fr/fr/map/#source=14708&item=7170&class=10&zoom=9&lat=49.109&lon=4.096&layer=Mapnik&overlays=FFFFFFFFFFFFFFFFFFFFT&level=1%2C2%2C3&tags=&fixable=
> 
> Après avoir bien dégommé autour de la région parisienne, puis le 77, le 89, 
> je suis sur l'Aube.
> 
> Un coup d'osmose + josm-zone, un peu de BD Ortho, de BANO, de cadastre et ça 
> se complète assez facilement. C'est aussi l'occasion de découvrir parfois des 
> coins où beaucoup de choses basiques manquent encore !
> Il y a parfois des faux positifs, n'oubliez pas de les indiquer dans osmose 
> (et d'indiquer ceux corrigés pour éviter que quelqu'un ne repasse dessus 
> avant la mise à jour nocturne).
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> _______________________________________________
> Talk-fr mailing list
> [email protected]
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à