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

2014-02-17 Par sujet sly (sylvain letuffe)
On jeudi 6 février 2014, sly (sylvain letuffe) wrote:

 ps: je vais sans doute faire un ré-import total de la base, et à partir de
 là, 
 il faudra ouvrir l'oeil afin de voir à partir de quand ça déconne, sur quel 
 rivière et voir si une édition en particulier aurait pu être le déclencheur.
 Je remettrais un mail pour dire quand c'est fait et si c'est fait.

J'ai donc ré-importé toute la base, et un calcul a été refait hier soir (un 
autre devrait survenir ce soir 19h00)

Le résultat n'est pas glorieux :
http://suivi.openstreetmap.fr/longeur-cours-eau-france/comparaison-sandre.html

C'est pas autant troué que la dernière fois, mais ça l'est déjà quand même
(par exemple Le Lot, mais bien d'autre encore)

Mais j'ai mal géré mon histoire, j'ai relancé les mises à jour tout de suite 
après l'import, ce qui fait que je n'ai pas laissé le temps de voir si le 
problème était déjà là à la fin de l'import, où s'il était lié au mise à jour 
ultérieures.
Coté des limites administratives, qui manquaient, elles aussi en nombre dans 
cette base, tout semble s'être réparé :
http://suivi.openstreetmap.fr/communes/communes.csv.txt



-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr


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

2014-02-17 Par sujet sly (sylvain letuffe)
On lundi 17 février 2014, Sylvain Maillard wrote:
 Salut,

hello,

 les trous dont tu parles, c'est tous le bas de la liste des cours d'eau
 qui aparaissent en 0% ?

Et qui sont véritablement dans osm.
Il en existe qui ne sont pas dans osm et eux, c'est normal qu'ils soient 
listés à 0%, mais il y en a plein qui ne devraient pas être à 0%.

Je viens de tenter une opération, on va voir ce soir si le calcul arrive à 
combler quelques trous...

 il y a sans doute quelques améliorations qui pourraient être faites:

Ça ! Les idées d'améliorations ne manquent pas, mais je vais déjà tenter de le 
faire marcher tout court, et ça sera déjà pas mal.
Bien sûr, si quelqu'un voit en cet outil un bon potentiel et a envie de 
rajouter des fonctions, c'est avec plaisir !

 - on a 156% du Rhône, mais parce que la relation osm part de la source du
 Rhône en suisse. Est-ce qu'il serait possible de ne pas prendre en compte
 les tronçons hors de france ? (même chose pour le Rhin: 690% !)
 
 
 
 Sylvain
 
 
 
 
 Le 17 février 2014 15:05, sly (sylvain letuffe) lis...@letuffe.org a
 écrit :
 
   On jeudi 6 février 2014, sly (sylvain letuffe) wrote:
 
 
 
   ps: je vais sans doute faire un ré-import total de la base, et à partir
  de
 
   là,
 
   il faudra ouvrir l'oeil afin de voir à partir de quand ça déconne, sur
  quel
 
   rivière et voir si une édition en particulier aurait pu être le
  déclencheur.
 
   Je remettrais un mail pour dire quand c'est fait et si c'est fait.
 
 
 
  J'ai donc ré-importé toute la base, et un calcul a été refait hier soir
  (un autre devrait survenir ce soir 19h00)
 
 
 
  Le résultat n'est pas glorieux :
 
 
  http://suivi.openstreetmap.fr/longeur-cours-eau-france/comparaison-
sandre.html
 
 
 
  C'est pas autant troué que la dernière fois, mais ça l'est déjà quand même
 
  (par exemple Le Lot, mais bien d'autre encore)
 
 
 
  Mais j'ai mal géré mon histoire, j'ai relancé les mises à jour tout de
  suite après l'import, ce qui fait que je n'ai pas laissé le temps de voir
  si le problème était déjà là à la fin de l'import, où s'il était lié au
  mise à jour ultérieures.
 
  Coté des limites administratives, qui manquaient, elles aussi en nombre
  dans cette base, tout semble s'être réparé :
 
  http://suivi.openstreetmap.fr/communes/communes.csv.txt
 
 
 
 
 
 
 
  --
 
  sly
 
  qui suis-je : http://sly.letuffe.org
 
 
 
  ___
  dev-fr mailing list
  dev-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/dev-fr
 
 
 


-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr


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

2014-02-06 Par sujet Frédéric Rodrigo

Le 05/02/2014 23:35, sly (sylvain letuffe) a écrit :

Le mercredi 5 février 2014 10:20:03, Sylvain Maillard a écrit :

c'est quelle version de la BDCarthage qui est utilisée pour la comparaison
?


Et bien je ne me rappel plus précisément où j'ai récupéré ça, je peux juste
dire que ça a environ 2ans et il me semble, mais sans certitudes, que c'était
dispo sur le site du sandre.

Quoi qu'il en soit, la longeur des cours d'eau n'ayant pas vraiment changé en
2 ans, je suppose que la fraicheur de ma source n'est pas la priorité sur
laquelle je dois travailler, mais plutôt tenter de voir pourquoi des données
disparaissent de la copie de la base.

Si vraiment je constate trop de numéro de référence sandre qui ont changée, je
m'occuperais alors de comparer avec une source plus récente (mais ça oblige de
regarder comment elle est faite, l'importer, la vérifier, enfin bref, un peu
de boulot quoi)




Le révérenciel sandre était déjà disponible, c'est la disponibilité de 
la géométrie qui est ressente.


Frédéric.


___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr


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

2014-02-06 Par sujet Sylvain Maillard
oui, sur le site du sandre c'est bien la BDCarthage, elle était sous
licence CC depuis Déjà 5 ans ;)
la structure des fichiers n'a pas bougé, tu devrais pouvoir faire la mise à
jour simplement en copiant le nouveau fichier à la place de l'ancien ...

