Faire évoluer le modèle de données d’OSM : consultation de la communauté en cours

Contribuer
#1

Bonsoir à toutes et à tous,

Il y a 6 mois, après le SOTM monde où des réflexions pour l’évolution du modèle de données d’OSM avaient été présentées, nous avions pu échanger ici à propos de ces visions.

Dans un billet de blog d’hier, Courtney Williamson indique qu’une consultation s’ouvre pour recueillir les commentaires de la communauté vis à vis de perspectives d’évolutions qui se dégagent désormais depuis le SOTM.
https://blog.openstreetmap.org/2023/01/04/reminder-call-for-feedback-on-the-data-model/

Cette consultation est destinée à définir les prochaines étapes au regard des propositions formulées précédemment.
En voici une synthèse qui se contente d’exposer les arguments du billet de blog.

Une définition plus fiable des polygones
Actuellement, chaque outil interprétant des données doit déterminer si tel ou tel chemin clos est un polygone ou non. Ceci pouvant avoir des impacts importants sur l’expérience d’édition ou bien d’utilisation des données.

Il semble nécessaire d’ajouter une primitive area en plus des node/way/relation habituels pour expliciter ce qui est un polygone ou qui ne l’est pas jusque dans les données brutes.
Cela permettra d’assurer la cohérence des traitements d’un outil à l’autre et aussi à l’API principal de vérifier que les objets devant être des zones ne sont pas cassés (par exemple).

Assurer des traitements légers et accessibles
Le modèle de données actuel, relationnel et topologique, a les avantages que nous connaissons tous mais oblige à une gymnastique de plus en plus coûteuse en arrière plan, notamment pour traiter les données brutes. Ce que font osm2pgsql et imposm par exemple.
Ces coûts semblent croître plus rapidement que les progrès du matériel disponible.

C’est le fait de devoir résoudre les identifiants de nœuds constituant un chemin à chaque fois qui prend par exemple de plus en plus de temps.
Au lieu de cela, il serait possible de migrer vers une base de données géographique, associant une géométrie à chacun des objets contrairement à maintenant où la seule géométrie est celle des nœuds.

Disposer de telles géométries permettrait de paralléliser les traitements qui ne sont que séquentiels aujourd’hui (on traite les nœuds, puis les chemins, puis les relations - jamais tout en même temps parce qu’ils dépendent les uns des autres).

C’est une évolution lourde de conséquence. Les nœuds ne seraient plus attachés explicitement aux chemins. Ils seraient attachés « parce qu’ils se trouvent pile dessus » en quelque sorte. C’est à dire qu’un sommet du chemin coïnciderait avec un nœud.
Nous n’aurions plus de nœuds sans tags (actuellement 98% des nœuds n’ont pas de tags et ne sont là que pour servir de sommets aux chemins).

Disposer d’un historique plus accessible
Le côté topologique de la base de données a aussi des implications sur l’accessibilité des historiques.
Puisque seuls les nœuds sont porteurs de coordonnées, il est difficile d’accéder à la représentation d’un chemin d’il y a 2 versions avant l’actuelle.

Avec l’évolution proposée vers une base de données géographique, il serait en outre possible de disposer des géométries d’anciennes versions de chaque objet très facilement.
Autrement dit, de faire sortir OSMCha du domaine de la rocket science et de l’intégrer durablement à l’interface d’osm.org

Produire plus facilement des tuiles vectorielles
La production de tuiles vectorielles (en opposition aux tuiles bitmap que nous connaissons aujourd’hui via le rendu monde) nécessite elle-aussi de résoudre les dépendances chemin/nœuds pour produire des géométries.

Disposer des géométries directement dans la base permettrait non seulement d’accélérer leur production mais aussi leur mise à jour. Puisque ces géométries voyageraient aussi dans les fichiers différentiels (minute / daily …)

Pour les anglophones, vous êtes cordialement invités à donner votre avis sous la forme d’issues sur ce dépôt

Pour les francophones, discutons-en ici afin de raffiner une position commune sur ces propositions

