Re: [OSM-dev-fr] requete pour trouver un way qui intersecte plusieurs communes
deja merci :)
j'ai ajouté
group by id a la fin
highway=raceway a filter
j'ai fais plusieurs test locaux, les id retournés sont tous bien a
corriger.
j'ai lancé 2 analyses osmose sur le nord_pas_de_calais (dept ou il y a
le plus de commune concernés) avec les 2 requetes.
j'analyserais demain ...
Le samedi 16 mai 2015 à 20:13 +0200, Frédéric Rodrigo a écrit :
> 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
___
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
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
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) 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 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.or
Re: [OSM-dev-fr] requete pour trouver un way qui intersecte plusieurs communes
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)/1000>1.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)/1000>1.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
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
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) 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 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
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 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
Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS
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
