Oui les ressources coutent cher, c'est bien pour ça qu'il faudrait imaginer un système de collaboration pour partager les couts et permettre des maintenances sans interrompre le service global. Il manque à Overpass une instance gérée par la Fondation OSM, et un système d'équilibrage de charge (permettant de répartir les requêtes). La Fondation Wikimedia pourrait aussi nous aider (il y a de nombreux projets wikiemdia qui pourraient bénéficier de données vectorielles dynamiques, y compris Wikipédia dans sa version francophone qui en fait usage, mais pas la version anglophone actuellement).
L'ennui c'est que toutes les instances veulent fournir une base "monde". Il sertait intéreessant d'imaginer un index "quad tile" sur 4 serveurs principaux, dont un est "maître" (et reçoit les mises à jour en priorité les 3 autres ayant des priorités moindres). Le partage de ressources pourrait aussi concerner la génération des "areas" (très couteuse sur le monde entier), et des listes de requêtes à réaliser feature par feature avec un système de prise en main et relachement et fourniture des résultats obtenus aux autres serveurs via un cache. On a des caches et un partage efficace actuelement uniquement pour les tuiles bitmaps, rien pour les couches vectorielles capables de répondre à bien des requêtes. Mais comment synchroniser efficacement les serveurs autrement qu'avec les minute diffs de la base OSM mondiale? Peut-on avoir des serveurs déidiés à certaines zones (qui auraient des données mises à jour plus régulièrement mais consultées par un cache par un autre serveur. On aurait quand même une réponse même si les données en cache sont anciennes mais chaque serveur soumettrait des demandes de rafraichissemnt aux autres en relayant les requêtes pour remettre à jour son propre cache. Le tout fonctionnant globalement "à la demande" et non pas purement géographiquement. Je ne suis pas sûr que la méthode de mises à jour via les minute diffs de la base monde permet de gérer l'équilibrage de charges et le partage de ressources pusique tout le monde doit faire la même chose dans sa base. Ca demanderait alors un système de mises à jour différents, par souscription ou diffusion (avec acquittement si on est toujours intéressé). Il serait essentiel pour que cela fonctionne que tout le monde respecte les prescriptions de gestion de proxy/cache du protocole HTTP/1.1 standard (notamment les dates de validitité). Il serait essentiel aussi de pouvoir localiser une liste de serveurs pouvant répondre à la recherche de certains "features"/"tags", pour que tout le monde n'ait pas à s'occuper de la totalité des données, mais aussi d'assurer quer toutes les données seront disponibles au moins quelque part (avec au moins un miroir, plus si les statsitiques d'usage montrent un intérêt particilier à certaines données). Mais tout ça demande du travail pour inventer un protocole. Et des discussions pour connaitre les moyens partageables et responsabilités de chacun. Ca mériterait une vraie discussion à SOTM Monde dans un atelier dédié. Il me parait essentiel de renforcer l'infrastructure et faciliter les collaborations et partager les moyens. Le petit CDN des tuiles bitmaps ne suffit plus du tout. Il y a de très bons développeurs de protocole pour MediaWiki qui pourraient aider à ce projet et ils ont des outils pour mesurer les besoins, évaluer les possibilités, faire des tests A/B, lancer des expérimentations, améliorer les protocoles, suivre les éléments à rendre obsolète et remplacer par d'autres plus performants. OSM n'a pas tout ça (et maintenant a moins de moyens depuis le départ de Mapquest qui développe son propre système et semble même prêt à utiliser des données propriétaires par des licences d'utilisation plus restrictives ou plus intrusives pour les visiteurs des cartes hébergées par lui) Et avec le temps ce manque de collaboration devient de plus en plujs critique car les données sont de plus en plus volumineuses et lourdes à gérer. Les couts ne cessent donc de monter pour tout le monde au lieu de se maintenir à un niveau permettant plus de participants pour la plateforme technique. Il est possible qu'à l'avenir la fondation OSM elle-même ne parvienne plus à gérer ces couts et que les appels de dons ne suffiront pas plus que les offres généreuses de partentaires tiers (pouvant fournir des la bande passante, des serveurs, de la capacité de calcul, de la connectivité et un temps de réponse acceptable dans le monde entier, et un support de veille pour assurer la maintenance du service avec un taux de panne faible). Mais pour Overpass, et même l'API OSM de base, on sent que tout cela tient à un fil. Et c'est très gênant pour les contributeurs de données dans les zones HOT où des imports massifs de données brutes sont demandé avec des pics de charge qui explosent par endroit, et où de très nombreuses corrections et vérifications sont nécessaires ensuite. La capacité limitée des serveurs ne permet pas de rendre les résultat attendus dans des temps raisonnable (alors que pour HOT il y a souvent urgence à fournir des données exploitables). Le 27 juillet 2016 à 19:47, Guillaume AMAT <guilla...@amat.io> a écrit : > Bonsoir François, > > Déjà merci pour votre retour positif, ça fait plaisir :) > Et d'ailleurs, le tutoiement ne me dérange pas du tout sur cette liste de > diffusion. > > Malgré la « fragilité » (relative) d'OverPass, je trouve étonnant que vos > requêtes ne fonctionnent pas la plupart du temps. Passent-elles sur > OverPass Turbo ? Combien de temps mettent-elles ? > > Un première version du cache a été développée mais le résultat est quand > même assez bancale... La génération se heurte elle aussi aux limites > d'OverPass :/ > C'est pour ça que je ne l'ai pas encore rendu disponible sur les instances > officielles. > > L'idée d'utiliser une autre instance d'OverPass a été évoquée mais où ? Je > crois savoir que ça demande pas mal de ressources et les ressources coûtent > cher. > > Bonne soirée, > Guillaume > > > > Le 26/07/2016 à 10:58, François Lacombe a écrit : > > Bonjour Guillaume, > > Merci pour le travail que vous faites, l'outil s'étoffe de plus en plus :) > > Relativement à ce point sur le rafraichissement, en chargeant les données > en live, je ne peux pas utiliser mapcontrib. > Bien souvent mes requêtes n'ont pas de réponse, quelque soit le moment de > la journée ou alors il faut attendre plusieurs minutes. > > Cette idée de cache avec des chargements uniques au moment le plus > opportun serait un énorme plus > > Ou alors choisir une instance d'overpass qui est moins sollicitée parce > qu'il est vrai qu'il faut bien pouvoir tester ces requêtes à un moment > donné avant de les "figer" dans le thème. > On a pas la main là-dessus n'est-ce pas ? > > Bonne continuation > > François > > Le 20 juillet 2016 à 11:40, Guillaume AMAT <guilla...@amat.io> a écrit : > >> Pour l'instant il n'y a pas de rafraichissement. Les couches OverPass >> sont chargées à l'arrivée sur un thème et quand on se déplace. >> >> >> >> Le 20/07/2016 11:33, Francescu GAROBY a écrit : >> >>> Tout a l'air de fonctionner, maintenant... >>> >>> Quelle est la fréquence de rafraîchissement, au fait ? >>> >>> Francescu >>> >>> Le 20 juillet 2016 à 11:24, Guillaume AMAT <guilla...@amat.io> a >>> écrit : >>> >>> C'est bon maintenant ! >>>> Pfff, le faux départ, c'est con... ;) >>>> >>>> Désolé pour le temps perdu, >>>> Guillaume >>>> >>>> Le 20/07/2016 10:57, Guillaume AMAT a écrit : >>>> Ah si vu ! >>>> Un souci au login pour certaines personnes. Je corrige vite. >>>> >>>> Le 20/07/2016 10:47, Guillaume AMAT a écrit : >>>> Étrange que vous ayez tous cette erreur, tout va bien de mon >>>> côté. >>>> Dans le doute j'ai redémarré le proxy qui est devant. >>>> Ça va mieux pour vous ? >>>> >>>> Le 20/07/2016 10:15, Philippe Verdy a écrit : >>>> Problème: http://www.mapcontrib.xyz [1] [6] fait une erreur 502 >>>> BAD >>>> GATEWAY pour l'instant (erreur temporaire de connexion de ton >>>> proxy?). >>>> >>>> Seule http://www.cartes.xyz [2] [7] fonctionne pour l'instant... >>>> >>>> >>>> Le 20 juillet 2016 à 08:47, Guillaume AMAT <guilla...@amat.io> a >>>> écrit : >>>> >>>> Bonjour à tous, >>>> >>>> Aujourd'hui sort la version 0.10.0 de MapContrib ! :) >>>> >>>> Pour rappel, MapContrib est une application web de contribution >>>> thématique à OpenStreetMap. Elle se veut simple, universelle >>>> (fonctionne sur tous les supports) et mobile (allez la tester dans >>>> la rue !). >>>> >>>> MapContrib a été présentée au SOTM FR 2016 [1] et le sera aussi >>>> au SOTM de Bruxelles en septembre [2]. >>>> >>>> Du point de vue utilisateur, cette version apporte entres autres : >>>> >>>> * À l'ajout d'un POI, le placement de celui-ci se fait via une >>>> croix affichée au-dessus de la carte. >>>> * La possibilité de déplacer un POI de type nœud. >>>> * De nouveaux types de couches, basés sur des fichiers GPX, CSV >>>> et GeoJSON. >>>> * L'ajout d'une colonne d'information sur les couches. Elle >>>> affiche les requêtes OverPass utilisées, les fichiers de données >>>> originaux, un bouton de téléchargement des données de la couches >>>> au format GeoJSON, etc. >>>> * La possibilité de géolocaliser automatiquement l'utilisateur. >>>> * Le comportement de la recherche de la page d'accueil est plus >>>> clair et cohérent. >>>> * Le bouton bleu « info » dans les champs de contribution est >>>> maintenant actif et renvoie sur la page taginfo de la clef courante. >>>> * Les résultats de la recherche de lieu (géocodage) sont plus >>>> lisibles et apportent plus d'informations. >>>> * La possibilité d'afficher les infos de POI dans des fenêtres >>>> modales oue des colonnes, à la place des infobulles classiques. >>>> * Et comme toujours, une multitude de corrections et >>>> améliorations diverses ;) >>>> >>>> Vous pouvez dès à présent tester/utiliser/partager l'outil aux >>>> adresses http://www.mapcontrib.xyz [1] [3] et http://www.cartes.xyz >>>> [2] [4] >>>> (elles pointent toutes les deux sur la même instance de >>>> MapContrib). >>>> À bientôt, >>>> Guillaume >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr [3] [5] >>>> >>>> Links: >>>> ------ >>>> [1] >>>> >>>> >>> http://www.dailymotion.com/video/x4dtprb_sotm-fr2016-vincent-bergeot-guillaume-amat-mapcontrib-faciliter-la-contribution-autour-d-une-themati_school >>> >>>> [4] >>>> [2] >>>> >>>> >>> http://2016.stateofthemap.org/2016/mapcontrib-openstreetmap-contribution-simple-everywhere/ >>> >>>> [5] >>>> [3] http://www.mapcontrib.xyz [1] >>>> [4] http://www.cartes.xyz [2] >>>> [5] https://lists.openstreetmap.org/listinfo/talk-fr [3] >>>> [6] http://www.mapcontrib.xyz/ [6] >>>> [7] http://www.cartes.xyz/ [7] >>>> >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr [3] >>>> >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr [3] >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr [3] >>> >>> -- >>> >>> Francescu >>> >>> Links: >>> ------ >>> [1] http://www.mapcontrib.xyz >>> [2] http://www.cartes.xyz >>> [3] https://lists.openstreetmap.org/listinfo/talk-fr >>> [4] >>> >>> http://www.dailymotion.com/video/x4dtprb_sotm-fr2016-vincent-bergeot-guillaume-amat-mapcontrib-faciliter-la-contribution-autour-d-une-themati_school >>> [5] >>> >>> http://2016.stateofthemap.org/2016/mapcontrib-openstreetmap-contribution-simple-everywhere/ >>> [6] http://www.mapcontrib.xyz/ >>> [7] http://www.cartes.xyz/ >>> >>> _______________________________________________ >>> 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 >> > > > > _______________________________________________ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > 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
