Des systemes comme ipfs ne permettraient-ils pas de partager la charge ?
Est-ce de ceci dont vous parlez https://github.com/ipfs/ipfs ?
Si oui alors pas vraiment, à priori. Ce système (que je ne connais pas donc je risque de dire encore des grosses bêtises) a l'air
d'être destiné à distribuer des ressources statiques.
Ici la problématique se situe d'une part parce que ce sont des données volumineuses et coûteuses à traiter; combiné au fait qu'elles sont relativement dynamiques. Ce qui fait qu'un système purement statique, basé sur du pré-calcul, serait un gaspillage de ressources, par opposition à une solution "à-la demande + cache".
Ici on parlerait—au conditionnel, je n'ai pas vu passer les chiffres que certains ont demandé—plus de problèmes de charge CPU/memoire, administration, que de bande passante ou de disque. Le dump postgis pour la terre entière pèse +50GB, donc il faut déjà un gros serveur PostgreSQL pour extraire les informations géographiques nécessaires (btw on peut certainement diviser en zones géographiques, mais au final la charge globale revient au même... surtout que les zones les plus densément peuplées sont probablement les plus chargées aussi). Je n'y connais pas grand chose, si quelqu'un qui a du chiffre concret passe dans le coin, qu'il n'hésite pas à sortir son clavier pour nous éclairer sur ce que cela représenterait (query db, génération de tiles, charge/requêtes, dans la vidéo de la conf gnome liée dans le journal associé on ne parle que de taille des tuiles à différentes résolutions vs vectoriel)....
Bref, je pense qu'il s'agit de trouver un compromis sufisamment économe afin de résoudre de manière efficace le transit et la transformation des données depuis la DB OSM vers le client utilisateur. DB OSM -> dump ou synchro par delta -> PostGIS de travail -> serveur de tiles (bitmap et/ou vectorielles) -> caching -> transport -> rendu client. Un protocole basé sur bittorrent ou similaire, ne résoudrait que la partie caching -> transport. Ou alors il faudrait être très astucieux pour trouver un moyen de distribuer tout cela de manière efficace (comment calculer le hash d'une ressource sans l'avoir calculée au préalable ?), je doute que cela soit même possible.
Néanmoins il est certain que simplement pomper les ressources d'un service gratuit ou d'OSM sans autre forme de coopération me semble un peu shortsighted. Réciproquement, reprocher ce manque de prévoyance au developpeur de gnome maps, voire à l'encontre du projet gnome, semble tout autant disproportionné :-)
[^] # Re: osm map via BitTorrent
Posté par benja . En réponse à la dépêche Une grosse tuile pour GNOME Maps. Évalué à 3.
en réponse à https://linuxfr.org/nodes/109564/comments/1665619
Est-ce de ceci dont vous parlez https://github.com/ipfs/ipfs ?
Si oui alors pas vraiment, à priori. Ce système (que je ne connais pas donc je risque de dire encore des grosses bêtises) a l'air
d'être destiné à distribuer des ressources statiques.
Ici la problématique se situe d'une part parce que ce sont des données volumineuses et coûteuses à traiter; combiné au fait qu'elles sont relativement dynamiques. Ce qui fait qu'un système purement statique, basé sur du pré-calcul, serait un gaspillage de ressources, par opposition à une solution "à-la demande + cache".
Ici on parlerait—au conditionnel, je n'ai pas vu passer les chiffres que certains ont demandé—plus de problèmes de charge CPU/memoire, administration, que de bande passante ou de disque. Le dump postgis pour la terre entière pèse +50GB, donc il faut déjà un gros serveur PostgreSQL pour extraire les informations géographiques nécessaires (btw on peut certainement diviser en zones géographiques, mais au final la charge globale revient au même... surtout que les zones les plus densément peuplées sont probablement les plus chargées aussi). Je n'y connais pas grand chose, si quelqu'un qui a du chiffre concret passe dans le coin, qu'il n'hésite pas à sortir son clavier pour nous éclairer sur ce que cela représenterait (query db, génération de tiles, charge/requêtes, dans la vidéo de la conf gnome liée dans le journal associé on ne parle que de taille des tuiles à différentes résolutions vs vectoriel)....
Bref, je pense qu'il s'agit de trouver un compromis sufisamment économe afin de résoudre de manière efficace le transit et la transformation des données depuis la DB OSM vers le client utilisateur. DB OSM -> dump ou synchro par delta -> PostGIS de travail -> serveur de tiles (bitmap et/ou vectorielles) -> caching -> transport -> rendu client. Un protocole basé sur bittorrent ou similaire, ne résoudrait que la partie caching -> transport. Ou alors il faudrait être très astucieux pour trouver un moyen de distribuer tout cela de manière efficace (comment calculer le hash d'une ressource sans l'avoir calculée au préalable ?), je doute que cela soit même possible.
Néanmoins il est certain que simplement pomper les ressources d'un service gratuit ou d'OSM sans autre forme de coopération me semble un peu shortsighted. Réciproquement, reprocher ce manque de prévoyance au developpeur de gnome maps, voire à l'encontre du projet gnome, semble tout autant disproportionné :-)