[OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

[Adrien André]

Le 19-11-07 à 07 h 26, marc marc a écrit :
> l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
> on y encode la meilleur image dispo au moment de l'encodage.
> et puis ?
> Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
> on peux la récupérer quand on a besoin, sans besoin de maintenance

J'ai toujours eu du mal avec cette tendance des attributs d'OSM à 
devenir le réceptacle des identifiants de toutes les bases externes 
existantes.

Je ne suis pas utilisateur de mapillary, et je me demande ce qui le 
différencie tant des sources habituelles.
Tout comme source=Bing + source:date=20191107,
source=mapillary + source:date=20191107 ne suffit-il pas ?
Pour aller plus loin, et afficher des photos dans une interface, je 
chercherais du coté de
https://www.mapillary.com#gimme=pics&lon=1.234&lat=5.678&date=20191107

Si on tient à stocker des informations de lien, alors la place de ces 
informations ne serait-elle pas plutôt ailleurs ?
Par exemple, dans des tables (OSM ou base satellite) à part. Tables qui 
pourraient ressembler au brouillon suivant :

type     | id    | version | database | key
-------- | ----- | ------- | -------- | ---
relation | 65606 | 289     | wikidata | Q84
          |       |         |          |


database | url                      | url_pattern
-------- | ------------------------ | ------------------------------------
wikidata | https://www.wikidata.org | https://www.wikidata.org/entity/{key}
          |                          |

Ceci pouvant également servir à des systèmes spécifiques pour lier leurs 
données avec celles d'OSM.

Les informations sémantiques sur les éléments restent ainsi séparées de 
la donnée technique de lien.
Les interfaces utilisant OSM peuvent s'en servir pour afficher les 
données de bases externes (photos, extraits d'articles, etc).
Et je présume que la maintenance d'openstreetmap.org en serait allégée.

-- 
Adrien