[OSM-dev-fr] [OSM-talk-fr] problème overpass-api et area-query sur une relation

[sly (sylvain letuffe)]

(Je bascule sur dev-fr, talk-fr est déjà très largement sur-chargée, et ce fil 
de discussion me semble assez technique)

Le vendredi 04 janvier 2013 15:41:59, Cyrille Giquello a écrit :
> Le 4 janvier 2013 15:33, Christian Quest <cquest at openstreetmap.fr> a écrit :
> > Je ne sais pas si c'est cette requête pour maintenir les area à jour
> > qui est lourde où si ce sont celles les utilisant ensuite sur
> > l'overpass...
> 
> C'est surtout leur génération qui est lourde, me semble-t-il.

C'est en effet leur génération qui est lourde, je n'ai pas encore regardé en 
détail comment ça fonctionne, mais ça fout un CPU à 100% en permanence et ça 
bouffe du disque.

Alors que personne ne savait que j'avais glissé en test les calculs des areas 
sur oapi-fr.openstreetmap.fr la machine perdait terriblement en rapidité pour 
les autres requêtes.
Roland ma conseillé de lui attribué une priorité plus faible (nice) mais ça ne 
résout que le problème CPU, pas le problème i/o
Je vais faire des tests avec ionice, mais le coeur du problème restant bien 
évidement que ça ne devrait pas bouffer à ce point.


> > C'est vrai aussi qu'à un moment passer à postgis offre un autre champ
> > de possibilités, il faudrait ajouter un moyen de requêter postgis via
> > HTTP pour une exploitation dans les slippymaps.

Tiens, ça me rappel un conseil que j'ai donné récemment sur [tech] ;-)

> Ça risque d'être encore plus chaud : très facile de saturer le serveur
> puisque l'on pourrait tout lui demander tout le temps.

Oui mais ça ressemble au même problème avec l'overpass. Si on veut le faire, à 
nous de trouver une méthode permettant de terminer les requêtes trop longues 
et d'avoir une règle d'utilisation et des restrictions. 

 
> L'overpass-API c'est super bien:
> - un type de requêtes largement suffisant
oui

> - une construction des données optimisées pour le type de requête
Oui, sauf les areas ;-)

> - un service qui tient la route
Oui bon ça, ça se discute ;-) mais les choses s'améliorent

 
> L'option de limite des requête sur un polygone est vraiment super,
> même si limitée à un type de données. Et en plus ce filtrage est
> négociable ;-)

Ou alors, mais ça devient délicat, se goupiller un couplage 
postGIS(osm2pgsql)/overpass(ou osmbin) pour obtenir le meilleur des deux 
mondes.

Mais c'est de loin plus facile à dire qu'a faire.


-- 
sly (sylvain letuffe)