Re: [OSM-dev-fr] requete pour trouver un way qui intersecte plusieurs communes

2015-05-18 Par sujet didier2020

aprés avoir corrigé un bon nombre de détection,
je ne pense pas que cela soit la géométrie de l'intersection 
qui importe, mais plutôt la nature de la voie :

J'ai remarqué que les intersections complexes sont plus liés 
aux écarts entre le tracé Bing vs tracé cadastre .

Faire une analyse sans faux positifs grace au premier mot du name :
upper(split_part(tag-'name',' ', 1) in () 

Toujours a corriger
Rue , Place, Impasse

Mitigé :
Avenue - Allée (dans les forets)

Faux positifs :
Route 
Chemin
Chaussée

Le lundi 18 mai 2015 à 21:54 +0200, Frédéric Rodrigo a écrit : 
 Le 17/05/2015 11:08, didier2020 a écrit :
  1)
  colonne intersectioncomplexe ajoutée
  ( a prioris il y aura plus de faux positif si .t.)
  voir id=153318806 ou id=111737255
 
 Pour osmose, on prend ou on prend pas ?
 
 
on prend tout, le critere etant ailleur. 
 ___
 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] Chargement de toute la France dans PostGIS

2015-05-18 Par sujet Vincent Frison
Mon dernier essai s'est bloqué au bout de ~1,5j à cause... d'un problème
d'espace disque ! :)

Bon là je retente sur une autre partition avec plus de 250 GB d'espace
libre et avec cette option flat-nodes qui a l'air sympathique
effectivement. Je met également 2 processes et soyons fou 2 Gb de cache car
avec un seul GB et un seul process c'était un peu trop pépére même pour mon
vieux laptop (seulement 1/4 du CPU et 2,8 Gb utilisé par osm2pgsql)

