[OSM-talk-fr] Héritage et relation

[Vincent Pottier]

Le 24/05/2012 10:10, Nicolas Dumoulin a écrit :
> Bonjour,
>
> Le jeudi 24 mai 2012 09:36:53 Gilles Bassière a écrit :
>> Effectivement, si on veut être très rigoureux (notamment si on aime bien
>> le principe de normalisation relationnelle), on peut considérer que
>> "Tout est relation". Par exemple, les multiples tronçons d'une route
>> sont des ways non-taggés qu'on inclut dans une relations portant le
>> name= et le highway=.
>>
>> C'est une position cohérente d'un point de vue intellectuel, je l'ai
>> déjà lu ou entendu. Mais ça rend l'édition bien plus compliqué. C'est
>> pourquoi, en pratique, on continue à répéter les tags sur les multiples
>> tronçons d'une même rue. Le pragmatisme et la dé-normalisation sont dans
>> l'air du temps !
> Oui, nous sommes certains à y rêver :-) Que c'est moche d'avoir tous ces tags
> répétés. Comme c'est parfois hasardeux de modifier les attributs d'une voie
> sans en oublier un morceau … (bon ok, on s'en sort au pire en faisant une
> recherche).
> Mais effectivement, tant que nous n'avons pas des éditeurs qui permettent de
> gérer cela simplement, on ne peut pas y passer.
>
Ça n'est pas qu'une question d'éditeurs, mais de modèle de donnée.
OpenStreetMap n'est pas tout à fait une base de données à objets, ou 
plus exactement, c'est une base de donnée à objets [1], mais on ne sait 
pas exactement ce que sont ces objets.

L'exemple de la route est typique.
Si le formalisme d'OSM était rigide, toutes les routes seraient 
contruites sur le même modèle :
- soient des ways simples comportant tout l'information : sémantique et 
géométrie (c'est le modèle de départ d'OSM)
- soient des relations portant la sémantique et des ways pour la 
géométrie et on aurait une couche ORM pour récupérer les données et les 
présenter comme objets.

Pour des raisons historiques et pratiques, les deux modèles sont 
mélangés dans la base de donnée.
- Pour l'avenue Machin, tronçonnées pour les sens interdits, les pistes 
cyclables, les relations de bus, les adresses postales, les Y à l'abord 
d'un rond-point...Le modèle relation+ways s'impose.
- Mais pour le "chemin des choux" qui mène dans la garrigue, le seul way 
suffit avec le nom, le ref et la géométrie.

Quand on veut obtenir un objet "Rue Machin", on risque donc de récupérer 
une collection : la relation globale et les tronçons.
Plus les "associatedStreet" et autres exotismes...

Le flou sur la représentation de l'objet "Rue Machin" est une 
difficulté, pour l'édition, le traitement... mais aussi une souplesse 
pour la créativité.

Les éditeurs essaient de tenir compte de ce flou, laissant à l'humain de 
déterminer s'il doit traiter une relation ou un way simple.

Ce que savent bien faire les machines, c'est de repérer que tel way, 
c'est du "highway=tertiary" et d'en tenir compte pour du routage.
Par contre de déterminer ce qu'est l'Avenue des Champs-Élysées [3], avec 
ses chaussées séparées, son rond-point au milieu, ses trottoirs, ses 
adresses, ses passages pour piétons, ses jardins et bassins, ses arrêts 
du bus et stations de métro, son serial-killer tunnel [4]... du 
surfacique, du linéaire, des interruptions, des associations... Pas 
simple...

Pourtant, les logiciels de routage s'en débrouillent, mapnik aussi.

Les représentations ne sont pas encore assez avancées pour qu'un modèle 
d'objets et interfaces (ou duck-typing) : linéaire pour le routage, 
surfacique pour la cartographie, associations pour les POIs... émerge et 
qu'une couche ORM se construise pour les éditeurs. On y vient avec les 
APIs, notamment XAPI [5].

Ça viendra... patience


[1] http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_orient%C3%A9e_objet
[2] http://fr.wikipedia.org/wiki/Mapping_objet-relationnel
[3] http://osm.org/go/0BPIIMGO4-
[4] http://www.2m40.com
[5] http://taginfo.openstreetmap.org/tags/name=Avenue des Champs-Élysées
http://overpass-api.de/api/xapi_meta?*[name%3DAvenue+des+Champs-%C3%89lys%C3%A9es]
--
FrViPofm