les géométries ont peu changé, comme tu le dis ça ne devrais pas modifier
radicalement la longueur des cours d'eau, c'est surtout les corrections et
modifications apportées aux attributs (comme le nom) peuvent changer des
choses au niveau de la comparaison des jeux de données !

Mais c'est certain qu'il est plus important de comprendre d'où proviennent
ces disparitions de données avant de s'attaquer à une mise à jour, ne
serait-ce que pour ne pas refaire le travail 2 fois ;)


Sylvain



Le 6 février 2014 09:45, Frédéric Rodrigo fred.rodr...@gmail.com a écrit :

 Le 05/02/2014 23:35, sly (sylvain letuffe) a écrit :

  Le mercredi 5 février 2014 10:20:03, Sylvain Maillard a écrit :

 c'est quelle version de la BDCarthage qui est utilisée pour la
 comparaison
 ?


 Et bien je ne me rappel plus précisément où j'ai récupéré ça, je peux
 juste
 dire que ça a environ 2ans et il me semble, mais sans certitudes, que
 c'était
 dispo sur le site du sandre.

 Quoi qu'il en soit, la longeur des cours d'eau n'ayant pas vraiment
 changé en
 2 ans, je suppose que la fraicheur de ma source n'est pas la priorité sur
 laquelle je dois travailler, mais plutôt tenter de voir pourquoi des
 données
 disparaissent de la copie de la base.

 Si vraiment je constate trop de numéro de référence sandre qui ont
 changée, je
 m'occuperais alors de comparer avec une source plus récente (mais ça
 oblige de
 regarder comment elle est faite, l'importer, la vérifier, enfin bref, un
 peu
 de boulot quoi)



 Le révérenciel sandre était déjà disponible, c'est la disponibilité de la
 géométrie qui est ressente.

 Frédéric.



 ___
 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


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

2014-02-06 Par sujet Ab_fab
Bonjour,

Merci de t'être penché sur la question

Je ne suis pas compétent pour trouver la cause, mais il y a quelque chose
de plutôt instable.
Le rapport généré
hierhttp://suivi.openstreetmap.fr/longeur-cours-eau-france/comparaison-sandre.htmllaisse
penser à des défauts pour la Loire et la Meuse.
Est-ce qu'il y a eu une intervention sur la base concernée ?

J'ai le souvenir que Jocelyn avait fait des imports individuels de cours
d'eau. Donc c'est pas la première fois que cela est nécessaire.
Je peux me tromper, mais je crois que quand OSM7 a été relancé à l'automne,
c'était avec une base neuve mais sans les ajustements de schéma concernant
les cours d'eau. Est-ce que c'est à cette occasion que cela part du mauvais
pied ?

