[OSM-dev-fr] De l'utilisation des relations et l'identification métier

[François Lacombe]

Merci Pieren pour cette réponse.

Cette observation est sensée et j'ai oublié de dire que la plupart du
temps, je travaille sur une BDD hors OSM présentant le même modèle.
Des liaisons sont donc souvent faites avec les primitives OSM et mes
données mais il est difficile de les maintenir : les objets apparaissent et
disparaissent et leur identifiant OSM change.
Alors qu'un identifiant métier ne change pas, c'est pour moi un moyen plus
stable d’interfacer OSM avec d'autres référentiels, même si 95% des gens ne
s'y intéressent pas.

Quand je fais un push d'OSM vers ma base, un objet qui a changé d'id OSM va
provoquer la création d'une nouvelle entrée. Alors que si on avait un
identifiant métier dessus, ça n'arriverait pas et je pourrais même mettre à
jour avec la nouvelle id OSM.
Regarder la géométrie (si un nœud est à la même place avec un id différent
c'est le même qui a changé d'id) ? Pourquoi pas, c'est très bancal et si le
nœud a à la fois changé de place et d'id tout en représentant le même
objet, je fais quoi ?

Ceci étant dit, je comprends bien que les routeurs regardent avant tout la
nature des chemins et c'est bien légitime.
Comment tu affiches ensuite à l'utilisateur le nom de la route à prendre si
celui-ci est indiqué dans une relation dont la route est membre et non sur
la route elle-même ?
Il faudrait parcourir toutes les relations pour voir si la route est membre
de l'une d'entre-elles mais il doit bien exister un moyen plus optimal.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


Le 11 mars 2014 11:39, Pieren <pieren3 at gmail.com> a écrit :

> 2014-03-11 11:20 GMT+01:00 François Lacombe
> <francois.lacombe at telecom-bretagne.eu>:
>
> > Une fois l'itinéraire calculé, je vais avoir une succession de chemins.
> Pour
> > certains on aura un tag ref=* directement sur le chemin, d'autres seront
> > membres de relations supportant ref=*. Je dois pourtant le retrouver dans
> > tous les cas et trouver la relation dont un chemin est un membre n'est
> pas
> > vraiment facile avec le modèle OSM. Et surtout savoir quand chercher une
> > relation ou quand ne pas la rechercher est déjà difficile à déterminer
> (la
> > présence du tag ref=* sur le chemin ou non... mouai).
> >
> > Est-ce que des développeurs ont déjà réfléchi à cette question ?
>
> Je pense qu'il ne faut trop se baser sur la présence de certains tags
> et qu'OSM est avant tout une bdd géospatiale. Il faut distinguer les
> tags essentiels des autres. Les "essentiels" sont par exemple
> "highway=primary/secondary" ou "building=*". Ce sont ceux qui sont les
> plus persistents dans OSM car ils sont les qualitifcatifs et ceux qui
> "concernent" le plus de personnes. Les tags secondaires sont par
> exemple les "ref=*" car ils ont un intérêt moindre. Ils peuvent
> disparaître plus longtemps de la base.
> Ce que je veux dire, c'est qu'un logiciel de calcul d'itinéraire se
> basant sur OSM aura surtout intérêt à se baser sur la géométrie des
> objets (les ways) utilisant des tags essentiels (comme
> "highway=primary") et les coordonnées de départ/arrivée qu'à chercher
> la présence ou non d'un tag "ref" sur un way ou une relation.
> Pour revenir à ton questionnement originel sur un indentifiant métier,
> tu peux les mettre dans OSM mais ne pas espérer que beaucoup de gens
> s'y intéressent. Il y aura aussi un travail de maintenance
> (effacements accidentels, vandalisme) qu'il faudra que tu assumes si
> tu comptes t'en servir d'une manière pérenne. Ou alors, tu peux aussi
> décider de conserver tes identifants métiers hors OSM en faisant le
> lien avec ce qui t'intéresse dans OSM (voirie, bâti) par ce qu'il y a
> de plus permanent, c.a.d les tags "essentiels" (highway, building) et
> des coordonnées géographiques (soit un périmètre autours d'un point de
> référence, soit un périmètre en lui-même).
>
> Mes 2 cents,
> Pieren
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://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/20140311/6f97a0aa/attachment.html>