Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interractions avec le projet OpenStreetMap #187

Open
flacombe opened this issue Jul 11, 2023 · 6 comments
Open

Interractions avec le projet OpenStreetMap #187

flacombe opened this issue Jul 11, 2023 · 6 comments
Labels
✨ Feature New feature or request question Further information is requested

Comments

@flacombe
Copy link

Bonjour,

En ayant regardé le récent webinaire d'OpenIG sur Géorivière, il est indiqué la possibilité de pouvoir intégrer plusieurs sources de données, en plus de Topage.
D'ailleurs dans les deux sens : l'intégration dans Géorivière et plus tard le retour d'informations vers le producteur (ici l'IGN).

L'intégration de données OpenStreetMap hydrographiques est-elle prévue ?
Topage souffre de nombreux manques et sa complétude sera très difficile à obtenir.
Ses producteurs n'ont pour l'instant pas indiqué de changements allant permettre de l'obtenir dans les prochaines années.

La problématique est d'ailleurs double, avec l'exhaustivité géographique et aussi sémantique.
Il est nécessaire de documenter les cours d'eau naturels et aussi artificiels.
OpenStreetMap construit un modèle attributaire depuis sa création pour ça
https://wiki.openstreetmap.org/wiki/FR:Cours_d%27eau
Avec des détails sur les cours d'eau artificiels en particulier pour l'hydroélectricité : https://wiki.openstreetmap.org/wiki/FR:Power_generation/Hydropower

Quels pourraient être les prochaines étapes pour permettre l'usage de ces données dans la feuille de route de Géorivière ?

@camillemonchicourt
Copy link

On intègre dans Georivière une couche de linéaire de rivières dans une table générique.
Donc on prend ce que l'on veut comme source de linéaire. IGN, OSM ou tout autre source, comme on le souhaite.
Cela n'est pas spécifique ou lié à l'outil.

@flacombe
Copy link
Author

Fort bien, on peut donc intégrer des données OSM facilement.

Qu'en est-il pour le retour ?
Cette question est importante pour deux raisons, par rapport à la fonctionnalité d'enrichissement de la morphologie :

  • Si le technicien en rivière ou le géomaticien améliore la morphologie du cours d'eau, il est d'intérêt de la renvoyer dans le référentiel en évitant au producteur (ou au bénévole) d'avoir à faire le même travail.
  • Si les données de bases viennent d'OSM, Géorivière étant utilisé publiquement, les données doivent être partagées à l'identique comme prévu par la licence ODbL. L'utilisateur qui intègre des données OSM dans Géorivière en est responsable mais il ne pourra respecter cette obligation que si le logiciel le lui permet.

Une question similaire est posée à 1:12:10 dans le webinaire d'OpenIG.
Il est question du renvoi automatique à l'IGN, on pourrait envisager la même chose dans OSM puisque les deux sources intègrent les codes SANDRE sur les géométries de cours d'eau.

