c'est quelle version de la BDCarthage qui est utilisée pour la comparaison ?
la dernière version officielle pour la france métropolitaine date de septembre 2013, elle est publiée sous la LO etalab et est accessible sur http://services.sandre.eaufrance.fr/telechargement/geo/BDCarthage/FXX/2013/arcgis/FranceEntiere/ Sylvain Le 4 février 2014 19:49, sly (sylvain letuffe) <lis...@letuffe.org> a écrit : > On mardi 4 février 2014, Ab_fab wrote: > > Bonjour, > > Hello, > > > J'ai fait une passe sur le rapport généré chaque jour pour comparer les > > longueurs entre la base Sandre et OSM [1]. > > Na de diou, quel rapport de bug complet et travaillé ! > J'ai pas trop le choix là, il va falloir que je regarde ;-) > > > 1. > Il faudrait voir si une autre source plus récente en provenance du sandre > pourrait > nous servir de base, et donc, améliorer la détection... > > > 2. Incohérence entre le nom dans OSM et celui de la base Sandre > > Cela ne devrait pas entrer en ligne de compte, la comparaison est faite > entre un fichier (ancien) en provenance du sandre uniquement sur la base > de la référence sandre : > > https://github.com/osm-fr/suivi-export/blob/master/longeur-cours-eau-france/suivi-cours-eau.php#L143 > > > 5. RAS > > La relation est-elle dans la base servant à générer le rapport ? > > J'ai bien l'impression que plusieurs fois ce n'est pas le cas. > > J'ai testé avec "le Clain" (ref = L2--0160) > osm=> select name from planet_osm_line where hstore(tags)->'ref:sandre' = > 'L2--0160'; > name > ------ > (0 ligne) > > Avec la Vilaine (J---006A) c'est bon par exemple > > En clair, il y a un problème de "fuite" dans l'import > Pour le clain, je viens de tenter un ré-import seulement pour cette > relation et ça s'importe correctement. > Donc... c'est pas les données ou en tout cas pas que. > Mais le processus de mise à jour ou osm2pgsql qui fait qu'a partir d'un > événement que je nommerais "x" par convention et aussi car j'ignore de > quoi il s'agit la géométrie de la > relation est jetée à la poubelle. > > J'ai suivi les fils dans tous les sens et je ne parviens pas à qualifier > "x" ni par une date ni par une autre caractéristique. > Je peux juste dire que la base d'osm13 n'est pas touchée par ce problème. > Je peux dire qu'aucune des géométries qui compose chaque chemin du Clain > n'est présente dans la base d'osm105 > La demande de reconstruction par un pending='t' de la géométrie de tous > les ways n'y change rien > > La piste la plus probable serait qu'il manque des noeud dans la base > locale (le fichier flat-nodes) mais je ne sais > pas comment l'interroger pour confirmer cela. > > La seule chose que je vois est donc une ré-importation complète de la base > -- > sly > qui suis-je : http://sly.letuffe.org > > _______________________________________________ > dev-fr mailing list > dev-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev-fr >
_______________________________________________ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
