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
_______________________________________________
Talk-fr mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-fr