---

Sur la même thématique cours d'eau mais sans rapport techniquement, je me
suis lancé dans l'utilisation de l'outil permettant de construire et
visualiser les bassins versants http://www.kompf.de/gps/rivermap.html.

Je suis arrivé à mes fins avec l'extrait Geofabrik allemand (création d'un
shapefile).
Je dois faire les ajustements pour mettre en pratique sur l'extrait
français.
A savoir référencer le way
osmhttps://docs.google.com/spreadsheet/ccc?key=0Am2C-mKrfBx4dGFZRTlLVC1ybURBQ0xyX29OWE5fa2cusp=drive_web#gid=0partant
de la source des fleuves dans
ce 
fichierhttps://github.com/skaringa/rivers/blob/master/src/com/skaringa/riversystem/WellknownRivers.javadu
code.

Il faut également référencer les ways de partage des eaux pour les canaux
reliant deux bassins versants.
J'en connais quelques un, mais s'il existe une liste exhaustive ou pas
loin, je prends.

@+

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 ;-)

 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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus, Nadja
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr


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

2014-02-06 Par sujet sly (sylvain letuffe)
On jeudi 6 février 2014, Ab_fab wrote:
 hierhttp://suivi.openstreetmap.fr/longeur-cours-eau-france/comparaison-
 sandre.htmllaisse
 penser à des défauts pour la Loire et la Meuse.
 Est-ce qu'il y a eu une intervention sur la base concernée ?

Pas de ma part en tout cas, et en effet, c'est assez étrange, mais ça 
ressemble à une perte d'info à nouveau pour ces 2 fleuve/rivière


 J'ai le souvenir que Jocelyn avait fait des imports individuels de cours
 d'eau. Donc c'est pas la première fois que cela est nécessaire.
 Je peux me tromper, mais je crois que quand OSM7 a été relancé à l'automne,
 c'était avec une base neuve mais sans les ajustements de schéma concernant
 les cours d'eau. Est-ce que c'est à cette occasion que cela part du mauvais
 pied ?

Oui, c'est pas impossible que ça puisse avoir un lien, nous n'utilisons plus 
tout à fait la même méthode qu'avant pour construire les relations 
type=waterway
Bien que les tests semblaient bon, il est possible que la procédure de mise à 
jour déconne et soit la cause de la disparition progressive de cette liste.

Je vais en causer avec jocelyn pour voir s'il a une idée.

ps: je vais sans doute faire un ré-import total de la base, et à partir de là, 
il faudra ouvrir l'oeil afin de voir à partir de quand ça déconne, sur quel 
rivière et voir si une édition en particulier aurait pu être le déclencheur.
Je remettrais un mail pour dire quand c'est fait et si c'est fait.

-- 
sly
qui suis-je : http://sly.letuffe.org

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr


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

2014-02-05 Par sujet 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.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


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

2014-02-05 Par sujet sly (sylvain letuffe)
Le mercredi 5 février 2014 10:20:03, Sylvain Maillard a écrit :
 c'est quelle version de la BDCarthage qui est utilisée pour la comparaison
 ?

Et bien je ne me rappel plus précisément où j'ai récupéré ça, je peux juste 
dire que ça a environ 2ans et il me semble, mais sans certitudes, que c'était 
dispo sur le site du sandre.

Quoi qu'il en soit, la longeur des cours d'eau n'ayant pas vraiment changé en 
2 ans, je suppose que la fraicheur de ma source n'est pas la priorité sur 
laquelle je dois travailler, mais plutôt tenter de voir pourquoi des données 
disparaissent de la copie de la base.

Si vraiment je constate trop de numéro de référence sandre qui ont changée, je 
m'occuperais alors de comparer avec une source plus récente (mais ça oblige de 
regarder comment elle est faite, l'importer, la vérifier, enfin bref, un peu 
de boulot quoi)


-- 
sly (sylvain letuffe)
http://wiki.openstreetmap.org/wiki/User:Sletuffe

___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr


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

2014-02-04 Par sujet sly (sylvain letuffe)
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