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

2015-05-16 Par sujet sly (sylvain letuffe)
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 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 à jour vers Debian 8 j'ai des soucis de
  compilation, du coup j'utilise la version packagée dans Jessie cad SVN
  version 0.86.0 (64bit id space).
  
  
  
  
  ___
  dev-fr mailing list
  dev-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/dev-fr
  
  --
  sly
  
  ___
  dev-fr mailing list
  dev-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/dev-fr

-- 
sly (sylvain letuffe)

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

2015-05-16 Par sujet didier2020
j'ai bati un truc a partir de la requete de christian 
sur une base osmosis .

j'ai pas réussi a aggreger les communes - longueur du way dans la
commune.

Le samedi 16 mai 2015 à 11:42 +0200, Frédéric Rodrigo a écrit : 
 Le 15/05/2015 18:36, Christian Quest a écrit :
  Suite à cet échange et à une demande de didier2020, j'ai sorti un CSV
  des highway qui portent un nom et qui croisent plusieurs communes.
  Les motorway ont été retiré, et c'est trié par nombre de communes
  croisées, puis par kilométrage décroissant.
  La liste des codes INSEE des communes croisées est indiquée.
 
  C'est ici: http://osm105.openstreetmap.fr/~cquest/routes.csv
 
  A affiner pour une future analyse osmose ?
 
 Si vous avais une requête qui tourne sur base osmosis je prends.
 
 
 ___
 Talk-fr mailing list
 talk...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr



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


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

2015-05-16 Par sujet didier2020
c'est mieux avec la requete ...


Le samedi 16 mai 2015 à 16:25 +0200, didier2020 a écrit : 
 j'ai bati un truc a partir de la requete de christian 
 sur une base osmosis .
 
 j'ai pas réussi a aggreger les communes - longueur du way dans la
 commune.
 
 Le samedi 16 mai 2015 à 11:42 +0200, Frédéric Rodrigo a écrit : 
  Le 15/05/2015 18:36, Christian Quest a écrit :
   Suite à cet échange et à une demande de didier2020, j'ai sorti un CSV
   des highway qui portent un nom et qui croisent plusieurs communes.
   Les motorway ont été retiré, et c'est trié par nombre de communes
   croisées, puis par kilométrage décroissant.
   La liste des codes INSEE des communes croisées est indiquée.
  
   C'est ici: http://osm105.openstreetmap.fr/~cquest/routes.csv
  
   A affiner pour une future analyse osmose ?
  
  Si vous avais une requête qui tourne sur base osmosis je prends.
  
  
  ___
  Talk-fr mailing list
  talk...@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 

select 
 h.id,
 h.name as nameway,
 h.ref as refway,
 c.ref_insee as insee,
 ST_Length(st_intersection(c.polygon,h.wline),false)/1000 as km_in_com
from 
(
-- les ways qui ne sont pas des autoroutes, qui ont un tag name et qui sont  a 1km
select 
id,tags-'highway' as highway,tags-'name' as name,tags-'ref'as ref,linestring::geography as wline
from 
debugwithjosm.ways 
where
tags ? 'highway' and not tags-'highway' in ('proposed','motorway','trunk','motorway_link','trunk_link')
and tags ? 'name'
and ST_Length(linestring,false)/10001.00
) as h
join
(
-- les communes
SELECT
relations.id AS id,
relations.tags-'ref:INSEE' AS ref_insee,
ST_Polygonize(ways.linestring) AS polygon
FROM
debugwithjosm.relations
JOIN debugwithjosm.relation_members ON
relation_members.relation_id = relations.id AND
relation_members.member_type = 'W'
JOIN debugwithjosm.ways ON
ways.id = relation_members.member_id AND
ST_NPoints(ways.linestring)  1
WHERE
relations.tags?'type' AND
relations.tags-'type' = 'boundary' AND
relations.tags?'boundary' AND
relations.tags-'boundary' = 'administrative' AND
relations.tags?'admin_level' AND
relations.tags-'admin_level' = '8' and
relations.tags?'ref:INSEE'
GROUP BY
relations.id,
relations.tags-'ref:INSEE' ) as c
-- avec une intersection
on  st_intersects(c.polygon,h.wline)
where
--ST_Length(st_intersection(c.polygon,h.wline),false)/10001.0 and
-- la taille de l'intersection par rapport a la longueur de la voie est significative
ST_Length(st_intersection(c.polygon,h.wline),false)/ST_Length(h.wline)0.20
;
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr


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

2015-05-16 Par sujet Frédéric Rodrigo

Salut,

