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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
