Re: [OSM-dev-fr] Wikipedia Maps in Lyon hackathon

[Christian Quest]

Too bad I can't be there in Lyon.

We would really like to setup a vector based rendering stack on OSM-FR
servers... so if you have some time to help us start the right way, it
would really help.

I hope you'll meet some of the Lyon OSM community... have a nice time in
Lyon

2015-05-19 0:42 GMT+02:00 Yuri Astrakhan :

> Hi, there is a Wikipedia hackathon
>  happening this
> weekend in Lyon, FR. I am one of the two engineers working on brining OSM
> maps to Wikipedia. We have built a Mapbox vector-based prototype, and would
> love to work with the community to make this project a success in
> production.
>
> Is there anyone who wants to work with us, who would like to come to Lyon
> over the weekend, please ping me directly.
>
> Thanks!
>
> --Yuri Astrakhan (user:yurik)
> WMF
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
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

[Christian Quest]

Il a peut être manqué la phase finale d'optimisation et de reclustering des
données.

Le 21 mai 2015 22:05, Vincent Frison  a écrit :

> Hier soir au bout d'environ 48h ça n'était toujours pas fini mais c'était
> sans doute pas très loin puisqu'il avait visiblement fini d'indexer toutes
> les tables. Je suis allé me coucher mais pas de bol il y a eu une coupure
> de courant durant la nuit, décidément...
>
> J'ai quand même l'impression que ça avait bien fini.. au final j'ai une
> base qui pèse 76 Gb et il y a 43 094 761 lignes dans la table
> planet_osm_polygon, si quelqu'un pouvait confirmer...
>
> En tout cas les indexes sur les géométries font bien leur boulot puisque
> les requêtes les utilisant sont aussi rapides que lorsque j'utilisais des
> bases avec une seule région ! :)
>
>
> Le 18 mai 2015 22:48, Vincent Frison  a écrit :
>
>> 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  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)  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)  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 m

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

[didier2020]

-l'analyse n'est pas du tout internationale, plutot "pointue" mais avec
peu de faux positif (pour ce que j'ai corrigé jusqu'a maintenant)
- il vaux mieux prendre des way qui sont longs, je pense que pour les
plus petits, d'autres analyses serait plus pertinente ou aurait le meme
effet de correction
(point adresse eloigné du way, associated street sans tag complémentaire
"xx:left ou xx:right dont le way est sur plusieurs commune,
analyse/verification de bano ou autre ?)

select 
t.id,
-- a adapter a osmose
ST_AsText(ST_Centroid(t.linestring))
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
 -- way qui sont > a 2km et
 -- qui ont le debut du name qui commence par "RUE" et certain type
de highway
 -- OU qui ont un code fantoir (avec ou sans name)
 highway.tags?'highway' AND
 (
   (
   highway.tags->'highway' IN
('primary','secondary','primary_link','secondary_link','tertiary','tertiary_link',
 'residential', 'unclassified', 'service', 'road') and
   highway.tags?'name' AND
   upper(left(highway.tags->'name',3))='RUE'
   )
   or highway.tags ? 'ref:FR:FANTOIR' 
 ) and
 ST_Length(highway.linestring, false) > 2000 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
group by 1,2
;


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