[OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

[Christian Quest]

Le 22/07/2017 à 21:26, marc marc a écrit :
> Le 22. 07. 17 à 20:55, François Lacombe a écrit :
>> Le 22 juil. 2017 8:47 PM, "marc marc" a écrit :
>>      Ce genre de projet doit faire des stats anonyme de ce qu'il consomme.
>>      Tant que le volume est petit comme tu le décris, c'est acceptable de le
>>      faire sur un overpass public.
>> Mmm le but du projet est d'etre mondial et de recontrer une large adhésion.
> oui et non
> oui le projet a un but mondial
> mais combien sont les projets à avoir commencé comme initiative perso
> pour tester un concept en phase confidentielle ? parfois sans jamais
> atteindre leur public
> on peux difficilement demander à chaque projet de commencer par
> installer un overpass local.
> maintenant je retiens de ta réaction qu'il faudrait mieux communiquer
> pour expliquer ce que la montée en charge implique en prod et/ou
> protéger les serveurs contre les volumes excessif

Proposer une alternative simple à mettre en oeuvre à overpass pour des 
projets qui ont des besoins spécifiques pour accéder aux données OSM me 
semble utile car reproductible.
Jungle Bus peut être l'occasion de mettre ça au point.

Cela améliorera:
- la surcharge sur l'overpass
- les temps de réponse de Jungle Bus (un instance avec juste les données 
utiles et utilisée que par Jungle Bus sera plus réactive)
- l'autonomie en cas d'indispo des instances publiques overpass

L'idéal est un comportement identique à l'overpass comme ça le code 
actuel n'a pas besoin d'être modifié et en cas d'indispo de l'instance 
JungleBus l'appli peut basculer en backup sur les instances publiques.

Je ne suis pas assez familier avec le déploiement d'une instance 
overpass... mais c'est de ce côté qu'il me semble utile d'investir du 
temps (en ce moment je suis plus sur les orthos).

>> L'overpass traite la selection avant la bbox (ou a traité par le passé)
> Si quelqu'un a les infos technique, ce serrait utile à savoir
> parce que subjectivement, j'avais l'impression d'un gain en réactivité.
>
>> a quoi ressemblerait une appli sur laquelle on est obligé de
>> selectionner des petites bbox pour que ca reponde ?
> c'est ce que je disais, faut pas exagérer.
> mais si qlq édite un arrêt de bus à Paris, c'est pas utile de demander
> les arrêts de bus mondiaux (parce qu'au minimum il faudrait transférer
> les données).
> Mais le vrai gain est ailleurs.

C'est assez évident. La façon d'écrire les requêtes overpass avait une 
importance, est-ce encore le cas. Sélectionner en premier sur la bbox 
puis sur les tags me semble en général bien plus efficace sur des bbox 
raisonnables.

>> Migrez vers une infra dont un cache local, ne perdez pas de temps
>> Surtout comme l'explique Florian que sa structure en a les moyens
> +1

Peut être qu'une simple recette de déploiement d'instance overpass avec 
des données pre-filtrées (osmosis) pour ne garder que l'utile à l'appli 
concernée peut être amplement suffisant pour répondre aux besoins que 
j'ai indiqué plus haut... mais de diffuser la recette avant il faut 
tester le principe pour valider que ça fonctionne.

-- 
Christian Quest - OpenStreetMap France