Je ne pense pas que sly utilise la BDCarthage, car ces comparaisons
existent depuis bien plus longtemps que la mise en opendata de la
BDCarthage.
L'occasion peut être de changer de source pour la comparaison.
Le 5 février 2014 10:20, Sylvain Maillard sylvain.maill...@gmail.com a
écrit :
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
--
Christian Quest - OpenStreetMap France
Conférence State Of The Map France du 4 au 6 avril à
Parishttp://openstreetmap.fr/sotmfr
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr
