[OSM-dev-fr] Des IDs a votre bon coeur COMPLET J'ESPERE.

Philippe Verdy verdy_p at wanadoo.fr
Ven 28 Juin 14:18:59 UTC 2013


Je suis aussi d'avis que ces IDs générés en interne par une base privée
sont du même type que ceux généras par un des nombreux services de type
TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
ni même librement utilisables (et sans suivi de leur utilisation par un
tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
données modifiées de son choix dans le trafic).

Si des IDs stables doivent exister pour référencer des objets OSM, ils
doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
identifiants INSEE par exemple, librement vérifiables).

La "stabilité" des IDs est très relative : elle n'est garantie que si ils
sont datés avec leur date de validité, les objets référencés pouvant à tout
moment changer de statut. Si un ID stable devait être utilisé, il devrait
au minimum inclure l'année de leur création
- soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
ref:INSEE=35238),
- soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
d'avoir une autre clé pour d'autres années après un changement de l'objet
référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
autre voisine).
Ensuite à charge pour les outils de recherche et de mise en relation avec
d'autres bases de faire les correspondances avec ces IDs stables, en tenant
compte de l'année s'il y a des IDs différents pour la même base de
référence (ici celle de l'lNSEE).

Combien d'IDs garder ensuite dans la base OSM ? On peut faire le ménage en
fonction des dates indiquées justement, qui permettent de procéder à des
vérifications ultérieures ou des remises à jour (même si cela consiste
seulement à garder l'identifiant en ne changeant que l'année), et en
fonction de l'universalité de ces identifiants (les identifiants INSEE sont
assez largement universels pour être gardés à demeure pour longtemps
partout en France, tant que l'INSEE les maintiendra; mais l'INSEE peut
aussi décider une année de revoir son propre système de codification et ces
dates indiquées dans des références supplémentaires historiques seront
utiles pendant une période de transition assez longue). Ces identifiants
sont plus universels que bien d'autres d'origine privée (mais d'usage
limité au seul domaine de leur concepteur).

Les IDs externes ne sont utiles que si la base externe est bien la source
de référence principale et fiable de vérification des données (cette
fiabilité pouvant être garanti par la loi quand elle oblige une entité à
s'inscrire dans un registre officiel reconnu, dont le nombre est
relativement limité). S'il s'agit par exemple d'un point géodésique en
France, la base de référence française est bien connue et c'est d'elle
qu'on tire l'identifiant externe. S'il s'agit d'un identifiant de société
ou d'un établissement de cette société, il n'y a que les identifiants au
RCS et SIREN+SIRET qui sont stables et fiables (mais eux aussi devrait être
datés), mais on peut ajouter le numéro fiscal européen.





Le 28 juin 2013 14:38, Pieren <pieren3 at gmail.com> a écrit :

> 2013/6/28 Ista Pouss <istaous at gmail.com>:
>
> > Quelqu'un avait rouspété que l'id se formait de façon obsure. Pas du
> tout !
> > À chaque id je suis capable de faire correspondre l'ID Overpass (car
> > j'utilise overpass).
>
> C'est quoi l'ID Overpass ? Comment fais-tu pour convertir la requête
> Overpass:
>
> http://overpass.osm.rambler.ru/cgi/interpreter?data=node%2845.38591285563495%2C4.306640625%2C45.48228066163947%2C4.51263427734375%29%5B%22shop%22%3D%22bakery%22%5D%5B%22name%22%3D%22La+baguette+magique%22%5D%3Bout%3B
>
> en un numéro "magique" "71435" ou ("stephboulange/71435") ?
>
> Est-ce que, comme le suggère Frederic, c'est juste un short-link, un
> hash-map stocké sur ton serveur ou celui d'overpass ? Cela veut-il
> dire qu'une autre instance d'overpass donnera un autre chiffre ?
> Est-ce que ça fonctionne encore si la requête retourne plusieurs
> objets ? Comment garanties-tu l'unicité si un autre objet contenant
> les mêmes caractéristiques apparait plus-tard dans le même
> bounding-box, ça marchera encore ?
>
> Pieren
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20130628/3420fd75/attachment-0001.html>


Plus d'informations sur la liste de diffusion dev-fr