Bonne soirée.

4 Likes
#2

J’avoue ne pas bien comprendre (mais je ne sais rien de la représentation des données dans la base).
Quand je crée un bâtiment avec iD, je crée une surface et je lui attribue un type «bâtiment ».
Faut-il comprendre l’ensemble de nœuds correspondant ne possèdent pas un attribut « bâtiment » permettant de savoir qu’ils font partie d’un polygone, mais que iD reconstruit cet objet à chaque fois ?

#3

Merci @InfosReseaux pour le résumé clqir et concis. Cependant, il n’y a là que des avantages de présenté, qu’en est-il des inconvénients ? Ie quels sont les avantages à cette modélisation purement topologique des données ? Je ne connais pas trop, mais est-ce que d’autres bdd géographiques utilisent le m^me modèle de données qu’OSM ? SI oui / non, pourquoi ?

Est-ce qu’il y a des reflexions, puisque ce serait un énorme changement pour OSM, d’augmenter la mémoire allouée aux coordonnées géo des objets pour augmenter la précision en x,y (qui n’est de mémoire que de l’ordre du centimètre, peut-être est-ce un frein pour certaines utilisations). Et de rajouter une coordonnées z ? (Tant qu’on est dans les chamboulements …)

#4

Bonsoir

C’est plus simple que ça.
Quand on créé un bâtiment sur iD, on créé un polygone et on lui ajoute les tags approprié pour le qualifier comme un bâtiment.
A aucun moment on a dit si c’était un périmètre fermé ou une surface pleine, les deux existant avec la même géométrie.
C’est l’éditeur qui sait que building=yes est équivalent à une surface et highway=unclassified à un périmètre fermé suivant le parcours d’une route.

Les inconvénients sont de mon propre opinion.
Dans une base géographique, il n’y a pas de connexion au sens où nous le connaissons aujourd’hui.
Donc pour placer un dos d’âne sur la route, il faudra en permanence s’assurer de la cohérence de la position du dos d’âne lui-même par rapport à celle de la route. Ce sera aux éditeurs de faire ce travail, mais que se passera-t-il si l’un d’entre eux ne respecte pas ce contrat implicite ?
On aura alors les moyens de casser des choses qui ne peuvent pas l’être aujourd’hui dans la base topologique.

l’API principal ne repose pas une base de données géographique. C’est une base relationnelle que je présente comme topologique.
Le rôle d’outils comme osm2pgsql est justement de dénormaliser les données et produire une base de données géographique exploitable pour d’autres usages.
La topologie est justement utile pour maintenir ensemble par construction les objets qui doivent l’être (le passage piéton sur la route, la ligne électrique sur le poteau, la vanne sur la canalisation…).

Je ne l’ai pas vu abordé, mais pourquoi pas.

L’ajout de la coordonnée z ne dépend pas que de la base de données. Il faut des éditeurs capables de la manipuler et nous n’avons pas ça. Que se passe-t-il quand nous travailleront sur une base 3D avec un éditeur strictement 2D ? Difficile je pense.

#5

Il n’est que moyennement topologique , je m’explique : on a un mélange de surfaces et de linéaires.
Typiquement un bois est du surfacique et une route est du linéaire. La route, la chaussée et les fossés et bas-côtés plus précisément touchent le bois. Comme route, chaussée et fossés sont représentés par un trait, pour que le bois touche la route il faut partager les points « communs ». Certains le font, d’autres pas (chacun pour des bonnes raisons).