Le 18 mai 2015 09:30, Christian Quest cqu...@openstreetmap.fr a écrit :

 --slim obligatoire pour ne pas être en out of memory
 --flat-nodes obligatoires aussi...

 Pour descendre le temps d'import, le plus efficace c'est le SSD.

 Un peu de tuning postgres peut aider aussi, mais c'est une science occulte
 !

 Voilà un exemple d'import France sur une machine avec 8Go et 4 coeurs (et
 1 SSD):
 http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks/LS21_Blade_with_SSD



 Le 16 mai 2015 16:38, sly (sylvain letuffe) lis...@letuffe.org a écrit :

 Le samedi 16 mai 2015 14:09:01, Vincent Frison a écrit :
  Merci pour vos retours..
 
  Sly pourquoi ne mettre qu'un seul processs ?

 J'ignore si c'est toujours le cas, mais il fût un temps, quand on
 choisissait
 multiple processus avec osm2pgsql, il consommait plus de mémoire sur la
 partie
 création des polygones de relation.
 Comme de toute façon, ta ressource limitante sera, de très loin, le disque
 très lent de ton portable (sauf ssd ?). Il faut laisser au maximum
 possible de
 mémoire au kernel linux pour qu'il puisse mettre le plus de chose en
 cache RAM
 possible. Et accessoirement fermer le plus grand nombre d'autres
 applications
 possible.

 Mais si tu as le courage, tu peux tenter avec 4 puis 1 processus. Ça nous
 permettra de savoir ce qui est le plus rentable dans un config avec
 mémoire
 limitée.


  Je crois que mon processeur
  est un double cœur mais concrètement ça en fait 4 (à cause de
  l'hyperthreading?), en tout je vois 4 processeurs en faisant un cat
  /proc/cpuinfo.
 
  Sinon ok je me suis rajouté 12 GB de swap et je vais refaire une
 tentative
  cette nuit en mettant la cache à seulement 1GB car effectivement ce
  paramètre ne concerne que la cache et il faut bien garder un peu de
 mémoire
  pour le reste...
 
  Le 16 mai 2015 13:31, sly (sylvain letuffe) lis...@letuffe.org a
 écrit :
   J'importe l'europe sur une machine avec 16go et 4 disques raid
 rotatifs
   en 5jours. Je pense que ca devrait le faire pour ta config sur la
 france
   uniquement avec de la patience.
  
   Pour 8go de ram, ce qui est peu n'active pas autant de cache avec -C
   sinon il n'en reste pas assez pour les autres traitements.
   Selon moi :
   --slim obligé
   -C 800
   --number-process=1
   Et ajoute au moins 4 voir 8go de swap
  
   Et arme toi de patience. Vu ta config, je tablerais sur 72h voir plus
   Sinon, importe sur une autre machine et dump puis restore
  
   Le 15 mai 2015 23:50:12 CEST, Vincent Frison 
 vincent.fri...@gmail.com a
  
   écrit :
   Hello,
   
   J'aimerais avoir un peu de retour d'expérience si certains parmi vous
   se
   sont déjà amusé à charger l'ensemble de la France dans une base
   PostGIS.
   
   En sachant que dans mon cas ça serait un vieux laptop avec Corei5@2
 ,4
   GHz
   et simplement 8 GB de RAM. Peut-être que je rêve en couleur avec une
   configuration aussi limitée, en tout cas c'est pas grave si ça prend
   plusieurs jours à charger...
   
   J'ai donc essayé de charger le fichier PBF, 3 GB tout de même, mais
   pour
   l'instant c'est un échec.
   
   J'ai d'abord essayé sans l'option --slim mais ça a crashé au bout de
   plus
   de 24h (je n'ai plus le message d'erreur exact malheureusement).
   
   Ma dernière tentative avec plus de cache (osmpgsql -s -c -C 5000
   --number-processes=3) n'a pas vraiment planté mais ça a quand même
   joliment
   foiré puisque je me retrouve qu'avec 160k ways au lieu des 48M
   visiblement
   prévus.
   
   Voici les logs:
   
   Using projection SRS 900913 (Spherical Mercator)
   [...]
   Using built-in tag processing pipeline
   Allocating memory for dense node cache
   Allocating dense node cache in one big chunk
   Allocating memory for sparse node cache
   Sharing dense sparse
   Node-cache: cache=5000MB, maxblocks=64*8192, allocation method=11
   Mid: pgsql, scale=100 cache=5000
   Setting up table: planet_osm_nodes
   
   Reading in file:
   /home/turman/Temporary/GeoData/OSM/france-latest.osm.pbf
   Processing: Node(328394k 132.7k/s) Way(48772k 38.71k/s)
 Relation(382850
   24.75/s)  parse time: 19203s
   
   Node stats: total(328394512), max(3511063881) in 2475s
   Way stats: total(48772758), max(344356113) in 1260s
   Relation stats: total(382854), max(5126005) in 15469s
   Committing transaction for planet_osm_point
   Committing transaction for planet_osm_line
   Committing transaction for planet_osm_polygon
   Committing transaction for planet_osm_roads
   
   Going over pending ways...
   pending_ways failed: out of 

Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS

2015-05-18 Par sujet Christian Quest
--slim obligatoire pour ne pas être en out of memory
--flat-nodes obligatoires aussi...

Pour descendre le temps d'import, le plus efficace c'est le SSD.

Un peu de tuning postgres peut aider aussi, mais c'est une science occulte !

Voilà un exemple d'import France sur une machine avec 8Go et 4 coeurs (et 1
SSD):
http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks/LS21_Blade_with_SSD