Voilà ce que j'en ai fait, regarde un peut les résultats et si tu peux 
l'améliorer. Il y a un bug avec les voies qui reviennent dans la commune 
d'origine, à voir si c'est est acceptable.


SELECT
  id
FROM
(
SELECT
  highway.id,
  highway.linestring,
  ST_ClosestPoint(highway.linestring, ST_Intersection(admin.linestring, 
highway.linestring)) AS intersection

FROM
  relations
  JOIN relation_members ON
relation_members.relation_id = relations.id AND
relation_members.member_type = 'W'
  JOIN ways AS admin ON
admin.id = relation_members.member_id AND
ST_NPoints(admin.linestring)  1
  JOIN ways AS highway ON
-- les ways qui ne sont pas des autoroutes, qui ont un tag name et 
qui sont  a 1km

highway.tags?'highway' AND
NOT highway.tags-'highway' IN ('proposed', 'motorway', 'trunk', 
'motorway_link', 'trunk_link') AND

highway.tags?'name' AND
ST_Length(highway.linestring, false)  1000 AND
ST_NPoints(highway.linestring)  1 AND
-- avec une intersection
ST_Intersects(admin.linestring, highway.linestring)
WHERE
relations.tags?'type' AND
relations.tags-'type' = 'boundary' AND
relations.tags?'boundary' AND
relations.tags-'boundary' = 'administrative' AND
relations.tags?'admin_level' AND
relations.tags-'admin_level' = '8' AND
relations.tags?'ref:INSEE'
) AS t
WHERE
  -- la taille de l'intersection par rapport a la longueur de la voie 
est significative

  ST_Line_Locate_Point(linestring, intersection)  0.1 AND
  ST_Line_Locate_Point(linestring, intersection)  0.9
;



Le 16/05/2015 16:26, didier2020 a écrit :

c'est mieux avec la requete ...


Le samedi 16 mai 2015 à 16:25 +0200, didier2020 a écrit :

j'ai bati un truc a partir de la requete de christian
sur une base osmosis .

j'ai pas réussi a aggreger les communes - longueur du way dans la
commune.

Le samedi 16 mai 2015 à 11:42 +0200, Frédéric Rodrigo a écrit :

Le 15/05/2015 18:36, Christian Quest a écrit :

Suite à cet échange et à une demande de didier2020, j'ai sorti un CSV
des highway qui portent un nom et qui croisent plusieurs communes.
Les motorway ont été retiré, et c'est trié par nombre de communes
croisées, puis par kilométrage décroissant.
La liste des codes INSEE des communes croisées est indiquée.

C'est ici: http://osm105.openstreetmap.fr/~cquest/routes.csv

A affiner pour une future analyse osmose ?


Si vous avais une requête qui tourne sur base osmosis je prends.


___
Talk-fr mailing list
talk...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-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-16 Par sujet Vincent Frison
Merci pour vos retours..

Sly pourquoi ne mettre qu'un seul processs ? 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 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 à jour vers Debian 8 j'ai des soucis de
 compilation, du coup j'utilise la version packagée dans Jessie cad SVN
 version 0.86.0 (64bit id space).
 
 
 
 
 ___
 dev-fr mailing list
 dev-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/dev-fr

 --
 sly

 ___
 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-16 Par sujet didier2020
j'ai exactement eu ce genre de soucis, j'ai resolu de façon empirique ne
connaissant pas le sujet.

comme ca marchait pas, j'ai essayé avec l'extract de la corse
(tout petit ca devait marcher...) en mode slim sans number-processes

j'ai corrigé suivant les msg erreur par recherche internet
http://wiki.openstreetmap.org/wiki/Osm2pgsql#Optimization
http://wiki.openstreetmap.org/wiki/PostgreSQL#Tune_the_database
... et d'autres dont je n'ai pas gardé de liens

2 eme etape, controle de l'utilisation des ressources avec le moniteur
systeme (memoire, swap et taille disque utilisé) et du log postgresql

modification des parametres postgresql pour voir ce que ca fait et si
cela utilise plus ou moins de ressources.

ca a ete laborieux

Le vendredi 15 mai 2015 à 23:50 +0200, Vincent Frison 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 à jour vers Debian 8 j'ai des soucis de
 compilation, du coup j'utilise la version packagée dans Jessie cad SVN
 version 0.86.0 (64bit id space).
 
 
 
 
 ___
 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-16 Par sujet sly (sylvain letuffe)


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 à jour vers Debian 8 j'ai des soucis de
compilation, du coup j'utilise la version packagée dans Jessie cad SVN
version 0.86.0 (64bit id space).




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

-- 
sly

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