Juste une idée, comme ça: Il n'y a pas moyen avec votre outil de marquer les bâtiments importés avec un numéro de parcelle (par exemple le plus petit numéro de parcelle où il est construit), ou le numéro de rue dans une agglomération, et insérer cette référence dans un tag de suivi, afin de savoir qu'il a été rapproché avec le cadastre, et ensuite permettra de savoir ceux qui ont été modifiés ?
Cela soulagerait ensuite bien des comparaisons géomatiques hasardeuses et faciliterait aussi les synchronisations lors d'imports de nouveaux bâtis, tout comme de permettre aussi d'avoir un état statistique du bâti manquant ou à corriger/fusionner. On insère bien des références Insee et NUTS pour les relations de communes, départements, arrondissements, régions, ou des codes SIREN pour les relations des intercommunalités... Ce qui permet justement des rapprochements de fichiers plus faciles et moins d'erreurs (par exemple sur les graphies ou toponymes alternatifs ou ambigus) dès lors que les géolocalisations ne correspondent pas exactement (surtout quand une source utilise une précision différente dans les géométries de contours ou les centroïdes renseignés, ou parce que cette géométrie a évolué au cours du temps et que les données prennent en compte des dates de mise à jour différentes de cette géométrie). Le 10 février 2012 20:24, Jérôme Cornet <jer...@aldorande.net> a écrit : > Le 10 févr. 2012 à 17:44, Etienne Trimaille a écrit : > >> Bon, j'ai enfin pris le temps de retester cet outil ;-) >> >> Est-ce possible de prendre en compte les building=* en compte ? > > Ahem… je dois avouer piteusement en public que je n'avais pas connaissance de > ces variations sur tag building. Et donc… > les bâtiments qui sont en building=XX ou XX n'est pas yes sont complètement > ignorés de la comparaison! (arggggg) > >> Je ne comprends pas toujours le résultats : >> Avec building=apartements / train_station dans la base OSM, ton outils met >> le bati dans ok.osm. >> Avec building=supermarket dans OSM, ton outils met le bati dans nofusion.osm. > > En fait cela ne dépend pas du type de building… (vu que je ne reconnais que > building=yes). La différence > que tu as observé est liée probablement à une intersection avec un autre > polygone qui lui était taggé building=yes. > >> Je précise que pour les 2 types apartements et supermarket, les bâtiments >> sont exactements au même endroits entre les 2 fichiers OSM (courant.osm et >> cadastre.osm).Je ne pense pas que cela soit le bon résultat, non ? Ils >> devraient se trouver dans nofusion.osm ? > > Euh je ne comprend pas bien cette partie. Dans le cadastre on a uniquement du > building=yes non? > >> Et en théorie, si j'ai bien compris les différents fichiers : >> ok.osm, à importer car aucune intersection > > Oui, même si l'outil pouvant avoir des failles (comme nous venons juste de le > voir), il est bon de vérifier. > >> nofusion.osm, à importer après verif des petites intersections > > Exact > >> fusion.osm, à ne pas importer, car bati déjà présent dans la base > > Ben là ça dépend des opinions. Préfères-tu un bâtiment dessiné exactement > comme dans le cadastre, ou garder > quelque chose d'approximatif fait à la main, pas forcément au bon niveau de > détail? (je sais j'en ai fait nombre à la main > à la grande époque). Si tu souhaites avoir la précision du cadastre, et les > tags intéressants rentrés sur la version faite > à la main, le calque "Fusion" est censé réimporter les tags utilisateur sur > le bâti cadastre (et sur les points, notamment > pour les adresses). Après c'est une question d'opinion/de temps et aussi que > le processus de fusion se passe bien. > >> conflit.osm, à vérifier manuellement >> C'est bien çà ? > > Oui. > >> Pour obtenir les batiments qui ont été supprimés du cadastre, mais présent >> dans OSM ? > > Peut-être en inversant les deux fichiers en arguments (cadastre et calque > osm) et en regardant la sortie .ok. > Je peux faire une option spéciale sinon si tu m'expliques à quoi ça te sert, > quel comportement tu veux, etc. > >> Merci pour l'outil ;-) > > Merci pour le feedback, il n'y a que comme ça qu'on le fera progresser. > > La morale de l'histoire, c'est que comme toujours, il n'y a pas d'outils > automatiques, et bati-fusion est clairement un outil semi-automatique, > qui requiert un contrôle manuel. Ne pas faire confiance aveuglément, et ne > jamais importer un calque de sortie dans avoir préalablement > vérifié que tout allait bien (y compris sur le .ok). > > Sur le site github, il y a un "tracker" de bugs > (https://github.com/jecor/bati-fusion/issues). Il y a un autre problème qui a > été trouvé par un utilisateur > à notlm-grenoble: l'outil suppose qu'on a téléchargé toute la commune pour > le calque osm. Dans certaines zones denses, ça n'est pas toujours > possible…. dans ce cas il faut donc faire très gaffe avec les bâtiments > "hors-zone" qui sont tous marqués ok. > > Je m'en vais fixer les bugs au plus vite, > > Jérôme > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
