correspondance opendata<>osm

[Marc-marc-marc]

qui d'ici ou d'osmose-backend est le mieux placé pour extraire des tags supplémentaire depuis l'opendata ?
par ex "Telecharger l'application DRIVECO, votre copilote en electrique, sur www.driveco.com" donne l'info que c'est gérable par app
ou bien encore rajouter des infos valable pour tous le réseau, par ex ce réseau permet le payement par app

[nlehuby]

J'ai une préférence pour la solution où on le fait plutôt ici : ça permet de garder l'analyse Osmose la plus simple et la plus lisible possible.

Mais l'inverse se défend tout aussi bien, d'autant que la plupart des analyses Osmose tapent en direct sur un jeu de données open data donc doivent embarquer leurs propres enrichissement de ce type.

Donc je dirais que c'est celui qui fait qui décide 🤷‍♀️

[nlehuby]

Je partage une réflexion connexe :

je me demande si l'approche consolidée, avec un seul fichier open data et une seule analyse Osmose continue de faire sens aujourd'hui : chaque producteur a son lot d'erreurs qui lui sont propres et qu'on ne retrouve pas chez son voisin donc faire une analyse Osmose dédiée permettrait de gérer ses spécificités finement.

Autre avantage à travailler localement : chaque réseau a sa configuration d'implantation dont on peut déduire bcp plus de choses. Par exemple, si on voit qu'il a des bornes avec 1 seul pdc, on sait qu'on peut créer autant de bornes dans OSM qu'il y a de pdc dans le fichier (au lieu de proposer un unique point pour toute la station). À l'inverse, s'il a une config typique avec une borne pour 2 pdc et 2 places de stationnement, on pourrait retraiter différemment. Le fait de travailler à l'échelle nationale ne permet pas de tirer partie de cela alors que ça permettrait d'améliorer sensiblement la qualité dans OSM.

[Marc-marc-marc]

mais faut-il pour autant avoir plusieurs analyses ?
je pense que ce serrait utile d'avoir une seule analyse mais un fichier de "particularité" plus poussé par opérateur.
le hic de la gestion des bornes c'est que pour le moment on est (dans le sens "france" à la ramasse avec la modif/précision que amenity=charging_station est la station et non plus la borne et devrait être donc unique par ref (j'étais contre la modif parce que je trouve que ce que le contributeur voir sur le terrain, c'est la borne, pas le regroupement "meta" de station...mais ainsi fut l'avis majoritaire) et man_made=charge_point pour la borne (mais pas rendu donc je pense que cela va refroidir la contribution)

[guiohm]

De mon côté, je suis en train d'améliorer les logs ici pour avoir un meilleur visu sur les problèmes par fournisseur/producteur. Je pense que ça pourra aider dans cette direction pour identifier les spécificités. https://github.com/guiohm/ref-EU-EVSE/commits/dev/