je viens d'ajouter ma pierre à l'objectif "dégommer du rose" en partant de toulouse et en remontant vers le nord jusqu'aux portes du cantal j'ai dégommé du rose
si des contributeurs locaux (je parle de la région Toulousaine) veulent se saisir de cet objectif pas de problème le lauragais, l'ariège et le gers sont des terrains de jeux qui n'attendent que vous ... je redonne un lien actualisé : http://osmose.openstreetmap.fr/fr/map/#source=14708&item=7170&class=10&zoom=9&lat=43.691&lon=2.151&layer=Mapnik&overlays=FFFFFFFFFFFFFFFFFFFFT&level=1%2C2%2C3&tags=&fixable= Le 25 novembre 2017 à 00:09, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Pas une erreur, le rose concernait les carreaux de "population" INSEE et > là je parle bien de la cartographie de population (le découpage urbaine à > l'INSEE) qui dans OSM est ce qui est représenté par les noeuds place= basés > aussi suir les chiffres de population (pour place=city/town/village/hamlet) > totalement indépendamment du découpage adminsitratif. > Mais on a toujours un problème avec Osmose qui veut qu'on modifie la > toponymie des lieux (place=*) en fonction du découpage adminsitratif (les > relations) et qui veut imposer les codes INSEE des relations aux noeuds > place et veut en supprimer d'autres, et qui aussi râle sur les différences > de chiffres de population entre la relation qu'il veut bien considérer (pas > la bonne) et celle indiquée dans le noeud place=* (qui correspond à la > population de la commune en général mais pas toujours et doit séparer les > populations des communes membres qui est elle auyssi parfaitement connue > par l'INSEE. > > Bref je suis totalement dans le cadre: la population. Qu'on veuille mettre > un admin_centre sur les communes nouvelles ou en fusion-association je veut > bien mais il doit s'agir du noeud de la commune membre ou est situié son > siège, et il n'a PAS à être nommé comme la commune nouvelle et la commune > nouvelle ne doit pas imposer sa population totale à une commune membre. > C'est totalement incohérent. > > > Le 24 novembre 2017 à 23:31, Gaël Simon <gael.simon...@gmail.com> a écrit > : > >> 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 <verd...@wanadoo.fr> 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 <cqu...@openstreetmap.fr> 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.openstr >>> eetmap.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=717 >>> 0&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 >>> 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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