Une base de donnée vraiment topologique comme les cartes marines électroniques S-57/S-101 est effectivement plus difficile à éditer, car tu commences par définir les points (isolés ou non) puis les chemins - edge pas way - (suite de points non isolés). Les surfaces et les objets linéaires se basent sur ces chemins, les surfaces étant orientées de manière horaire (donc utilisant des chemins en précisant si le chemin est direct ou indirect) - anti-horaire pour les trous -, permettant des rendus orientés vers l’intérieur ou l’extérieur.
C’est plus difficile à éditer, par contre c’est plus facile pour faire des mises à jour (c’est la raison du choix du format : tu déplaces des points, ajoutes/supprimes/modifies des chemins ou des fonctionnalités).
D’un point de vue traitement, les cartes sont indépendantes (à une échelle donnée) et sans recouvrement - par les identifiants on sait qu’un polygone par exemple est commun à deux cartes qui se touchent (et aussi que dans des résolutions différentes il s’agit du même objet).
Du coup j’ai du mal à comprendre l’histoire de la parallélisation. https://osmdata.openstreetmap.de/ est un exemple de données OSM éclatées en tuiles vectorielles.
Tu cliques sur un point avec QGIS et tu verras que la division administrative est respectée.

Du coup je me dis : est-ce que c’est l’introduction du type area qui est intéressant ou la découpe en pavés réguliers avec des « points de colle » pour recoller les éléments présents sur plusieurs tuiles ?
Oui c’est une question ouverte.

#6

Non, il n’y a pas de surface à ce niveau dans OSM.
Les surfaces sont déduites des attributs de certains polygones définis comme un chemin fermé, cf ce que j’explique au dessus.

Il est justement proposé de créer un nouvel objet « surface » pour lever la déduction basée sur les attributs.

Ceci change sensiblement le reste du message :slight_smile:

#7

OK.
Dans les normes S-57 et S-101, il y a un type linéaire et un type surfacique, donc l’introduire n’implique pas de casser le modèle topologique.
Donc on peut ajouter un type area sans tout casser (et effectivement ça change le sens du mesage).

#8

Oui, si la proposition n’était que de créer le type surfacique, cela ne poserait pas tant de problème.

Une seconde proposition est faite : abandonner les nœuds comme sommet des chemins.
Celle-ci force à ce que chaque objet dispose de sa propre géométrie et transforme la base en base de données géographiques.
Avec l’inconvénient de distribuer la vérification de la cohérence entre les différents objets pour maintenir les connections entre eux (un passage piéton sur une route, un passage à niveau au croisement d’une route et d’une voie ferrée, etc…). C’est un point très structurant et j’ai pas encore lu de solution à chacun de ces points.

#9

Là encore on est d’accord : là on casse bien tout, on a déjà eu assez de soucis avec les éditeurs et les relations, faut-il remettre un sous dans la machine ? Oui, là, la question est fermée !

#10

Je ne suis pas sûr de bien saisir ce que ça implique, mais de ce que je comprends, je suis un peu inquiet du résultat sur des zones très chargées, et multi niveaux comme les grandes gares.
En d’autres termes, est-ce que ce modèle est tenable sans ajouter des couches ?

#11

Quand on créé un bâtiment sur iD, on créé un polygone et on lui ajoute les tags approprié pour le qualifier comme un bâtiment.
A aucun moment on a dit si c’était un périmètre fermé ou une surface pleine, les deux existant avec la même géométrie.

Dans ce cas, pourquoi ne pas simplement gérer ces attributs manquants qui serait déduit du type : une clôture = ligne fermée, un parking = surface ?

Pour éviter la redondance, une table de relation type polygone <> type géométrie me parait envisageable.

#12

Ma lecture c’est que cela permet de ne pas mélanger l’API et le tagging. Qu’un certain tag soit valable en tant que surface ou area cela est décidé par la communauté, à chaque éditeur de faire les vérifications nécessaires avant l’upload. Un type area permet à l’API de le refusé s’il y trouve une erreur, sans lien avec le schéma de tagging.

#13

C’est comme cela que cela fonctionne aujourd’hui, chaque utilisateur (pour le rendu d’une carte, le calcul d’itinéraire…) a sa propre table de correspondance dans son coin.
Exemple :

Ça marche, mais c’est pataud.

#14

