[OSM-dev-fr] Fichier comparaison cours d'eau

[Christian Quest]

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.maillard at 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) <liste2 at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>>
>
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at 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 à
Paris<http://openstreetmap.fr/sotmfr>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140205/25092b72/attachment-0001.html>