Effectivement la condition est qu'une partie des données est au minimum accessible au public, donc qu'on doit être capable d'utiliser ces références pour aller consulter ces ressources externes. Leur justification c'est d'une part de permettre de synchroniser la partie "libre" / "ouverte" de ces données qu'on aurait importées dans OSM, et de pouvoir les vérifier à leur source, et d'autre part de permettre aussi aux applications tierces (y compris non libres) de chercher des données déjà dans OSM pour les lier à d'autres données privées utilisant les mêmes identifiants.
Cela peut aussi faciliter l'ouverture d'autres jeux de données depuis la même source, et lui permettre aussi à cette source de pouvoir mettre en place un outil lui permettant de faire ces mises à jour de façon plus ou moins automatisées, le but étant alors d'avoir sans OSM dans données ouvertes actualisées plus facilement et plus rapidement. Cela peut aussi permettre de résoudre certains problèmes avec des applications tierces qui ne permettent pas facilement de consulter des données pourtant ouvertes, qu'elles n'ontègrent pas elles-mêmes et aussi de compléter leurs propres données incomplètes. Ces identifiants leurs permettront aussi d'utiliser plus facilement leurs propres données quand à la place de celles présentes dans la base OSM, quand ils savent que les leurs sont meilleures, OSM leur permettant alors juste de "boucher les trous" sut ce qu'i chez eux sont des données en impasse. En fin de compte cela permet à tout le monde d'valuer la qualité des données et des sources utilisées, et permettre, quand plusieurs sources ont des données incompatibles entre elles, de se mettre d'accord et trouver là où sont leurs différences pour les résoudre entre eux, et finalement qu'on soit aussi d'accord dans OSM avec eux.. Ces références croisées sont un outil facilitant les échange puis à terme la convergence des données entre différents acteurs, même si por l'instant ils n'envisagent pas encore de libéraliser une bonne partie de leurs données. Globalement, tout le monde va y gagner en terme de qualité et facilité de réutilisation de ces données grâce à une codification et une nomenclature commune dont on ne peut pas décider réellement nous mêmes (et faciliter la réutilisation des données fait aussi partie des buts d'OSM). si en fin de compte une des soures décide d'abandonner sa propre maintenance et se fier à une autre, on le saura assez vite, et on pourra supprimer alors les références liés à ces bases abandonnées car maintenant par une source faisant plus référence que les autres. Le 14 avril 2013 16:00, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Pour prendre un peu de recul... si on réfléchissait au problème de façon > plus globale ? > > Pour utiliser des ref:xx ? > > - pour lier des données OSM avec des jeux de données externes > > Peut-on/doit-on le faire pour n'importe quel jeu de données ? > > Je ne pense pas. Si ce sont des données librement accessibles et qui > apportent plus d'information sur un objet OSM, oui, ça me semble avoir sa > place dans OSM. Ca permet de ne pas inclure inutilement tout un ensemble de > données dans OSM, données qu'il faudrait maintenir à jour pour qu'elles > gardent de leur utilité. > > Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien. > > Comment faire l'inverse... avoir un lien dans des données externes vers > des objets OSM ? > > Là ça se complique gravement pour plusieurs raisons: > > - les "id" OSM ne sont pas pérennes: ils peuvent changer suite à un > effacement/recréation ou parce qu'on fait évoluer un objet (par exemple un > POI initial sur un nœud peut disparaitre en étant reporté sur un polygone) > > - un objet dans le jeu de données externe peut correspondre à plusieurs > objets dans OSM. C'est le cas par exemple pour les codes FANTOIR/RIVOLI > (rayer la mention inutile) qui identifient une rue, laquelle rue peut être > segmentée dans OSM... et là il faut avoir un objet englobant sous la forme > d'une relation. > > Il y en a sûrement d'autres... > > > Il va falloir se pencher sérieusement un de ces jours sur des identifiants > pérennes que je pense devoir mixer les 2 dimensions d'OSM à savoir la > dimension spatiale et la dimension sémantique en gardant un niveau de flou > sur les deux pour retrouver des objets qui ont légèrement bougé ou > légèrement changé de description. > > Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) > serait un truc du genre "bakery#u09v8z39" où "bakery" indique le type > d'objet cherché et #u09v8z39 est le geohash de sa position approximative. > > C'est assez facile à mettre en œuvre pour des objets ponctuels ou > surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash > (début/fin). > > L'utilisation pourrait se faire via une API interrogeant par exemple > l'overpass en convertissant ce "hash" à la volée. > > Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? > > -- > Christian Quest - OpenStreetMap France > Synthèse du Week-end "SOTM-FR" à Lyon : > http://openstreetmap.fr/s<http://openstreetmap.fr/sotmfr2013>ynthese-sotmfr > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