Remarque en passant : la précision en x,y peut difficilement être au centimètre en raison de l’absence de base d’appui à cette précision, ou de levers GPS professionnels. J’imagine qu’il s’agit d’un affichage de décimales non significatives.
La précision d’OSM (en France) doit se situer entre quelques mètres et disons dix à vingt mètres à cause de l’imprécision du cadastre et donc des bâtiments.

#15

A la lecture des différents commentaires :

  • il faut « toucher d’une main tremblante » au système d’origine, il a fait ses preuves;
  • les impacts paraissent nombreux et variables sur l’aval. Cela signifie habituellement qu’on ne pourra pas tous les cataloguer et qu’il y aura des effets de bord inattendus.
    Pas glop.
  • de plus, il me semble que ce serait incorporer dans la base elle-même des contraintes liées à certains usages. Comme le dit @Ydel, éviter de mélanger API et tagging.
  • dit autrement : quel est le coût de ne rien faire?
  • ne vaut-il pas mieux laisser les usagers qui en ont besoin définir les outils dont ils ont besoin plutôt qu’intégrer et donc de prioriser certains en dur?
  • en quoi cette évolution (que je vois comme un rapprochement des canons de l’infogéo) contraindrait-elle le futur?
  • Venant des BD géo, le modèle OSM m’a paru considérablement plus simple à saisir pour un néophyte. Il serait dommage que les géomaticiens exportent leur compétence et leurs habitudes dans un écosystème qui n’en a pas besoin, je rejoins ici Steve Coast cité par @InfosReseaux en juin « OSM’s design is simple but it’s also a little chaotic for the same reason that it’s simple: It’s a mirror of the human world, which after all is chaotic. »
3 Likes
#16

Pour complérer : officiellement on travaille en WGS 84 - WGS84 - World Geodetic System 1984, used in GPS (les coordonnées GPS) : précision 2 m.
En fait les othophotographies sont en RGF93 v1 / Lambert-93 + NGF-IGN78 height.
Là c’est plus précis (le système suit la dérive des continents). Mais les valeurs ne sont pas les mêmes.
Et comme @Mens_Data le souligne, le cadastre est moins précis car issu initialement de plans papier dont le but est de taxer le foncier : la position exacte n’est pas le souci premier de l’administration fiscale. Il suffit de parcourir le cadatre à la limite entre communes pour voir des sautes dans le cadastre.
Pour avoir une précision décimétrique voir centimétrique, effectivement il vaut un relevé de qualité professionnelle (GPS RTK par exemple) ou de partir des relevés géodésiques de l’IGN et consorts pour travailler en relatif par rapport à ces points.
Donc augmenter le nombre de chiffres permettrait dans le futur d’améliorer la précision mais actuellement de faire croire à une fausse précision.
Si on veut avoir cette hautre précision il faut replacer quasiment tous les points dans OpenStreetMap. Ce ne peut être qu’une amélioration progressive.

#17

Qu’est-ce qui empêche de centraliser un style par défaut (pour cette partie, quitte à changer le formalisme) et que les utilisateurs partent de là ? Question ouverte.

#18

Il ne faut pas mélanger la précision absolue et relative.
Si on s’amusait à supprimer des décimales sous prétexte que la précision absolue d’Osm n’est que métrique, on risque d’avoir quelques soucis pour dessiner des giratoires qui soient rond. Dans le même ordre d’idée, ça deviendrait impossible de positionner précisément un obstacle sur un trottoir dessiné en surfacique.
Donc non, il ne faut pas utiliser la précision absolue pour déterminer le nbre de décimales nécessaires.

Il suffit d’utiliser la BD ortho pour avoir une précision absolue inférieure au mètre.

1 Like
#19

On est d’accord. Je dis juste qu’il ne faut pas prendre ça pour de la précision absolue.

#20

Mais augmenter la possibilité ne changerait à rien à la situation actuelle : aujourd’hui plein d’objets ont une précision bien moins bonne que possible. On voit parfois des objets décaler de plus de 10 m ! Donc augmenter l’espace de stockage pour les x,y, permettrait d’avoir de nouveaux usages sans rien changer (si ce n’est la taille de la bdd …)