infrastructure
infrastructure copied to clipboard
osm-fr
Décommissionnement d'osm12 pour son upgrade vers cluster-free
Il reste encore 3 containers openvz en fonctionnement sur osm12, voici la liste avec les services figurant dans le /data/project de chacun + leur config apache, rayé si plus actif :
- [ ] osm104 (~~bano1~~, ~~cadastre~~, ~~osmbin~~, ~~osmose~~ + ~~cadastre-joker~~, imagery)
- [x] osm105 (~~layers~~)
- [x] osm108 (osmbin/osmose/polygons)
(à mettre à jour au fur et à mesure de l'avancement)
osm105 me semble désormais totalement inutilisé, le rendu des tuiles "layers" ayant migré sur osm13. Je l'ai stoppé avant suppression.
Sur osm104, il reste:
- http://cadastre.openstreetmap.fr : interface pour extraire les données des PDF du cadastre, ce qui ne présente plus d'intérêt depuis que ces données sont dispo en opendata vectoriel. Quelques accès marginaux dans les logs. A supprimer ?
- cadastre-joker : proxy (ruby) vers les WMS du cadastre pour afficher en TMS le cadastre dans JOSM et autres éditeurs. A déplacer ?
- imagery.openstreetmap.fr : couches d'orthos anciennes utilisées pour les crises et urgences. A fusionner avec wms.openstreetmap.fr ?
osm108 est en cours de migration sur osm14, sur download.vm.openstreetmap.fr. Et par ailleurs, on n'aura plus d'osmose dessus, parce que la vérification des polygones administratifs se fait maintenant via la base osmosis de chaque pays.
Je pense que osmose+osmbin sur osm104 ne sont plus utilisés.
Pour http://cadastre.openstreetmap.fr, je propose de couper le service, en redirigeant vers une page du wiki disant que le service n'est plus actif, et de contacter tech@ si nécessaire.
https://cadastre.damsy.net se sert de http://cadastre.openstreetmap.fr parce que qu'attendre une (hypothétiquement) maj trimestrielle du cadastre vectoriel par etalab est trop lent pour ajouter un nouveau batiment il y a aussi le code addr:housenumber vers bâtiment qui n'existe pas encore sur https://bano.openstreetmap.fr/
Effectivement, il y a parfois des données temporairement plus à jour sur cadastre.gouv.fr mais c'est quand même l'exception plus que la règle et le décalage ne doit pas dépasser 3 mois justement.
cadastre.openstreetmap.fr fonctionne avec du code ancien plus maintenu (à ma connaissance) et en scrappant les PDF du cadastre, ce qui ne devrait plus être nécessaire aujourd'hui.
Entre un service non maintenable utilisé pour gagner parfois quelques mois, et quelque chose de stable avec un petit décalage je pense qu'il faut jouer la stabilité.
Qui est derrière cadastre.damsy.net ?
quand on ajoute un bâtiment récent manquant, 6 mois (quand c'est pas pire) de différence entre 2 sources n'est pas négligeable au point que je n'utilise jamais etalab pour ce genre de tâche, trop peu fiable. il y a une grande différence entre couper volontairement un service fonctionnel qui utilise la source la plus fiable. et le service est non maintenu (il y a + de contributeurs récent que d'autres "maintenu mono-contributeur") ce qui compromet sa viabilité.
le dépôt git de cadastre.damsy.net renseigne Gautier P (bagage), il est actif dans ta fenêtre irc :) son site n'est pas qu'un import du cadastre, c'est + que cela : recherche de lieu nécessitant un import sur base de la date ou de "cas d'école" : bâtiment nœud, absence d'église, ...), avec conflate prémaché de l'existant. à mes yeux cela classe le téléchargement vectoriel brut tel qu'il est actuellement dans la catégorie bricolage :-)
pour résoudre le soucis du mainteneur qui n'est plus actif sur le projet, le mieux serrait de nommer Gauthier mainteneur comme il s'était proposé il y a longtemps, c'est d'ailleurs lui qui a écrit la majorité des PR ces 12 derniers mois.
Si @bagage souhaite maintenir le code de cadastre.openstreetmap.fr et le service, ce sera avec plaisir, mais c'est à lui de décider !
Il faut par contre le redéployer sur un container récent, car là ça tourne dans un vieux conteneur openvz avec plein d'autres trucs qui partent à la benne.
Je n'aurai pas le temps ni les compétences pour le maintenir - probablement que mon site passera en veille aussi (les imports les plus prioritaires ont été réalisé).
C'est vraiment très très dommage de fermer cadastre.osm s'il n'y a pas d'alternative qui amène autant de précision. D'ailleurs, l'alternative est ?
C'est vraiment très très dommage de fermer cadastre.osm s'il n'y a pas d'alternative qui amène autant de précision. D'ailleurs, l'alternative est ?
Je plussoie : Avant de fermer un service ne serait-il pas judicieux d'en discuter largement sur un canal plus « main stream » Essayer par exemple de savoir si il est utilisé ?
Sur ces 2 dernières semaines, il y a en moyenne quotidienne 3 IP qui récupèrent des fichiers générés (j'ai viré les bots).
Aspect technique : ce service tourne dans un vieux conteneur (osm104), sur un vieux serveur (osm12, CentOS 6 + openvz) qu'on veut remettre à niveau pour plein d'autres usages (l'intégrer au cluster free)
Aspect humain : si personne n'est disponible pour redéployer ce service d'extraction de PDF dans un conteneur plus récent et maintenable, puis le maintenir, on ne peut pas mobiliser ad vitam æternam une machine entière pour un service à l'usage devenu assez marginal que personne ne maintient.
Pour les volontaires potentiels, le code derrière ce service se trouve sur https://github.com/osm-fr/export-cadastre (50% C++, 40% python)
Vu que ça ne sert que pour importer des batiments, ça me parait logique que l'utilisation ne soit pas bien fréquente. 3 IPs par jour me parait déjà pas mal.
Mais je repose la question: quelle est l'alternative pour importer des batiments du cadastre dans OSM ?
les alternatives sont :
- afficher la couche cadastre et dessiner par dessus
- ouvrir josm, télécharger depuis le cadastre via etala
Si il y a peu de fréquentation c'est peut-être que ce service est peu connu ? Moi-même l'ai découvert à l'occasion de cette discussion et depuis je m'en sers :)
La suite sur talk@ ? Car je crois que la question n'est pas que technique.
@vdct c'est justement parce que je ne connais pas l'alternative que je demande, tout comme @jocelynj
@Marc-marc-marc
les alternatives sont : * afficher la couche cadastre et dessiner par dessus
pouahbeurk :P
* ouvrir josm, télécharger depuis le cadastre via etalab
Et après ? (suis bleuette, je te rappelle...)
@cquest j'entends bien et ces difficultés techniques et d'occupation de temps humains sont connues.
Donc, quelle alternative ? Si elle existe, ok. Sinon...
JOSM permet de télécharger directement les données du cadastre (4ème onglet dans "Télécharger les données...")
On peut choisir la zone et le type d'objets à récupérer, typiquement bâtiments et adresses mais les autres infos sont aussi disponibles. C'est brut, sorti des données vectorielles en opendata.
La seule limitation (non négligeable malheureusement) étant que ces données ne sont mises à jour que 4 fois (a confirmer?) par an et ont donc un retard de plusieurs mois par rapport aux données directement extraites des pdf. Pour ma part (cadastre.damsy.net) j'ai fais le choix d'utiliser l'ancienne méthode pour cette unique raison, tant que la fréquence de maj etalab n'est ni stable (plusieurs fois des maj ont été oublié) ni assez élévée (1 par mois serait bien a mon avis).
Oui et non... car autant que je sache les données des PDF sont remise à jour une fois par an par commune. Donc entre les données opendata et les PDF:
- pour 3/4 des communes, il n'y a pas de retard,
- pour 1/4 il y a un retard d'au pire 3 mois.
Les données opendata contiennent d'autres infos... comme la date d'ajout dans le plan, ce qui facilite le repérage des nouveaux bâtiments.
Pour l'opendata, à ma connaissance il y a eu 1 mise à jour seulement de "sautée", ce printemps pendant le confinement, sinon à quelques semaines près c'est stable et si ça ne l'est pas j'ai le contact direct avec la personne qui s'en occupe.
@cquest vu (c'est le 3e onglet, dans mon JOSM de bleuette ^^). Mais ça ne résout pas, pour l'instant, le pb de @bagage :(
On peut choisir la zone
non, uniquement des planches cadastrales d'une zone.
C'est brut
c'est la moitié des problèmes que résout le projet de bagage : éviter de tout faire à la main
la date d'ajout dans le plan
c'est mis quel tag dans josm ?
bon bref, j'avais proposé jadis de faire un rsync entre la vm et une nouvelle histoire de sortie cadastre.osm-fr de osm12 sans s’embourber dans des dépendances chronophage
@Marc-marc-marc n'hésites pas si tu veux procéder ainsi (rsync vers nouveau CT) si tu penses que c'est jouable.
J'ai testé de mon côté l'onglet pour télécharger le cadastre dans JOSM, et j'ai trouvé ça bien plus pratique que de passer par http://cadastre.openstreetmap.fr.
Il y aurait juste cette page du wiki à mettre à jour pour recommander de passer directement par JOSM: https://wiki.openstreetmap.org/wiki/France/Cadastre/Import_semi-automatique_des_b%C3%A2timents
@Marc-marc-marc @jocelynj on continue sur talk-fr comme suggéré par @JacLavi (en changeant éventuellement l'objet du courriel ?). Parce que j'ai des choses à dire moi aussi ;P (et ça n'a rien à voir avec l'infra...)
Je ne peux pas m'engager à avoir le temps de le maintenir mais je peux essayer de prendre du temps pour porter cadastre.openstreetmap.fr, Quel type de conteneur ou vm serait disponible pour l'héberger ?
L'actuel est un conteneur openvz sous debian jessie, on passerait à un LXC sous debian buster.