Le 22 juillet 2017 à 20:46, marc marc <marc_marc_...@hotmail.com> a écrit :
> Le 22. 07. 17 à 15:23, Florian LAINEZ a écrit : > > J'ai été un peu perdu techniquement parlant à certains moments mais > > globalement j'ai compris. > N'hésites pas à demander ce qui a besoin d'explication supplémentaire > > Je vais séparer fortement ce que le(s) dev(s) peux/devrait faire de ce > qu'il est possible de faire côté serveur/infra > > > 1. Le cas du dev dans son coin > Pour lui le plus simple c'est d'encoder dans son application les url des > différentes instances overpass api existante > Il est les tries > - soit en fonction de leur géographie (demander au serveur français pour > un projet concernant des objets en France, ..) > c'est la solution est la plus efficace si les données sont géographique. > - soit il les appelle séquentiellement (le 1er puis le 2ieme puis le > 3ieme). c'est la solution la plus sympa pour la collectivité vu qu'elle > réparti la charge. > - soit il appelle toujours le premier et ne passe au 2ieme qu'en cas > d'erreur. c'est la solution faite quand un serveur est mieux qu'un autre > (l'allemand répond + vite que le russe) > Le dev devrait aussi se tenir au courant des changements de serveur. > Le serveur allemand qui n'a temporairement pas de maj, c'est à savoir. > Le serveur francais qui est en "pause", c'est aussi à savoir. > Quand un server ne répond plus, c'es facile à détecter. quand il ne se > met plus à jour, c'est compliqué. > Le dev doit réfléchir à un moyen de mettre à jour cette info dans > l'appli sans devoir produire une nouvelle version (une solution est de > téléchargé un fichier de conf au démarrage ou d'utiliser le dns, voir + > bas). > Au minimum je pense qu'il devrait suivre la page concernée du wiki pour > recevoir une alerte en cas de modif. > > > 2. Le cas Jungle Bus > 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. > Mais à un moment, le volume de ce qu'on demande engendre une charge non > négligeable et il devient préférable d'avoir un cache local. > La limite entre "sans cache" <> "avec cache" est très subjective. > Il faudrait collectivement discuter d'un ordre de grandeur à communiquer. > Le moyen de maj du cache est par contre ULTRA critique ! > La meilleure façon de gérer ça c'est à la demande, et avec des files de priorité (basées sur l'ancienneté de la dernière mise à jour ou de la dernière demande non encore satisfaite), à peine complété par un peu d'anticipation (basée sur les statistiques d'usage récent permettant de demander un peu plus que ce qui est demandé, par exemple sur une zone un peu plus grande, mais avec une priorité moindre, sachant qu'il y a déjà une propriété plus élevée que le téléchargement à la demande se fasse bien avant d'atteindre la priorité définie, et qu'une extension de la zone demandée n'est pas nécessaire et ne devrait même pas avoir lieu si les données déjà retournées pour les données demandées dépassent déjà un seuil de volume)
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
