Sur le fond on est d'accord, il va falloir disposer de ressources locales au projet pour ne plus dépendre d'OAPI.
Par contre, est-ce utile et justifié de monter une instance overpass en ayant préalablement épuré le jeu de données à ce qui nous intéresse uniquement ? Remonter un backend conforme à l'API central pour l'édition, qui dupliquerait le flux d'édition à la fois dans la base locale et sur OSM d'une part et qui permettrait de charger ces données dans l'appli frontend sur une bbox d'autre part ne requiert pas la puissance (et complexité adjacente) d'overpass. My 2 cents *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux <http://www.twitter.com/InfosReseaux> Le 21 juillet 2017 à 11:26, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 21/07/2017 à 10:48, marc marc a écrit : > > Comment fonctionne un serveur overpass ? il a > - une copie locale de la base mondiale > - un moyen pour la garder à jour (par ex chaque minute via un diff) > > > Oui, dans les grandes lignes c'est ça, la particularité c'est que la base > a une structure propre à overpass et a été spécialement conçue pour > l'organisation des données OSM. C'est ça qui fait qu'overpass est très > performant car spécialement conçu pour cet unique usage. > Il n'y a pas de postgres ou autre utilisé (sauf, il me semble pour les > "area"). > > Si Jungle bus avait sa base locale contenant toutes infos couramment > utilisée par cet app (plateorm, bus_stop, stop_area, route=bus), > Jungle bus pourrait interroger cette overpass "privé" au lieu d'un > overpass "public". Cette copie locale serrait très petite en > taille vu qu'il y a moins de 2 millions de ces 4 tag > La maj de cette copie serrait très petite aussi vu qu'un arrêt de bus ne > change pas souvent. > > > Voilà... on ne traite qu'un tout petit sous ensemble des données OSM et ça > allège du coup beaucoup de choses ! > > La seule chose qui reste à créer c'est un "diff" non pas mondial ou > géographique comme cela existe déjà mais sur base d'un nombre limité > d'objet (par exemple plateorm+bus_stop+stop_area+route=bus) > > > osmfilter / osmconvert ou osmosis peuvent servir à ça en amont pour > filtrer les diff avant de les injecter dans l'update d'overpass afin de ne > garder que ce qui est utile. > > Quand au délais de maj, il existe sur tous les serveurs. > si tu interroges l'overpass allemand, il a une minute de décalage. > La copie local aurait le même genre de lag. > Cela n’empêche en rien de voir le résultat de ton édition. > Des app comme Go Map conservent une copie de ce que tu as envoyé > Le seul effet réel est que si tu as 2 smartphones, > les modifs de l'un mettront une minute pour être visible sur l'autre. > C'est le cas pour d'autres app, cela me semble acceptable. > > > En général ça ne pose pas de problème ou plutôt ça en posera un quand il y > aura des millions de contributeurs Jungle Bus qui éditerons tous > ensemble... ce que j'appelle un "problème de riche". > > J'ai lu la doc d'install hier soir. > L'installation a l'air assez documentée. > Je vais tester en local dans les jours à venir. > > > Teste sur un extrait, pas sur le planet... et SSD (rapide) indispensable > > Mais la version osm-fr était-elle standard ? > A lire le wiki, j'ai l'impression que l'instance osm-fr a une > amélioration pour permettre de s'en servir comme proxy d'édition. > > > C'est un petit script au dessus d'overpass (et indépendant) qui permet de > l'utiliser en lieu en place de l'API d'édition. > > -- > Christian Quest - OpenStreetMap France > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
