Forum OSM France

Faire évoluer le modèle de données d'OSM : vraies questions

Contribuer
#1

Salut à tous et à toutes,

J’ai souhaité ouvrir ce fil ici pour rassembler quelques idées autour des évolutions du modèle de données d’OSM, sujet qui est régulièrement débattu au niveau mondial et dont il est difficile de trouver une synthèse construite.

OSM emploie beaucoup de logiciels et l’un d’eux a une importance plus grande que les autres : l’API principal, couplé à la base de données permet à beaucoup d’autres de fonctionner. Nous utilisons la version 0.6 depuis 2009. Si des évolutions techniques ont eu lieu depuis 2009, tout cela s’est fait à iso-fonctionnalité.

Le modèle de données qui lui permet de fonctionner, le fameux Les nœuds sont les seuls porteurs de coordonnées, parfois arrangés en chemins, eux-même éventuellement membres de relations, n’a pas été remis en cause. Vous vous doutez bien que les demandes d’évolutions de l’API et de la base de données sous-jacente sont nombreuses.

Soucieuse d’étudier la pertinence de certaines demandes, la fondation a récemment mandaté Jochen Topf pour mener une étude d’opportunité. Elle pourra conduire ou non à certaines évolutions à déterminer. On ne va pas encore casser OSM.

Jochen explique dans un billet de blog que notre modèle de données n’est pas facilement appropriable par les consommateurs, habitués aux modèles plus complexe des SIG. L’absence d’évolution ne permet pas à OSM de rester agile face à de nouveaux défis.

Steve Coast, entre autres, a répondu par un autre billet de blog, défendant la simplicité et la stabilité des fondations de l’API. Il s’agit selon lui de questions de conception et d’adéquation avec les besoins d’une majorité de consommateurs qui aujourd’hui traitent sans encombres les données d’OSM.

Pour ma part, mon usage d’OSM n’a pour l’instant atteint les limites du modèle actuel qu’une fois, lorsqu’il aurait fallu ajouter des tags aux membres de relations, pour faire porter plusieurs références à un même nœud.
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Power_routing_proposal#circuit_dependent_pylon_numbers

Cela me rappelle enfin certains points abordés hier dans la présentation de @overflorian sur la nécessaire évolution d’OSM.
Il faudra veiller à poser correctement le pour et le contre et ne pas tomber dans les travers d’évolutions forcées ou de solutionnisme pour des problèmes qui n’existent pas.
Si telle ou telle évolution est décidée, il faudra enfin veiller à ce que la solution retenue soit intégrée au bon niveau, entre la base de données et le post-traitement des consommateurs, bien en aval.

Au plaisir d’en discuter ici au gré de nos expériences respectives.

#2

Personnellement, ce qui m’a perturbé dans l’apprentissage d’OSM ces deux dernières années n’est pas tant le modèle lui-même que son interprétation, et les conséquences que cela a dans les tags.

Je partage ici l’interprétation qui m’est venue naturellement dans les premières semaines : à la base tout est relation, et on a isolé deux types de relations à qui on a donné un statut particulier, les nœuds et les chemins. Ce sont en quelque sorte des « relations pré-compilées », tellement standard qu’elles sont codées en dur dans la base de données.

Certains trouveront que c’est de la philosophie, de la pure théorie. Mais :

  1. si cette interprétation correspondait à la réalité, elle serait beaucoup plus simple à expliquer que l’actuelle. A titre d’exemple, qu’un way OSM ne soit pas nécessairement un chemin qu’on peut parcourir sur le terrain, mais n’importe quel polygone et par exemple un contour de bâtiment, c’est complexe à absorber ;

  2. je n’ai pas d’exemple sous la main à l’instant, mais il me semble que certains schémas de tags seraient plus facile à définir et à expliquer si on avait une interprétation de ce type en tête.

  3. cela pourrait servir de base à des évolutions maîtrisées du modèle, en introduisant de nouveaux types sur la base des tags. Par exemple, on pourrait décider un jour qu’un objet « building » est défini comme une relation contenant une géométrie associée à quelques tags obligatoires.

  4. cela permettrait peut-être de donner un statut clair aux areas ?

Voilà, rien de très construit à ce stade, mais l’expression d’une gêne devant un modèle sur lequel mes intuitions, mes extrapolations d’informaticien, ont souvent échoué.

#3

Bonsoir Stéphane,

Ce n’est pas possible ainsi : les nœuds n’ont pas de membres et les way ne peuvent pas définir de rôle sur leurs nœuds. Si les noeuds et les way héritaient de relation (au sens osm), ils auraient également ces propriétés.

Est-ce intrinsèquement complexe ou en raison de pratiques pré-existantes différentes ? Dans le deuxième cas, on est pas obligé de les suivre en proposant une approche plus minimaliste.

C’est déjà le cas : les tags sont définis avec une affinité distincte entre les chemin ouverts et les polygones, sans avoir besoin de définir une ou plusieurs primitives supplémentaires.

Je ne comprends pas : n’est-ce pas déjà le cas ?

#4

Pour les membres ce n’est pas un problème : il suffit d’admettre 0 comme nombre possible de membres. La notion de rôle, que j’avais oubliée, est plus embêtante. Tu as raison, cela disqualifie les relations comme cadre commun ; mais à mes yeux, il manque ce cadre commun d’interprétation.

De pratiques et de terminologie. Avoir un way avec highway=path, et un autre avec building=yes, c’est un problème qui commence avec le mot « way ».

Nous ne nous intéressons pas au même critère. Le mien ici, c’est la complexité d’apprentissage. Du moins, telle que je l’ai mesurée sur mon propre apprentissage.

Dans l’API, c’est un way (https://wiki.openstreetmap.org/wiki/Way). Pour le non-spécialiste des SIG, un way c’est autre chose (Way - Wikipedia). Tout dépend de qui on veut impliquer.

#5

Cela risquerait de laisser des relations vides persister dans la base, c’est un risque puisqu’en plus il est difficile de les rattraper en édition si elles n’ont pas de membres au travers desquels exister.

A la rigueur on pourrait définir une quatrième primitive « area », mais complexifierait l’édition en obligeant le contributeur à choisir explicitement l’un ou l’autre. Sera-t-on gagnant ?

Si cette complexité d’apprentissage est due à des pratiques différentes, sommes-nous alors tenus de les reproduire pour que ce soit simple ? Vous avez 4 heures :slight_smile:

Pour le spécialiste des SIG aussi, c’est tout autre chose (les SIG distinguent linestring et polygon)
OSM n’ayant pas grand chose à voir avec un SIG traditionnel, tout le monde peut confondre le terme.

On aurait pu choisir un autre nom, polyline par exemple.

J’ai du mal à comprendre comment associer une géométrie dans une relation serait plus simple à appréhender que ce que nous faisons en ce moment. Éditer une relation est coûteux et on a pas trouver de moyen commode pour le faire, il y a sûrement une raison.