Le 16 mai 2015 16:38, sly (sylvain letuffe) lis...@letuffe.org a écrit :

 Le samedi 16 mai 2015 14:09:01, Vincent Frison a écrit :
  Merci pour vos retours..
 
  Sly pourquoi ne mettre qu'un seul processs ?

 J'ignore si c'est toujours le cas, mais il fût un temps, quand on
 choisissait
 multiple processus avec osm2pgsql, il consommait plus de mémoire sur la
 partie
 création des polygones de relation.
 Comme de toute façon, ta ressource limitante sera, de très loin, le disque
 très lent de ton portable (sauf ssd ?). Il faut laisser au maximum
 possible de
 mémoire au kernel linux pour qu'il puisse mettre le plus de chose en cache
 RAM
 possible. Et accessoirement fermer le plus grand nombre d'autres
 applications
 possible.

 Mais si tu as le courage, tu peux tenter avec 4 puis 1 processus. Ça nous
 permettra de savoir ce qui est le plus rentable dans un config avec mémoire
 limitée.


  Je crois que mon processeur
  est un double coeur mais concrètement ça en fait 4 (à cause de
  l'hyperthreading?), en tout je vois 4 processeurs en faisant un cat
  /proc/cpuinfo.
 
  Sinon ok je me suis rajouté 12 GB de swap et je vais refaire une
 tentative
  cette nuit en mettant la cache à seulement 1GB car effectivement ce
  paramètre ne concerne que la cache et il faut bien garder un peu de
 mémoire
  pour le reste...
 
  Le 16 mai 2015 13:31, sly (sylvain letuffe) lis...@letuffe.org a
 écrit :
   J'importe l'europe sur une machine avec 16go et 4 disques raid rotatifs
   en 5jours. Je pense que ca devrait le faire pour ta config sur la
 france
   uniquement avec de la patience.
  
   Pour 8go de ram, ce qui est peu n'active pas autant de cache avec -C
   sinon il n'en reste pas assez pour les autres traitements.
   Selon moi :
   --slim obligé
   -C 800
   --number-process=1
   Et ajoute au moins 4 voir 8go de swap
  
   Et arme toi de patience. Vu ta config, je tablerais sur 72h voir plus
   Sinon, importe sur une autre machine et dump puis restore
  
   Le 15 mai 2015 23:50:12 CEST, Vincent Frison vincent.fri...@gmail.com
 a
  
   écrit :
   Hello,
   
   J'aimerais avoir un peu de retour d'expérience si certains parmi vous
   se
   sont déjà amusé à charger l'ensemble de la France dans une base
   PostGIS.
   
   En sachant que dans mon cas ça serait un vieux laptop avec Corei5@2,4
   GHz
   et simplement 8 GB de RAM. Peut-être que je rêve en couleur avec une
   configuration aussi limitée, en tout cas c'est pas grave si ça prend
   plusieurs jours à charger...
   
   J'ai donc essayé de charger le fichier PBF, 3 GB tout de même, mais
   pour
   l'instant c'est un échec.
   
   J'ai d'abord essayé sans l'option --slim mais ça a crashé au bout de
   plus
   de 24h (je n'ai plus le message d'erreur exact malheureusement).
   
   Ma dernière tentative avec plus de cache (osmpgsql -s -c -C 5000
   --number-processes=3) n'a pas vraiment planté mais ça a quand même
   joliment
   foiré puisque je me retrouve qu'avec 160k ways au lieu des 48M
   visiblement
   prévus.
   
   Voici les logs:
   
   Using projection SRS 900913 (Spherical Mercator)
   [...]
   Using built-in tag processing pipeline
   Allocating memory for dense node cache
   Allocating dense node cache in one big chunk
   Allocating memory for sparse node cache
   Sharing dense sparse
   Node-cache: cache=5000MB, maxblocks=64*8192, allocation method=11
   Mid: pgsql, scale=100 cache=5000
   Setting up table: planet_osm_nodes
   
   Reading in file:
   /home/turman/Temporary/GeoData/OSM/france-latest.osm.pbf
   Processing: Node(328394k 132.7k/s) Way(48772k 38.71k/s)
 Relation(382850
   24.75/s)  parse time: 19203s
   
   Node stats: total(328394512), max(3511063881) in 2475s
   Way stats: total(48772758), max(344356113) in 1260s
   Relation stats: total(382854), max(5126005) in 15469s
   Committing transaction for planet_osm_point
   Committing transaction for planet_osm_line
   Committing transaction for planet_osm_polygon
   Committing transaction for planet_osm_roads
   
   Going over pending ways...
   pending_ways failed: out of memory for query result
   (7)
   Error occurred, cleaning up
   
   Au vu du message d'erreur, dois je augmenter la taille du cache ?
   Malheureusement je suis déjà pas très loin de ma limite physique, mais
   je
   pourrais me créer un swap.. swap que je n'ai pas actuellement, d'où
   peut-être mes problèmes d'ailleurs !
   
   Bref si vous avez des conseils ou des bonnes options je suis preneur.
   
   Merci, Vincent.
   
   PS: j'utilisais avant une version bien à jour d'osm2pgsql compilée
   depuis
   Git mais depuis ma mise à