Je comprends qu'il y a des fonctionnalités d'export simple (et donc l'utilisateur devra publier par lui-même cet export sous licence ODbL si nécessaire) et que des moyens plus automatiques de reversement vers l'amont seront développés plus tard, est-ce bien ça ?

@camillemonchicourt
Copy link

Oui cela dépasse un peu l'outil mais concerne plutôt son usage dans le contexte de chaque instance.
Georiviere propose des fonctionnalités d'export de toutes les données qu'il contient, qui permettent donc de partager les contenus sous licence libre.

On peut aussi brancher des solutions automatiques directement sur la BDD, comme on le propose sur Geotrek : https://si.ecrins-parcnational.com/blog/2021-06-publier-opendata-continu.html

Georiviere dispose aussi d'une API, qui pourrait permettre d'envisager des récupérations de données plus automatiques et réguliers.
Cette API est utilisée par https://github.com/Georiviere/Georiviere-public, donc je ne sais pas si elle contient déjà tous les objets présents dans Georivière-admin.

@flacombe
Copy link
Author

Merci pour les compléments, on a déjà de bonnes fonctionnalités pour repartager.

Autre point, sur le modèle de données internes : il n'existe visiblement pas de standard sur la GéMAPI, outre ce qui est déjà construit pour la BDTopage et les formats définis pour le SIeau.
Est-ce que de futures évolutions de l'outil nécessiteraient des compléments et souhaitez-vous conserver ce modèle de données interne particulier ?

Si OSM est surtout identifié pour aller chercher des données, il peut aussi l'être pour apporter des modèles sémantiques.
L'hydrologie étant un sujet d'intérêt pour moi et je contribue au développement attributaire d'OSM. Ce peut être intéressant d'alimenter notre feuille de route avec ces besoins.

@thomasmagninfeysot
Copy link

Bonjour @flacombe, alors pour le modèle de données il a été travaillé avec plusieurs structures lors du développement de l'outil pour avoir un modèle qui puisse correspondre au maximum de structures et dans des contextes différents. Il s'agit d'un premier tronc commun et ce modèle pourrait encore évoluer et être compléter avec de nouveaux besoins. Si un modèle de données nationale émergerait, on sera bien évidemment ok pour faire évoluer le notre. Il y a plusieurs autres outils similaires à Georivière, il faudrait donc pouvoir travailler tous ensemble sur un modèle commun.

Concernant le BDTopage, je suis bien d'accord avec vous qu'elle est encore trop imprécise et pas assez exhaustive et que les mise à jour sont longues. Il faut cependant garder à l'esprit qu'il s'agit du référentiel utilisé par les services de l'état (OFB, DDT..) pour le classement des cours d'eau/non cours d'eau, il s'avère donc judicieux pour nous d'utiliser cette donnée comme base dans le cadre de la GEMAPI. A noter que l'échange de données dans le sens Georivière>IGN avec l'API de l'espace collaboratif n'est pas effective, il s'agit d'un projet que nous souhaiterions réaliser avec l'IGN. Le but est de pouvoir apporter un enrichissement de la BD Topage avec les modifications terrains faites depuis GeoRivière. On pourrait aussi imaginer ça avec OSM. Comme l'a dit Camille, l'idée est de pouvoir s’interfacer et échanger avec d'autres outils/plateformes

@flacombe
Copy link
Author

flacombe commented Jul 16, 2023

Bonsoir @thomaspnrhj merci pour les explications complètes !

Si un modèle de données nationale émergerait, on sera bien évidemment ok pour faire évoluer le notre.

OpenStreetMap fait émerger un modèle mondial, on ne souhaite pas introduire de silos locaux.
Cette présentation faite en 2018 le montre bien : https://peertube.openstreetmap.fr/w/vazRxKq3b8VdSwFjMuFceo
Pour le big picture, c'est à 9:20 ou plus techniquement sur le wiki OSM.

Pour autant, des compromis peuvent être fait pour faire communiquer les deux mondes sans tout dynamiter. Ce peut être progressif.

A noter que l'échange de données dans le sens Georivière>IGN avec l'API de l'espace collaboratif n'est pas effective, il s'agit d'un projet que nous souhaiterions réaliser avec l'IGN.

Je comprends l'idée et vis à vis de la Gemapi, ca peut avoir son intérêt en effet tout en étant vigilent sur la rivalité entre données de référence, leur complétude et les effets que cela a sur le milieu naturel.
Il faut espérer que la politique autour de Topage ne fasse pas perdre trop de temps à l'écosystème qui a beaucoup d'attentes.
A côté de ça, on a un fonctionnement collaboratif déjà établi, des contributeurs motivés et un socle qui peut rivaliser avec Topage. Voici ce que j'en pense, récemment sur Géorezo.
N'hésitez pas à le faire savoir à vos partenaires.

On se tient à votre disposition si vous voulez avancer.
Bonne semaine :)

@babastienne babastienne added ✨ Feature New feature or request question Further information is requested labels Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ Feature New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants