infrastructure
infrastructure copied to clipboard
osm-fr
Demande VM pour "Adopte une commune"
Suite à l'atelier "Adopte une commune" qui s'est déroulé pendant le Sotm (voir discussion), j'aimerais pouvoir installer un outil d'observatoire / suivi d'avancement des données bâtiments + route sur la France, à l'échelle communale. L'idée de cet outil est de :
- Produire chaque jour (chaque heure ?), pour chaque commune, un indicateur de l'avancement de la cartographie de différentes thématiques (pour l'instant bâti + routes) en comparant avec des bases nationales
- Proposer ces indicateurs sous la forme d'un outil web (probablement MapLibre + tuiles vectorielles)
- Faire du lien avec des outils d'édition classique (Osmose, iD, JOSM), voire un Task manager si une instance est installée
- Le tout pour faciliter l'animation à l'échelle départementale autour de ces sujets (faire du jardinage :leaves: )
J'ai publié un premier brouillon de code ici : https://gitlab.com/PanierAvide/adopte-une-commune-observatoire
Les technologies utilisées sont très classiques (pour l'instant Docker OSM pour l'import et mise à jour de la base OSM, PostgreSQL/PostGIS, du Python, prochainement pg_tileserv et MapLibre GL pour la partie carto web).
Les ressources pour la machine :
- 4 CPU
- 16 Go RAM
- 300Go espace disque
- Pouvoir y lancer du Docker
@frodrigo si tu peux valider que les volumes de ressources demandés sont pas déconnants à la vue de la demande :grin:
Merci d'avance :relaxed:
de mémoire, la question d'avoir par exemple une base osm commune à plusieurs a été quelque fois posé, j'imagine bien que plusieurs projets ont besoins de données à jour. Cela peut-être une fausse bonne idée de ma part :)
Ça simplifierait bien des problèmes :
- Qu'une base à maintenir synchronisée, possiblement à la minute, et pour tout le territoire national (voire monde ?)
Mais ça en pose bien d'autres aussi :
- Gestion des droits d'accès en lecture seule pour éviter qu'un logiciel mette le bazar
- Créations de n schémas (un par appli) pour segmenter un peu les tables annexes
- Côté critique d'avoir qu'une seule base pour tous les projets (et en même temps ça peut simplifier les backups)
À voir si cette demande est le bon moment pour faire ça ou pas :thinking:
n'est-ce pas à envisager pour que ce projet soit le premier et seul (au départ) connecté à cette base unique ? vous connaissez ma capacité à ne pas faire sur ce genre de chose car je ne sais pas faire :D c'est plus facile à dire !
Je pense plutôt a deux autres solutions
- utiliser une base commune avec les données (rendu avec osm2pgsql) à jour à laquelle on se connecte depuis la base du projet. Je pense que BANO faut déjà ça.
- voir si possible d'utiliser l'API d'Ohsome pour ce besoin
Je vois effectivement que Ohsome a un point d'appel pour récupérer la densité : https://docs.ohsome.org/ohsome-api/v1/endpoints.html#post--elements-(aggregation)-density-groupBy-(groupType)
Est-ce que tu as des retours sur la disponibilité, mise à jour et stabilité de Ohsome ?
Et pour l'approche à la BANO, techniquement comment ça se joue ? Avec une base distante (foreign data wrapper) ? Est-ce qu'il y a moyen de mimer le fonctionnement en local pour pousser du code le plus prêt-à-l'emploi possible ?
- Je pense que BANO faut déjà ça.
Ca c'est le fonctionnement de BANO de 2014 à 2020 environ. Depuis BANO a sa propre base, taillée sur mesure pour son besoin, et alimentée par imposm. Je ne crois pas une seconde à la base commune à de multiples projets, j'ai pour BANO énormément simplifié le code et les processus en ayant une base sur mesure. Dans le cas de BANO c'est une toute petite base (pas besoin des bâtiments, notamment) donc très réactive et toalement orientée pour UN besoin. En terme de gouvernance, ça me parait un gros bazar d'avoir une même base à plusieurs, tant l'exercice de faire converger tous les besoins me paraît chronophage, pour un gain que je ne perçois pas. Si on veut mutualiser, on peut mutualiser la récupération des diffs pour alléger la sollicitation du serveur de diffs, mais au delà de ça chaque projet devrait assumer son propre chargement de données, taillé dans un modèle qui colle à ses besoins. La seule mutualisation inter-projets que j'arrive à imaginer serait pour de projets de rendu carto, où il semble assez naturel de préparer les primaires géométriques globalement de la même façon (agrégation, généralisation, etc). Mais pour des projets non carto (isochrones, routing, QA, BD consolidée, etc) je pense vraiment que c'est une fausse bonne idée.
* Qu'une base à maintenir synchronisée, possiblement à la minute, et pour tout le territoire national (voire monde ?)
Je tiens à insister, dès le début de l'initiative, sur le fait que le territoire national ne se limite pas à l'hexagone, pour éviter d'avoir le même problème que sur LeProjetDuMois :wink:.
le territoire national ne se limite pas à l'hexagone
L'extract france_metro_dom_com_nc.osm.pbf est fait pour ça : http://download.openstreetmap.fr/extracts/merge/
* Qu'une base à maintenir synchronisée, possiblement à la minute, et pour tout le territoire national (voire monde ?)Je tiens à insister, dès le début de l'initiative, sur le fait que le territoire national ne se limite pas à l'hexagone, pour éviter d'avoir le même problème que sur LeProjetDuMois wink.
il y a un candidat au CA qui devrait avoir un oeil attentif à cette question :)
je pense vraiment que c'est une fausse bonne idée.
j'entends très bien d'autant que je ne comprends pas tout à fait :)
Concernant la création de la VM, est-ce que docker est indispensable ? (le souci est qu'une install docker demande une VM qemu pour être bien géré par proxmox, et qu'on préfére des containeurs pour plus facilement gérer l'infra)
Je suis d'accord avec @vdct qu'une base commune n'est pas forcément idéal, surtout si on peut simplifier les données importés en base.
300G, ça me parait beaucoup: c'est pour le monde entier ?
Ce serait plus pratique si c'était en Docker, ça rend la mise à jour dans le temps de la base OSM beaucoup plus facile.
Peut-être qu'effectivement 300Go c'est beaucoup, 150 ? (c'est jamais simple d'estimer en avance l'espace occupé par les bases Imposm).
autant avoir une base commune pour différent projet est une idée discutable autant avoir une serveur progress par projet est un gaspillage de ram (la ressource la plus limitante de l'infra actuellement) un serveur progress permet sans problème à chaque projet d'avoir sa propre base
Plus d'objection ? On peut donner à @PanierAvide ce qu'il demande pour qu'il puisse avancer ?
Je regarderais ce week-end pour savoir où est-ce qu'on a de la place. Peut-être sur le cluster free ?
@jocelynj ou d'autres, du nouveau pour le lieu où on pourrait mettre cette VM pour Adopte une commune ? On peut sans doute commencer avec 150Go de place pour tester et augmenter la place au besoin.
