[OSM-talk-fr] Les itinéraires : (était : Tour de France 2011)

Guilhem Bonnefille guilhem.bonnefille at gmail.com
Mar 12 Juil 11:59:06 UTC 2011


Le 12 juillet 2011 12:34, Eric Sibert <courrier at eric.sibert.fr> a écrit :
>> A titre personnel, je pense que "tous" les itinéraires devraient aller
>> dans
>> une base séparée tant ces itinéraires sont gênants pour les éditions de
>> base
>
> Personnellement, j'ai aussi tendance à penser que les itinéraires devraient
> être dans des bases à part s'appuyant sur OSM, pas uniquement pour des
> questions d'édition mais parce qu'on a à faire des constructions
> intellectuelles fluctuantes. C'est la réflexion que je me faisais à Noël
> quand je mettais à jour le plan des pistes de ski de fond d'une station.
> Chaque année, ça change. Oui, dans les champs, tu les fais passer où tu veux
> les pistes. Dans la forêt, par contre, ça suit des chemins sous-jacents
> qu'on retrouve une fois la neige fondue. Donc de mon point de vue, les
> éléments suivants auraient plus leur place dans des bases externes:
> - pistes de ski
> - ligne de bus (mais arrêts et couloirs de bus dans OSM)
> - lignes de tram (mais arrêts et voies dans OSM)
> - itinéraires routiers Bis, Vert...
> - itinéraires vélos
>
> Après, on peut se demander jusqu'où aller. Les limites administratives? Les
> limites de communes ne sont pas très fluctuantes. Mais on pourrait se
> demander si les EPCI et autres syndicats intercommunaux à vocations
> multiples ou uniques ont leur place. Les liaisons maritimes par ferry? C'est
> nécessaire pour les applications de routage. Néanmoins, suivant la
> fréquence, ça ne peut pas vraiment s'assimiler à une route. Un temps de
> calcul de parcours qui ne tient pas compte des trois jours d'attente du
> ferry hebdomadaire... Idem ferroutage.

Je trouve le sujet particulièrement délicat. Il faudrait surtout
définir à quoi ça peut bien servir de séparer les bases de données.
D'un certain point de vue, les données sont déjà séparées (ou
séparables) puisqu'utilisant des entités différentes (type de
relation). La solution actuelle est la plus simple et fait déjà
ressortir des problèmes lors de l'édition. Je pense qu'en séparant les
bases, les problèmes seront encore plus complexes.

Mais il me semble que les usages évolues aussi. Par exemple, j'ai
récemment consulter le moyen de tagger un radar de vitesse. Et j'ai
été surpris de découvrir qu'il s'agissait d'une relation incluant 3
noeuds (oui oui, des noeuds, pas des voies). Je vois assez facilement
à quel point ça simplifie le mapping et réduit les conflits d'édition
(y'a juste ces 3 noeuds à préserver, pas des ways entières). Du coup,
peut-être qu'un solution pour les relations de type "route"
consisterait à évoluer vers ce schéma : la route contient quelques
noeuds et le tracé est calculé en retrouvant les way qui permettent de
joindre les noeuds en question. Du coup, fini les problèmes de
split/fusion de way, d'inversion du sens de la way...

> Un jour, il faudra répondre à la question : qu'est-ce qui va dans OSM et
> qu'est-ce qui n'y va pas?

Personnellement, je trouve que cette question a du sens. Mais je ne me
la pose pas tant sur les notions d'information concrète ou abstraite.
Aujourd'hui, je me demande ce que l'on peut y stocker :
- uniquement des éléments réels ? Par exemple, puis-je y mapper l'Atlantide ?
- uniquement des éléments visibles ? Par exemple, galeries de grottes,
tunnel métro, canalisation, réseau électrique enterré...
- uniquement ce qui dure dans le temps ? Par exemple, une discussion
récente a abordé la question de la praticabilité des chemins, mais
quid des sens de circulation qui changent, finalement, assez souvent,
ou de la position des ralentisseurs, passages piétons, pistes
cyclable...

> Actuellement, le problème des bases externes, c'est comment les relier à
> OSM. Répondre à ce problème pourrait aussi faire avancer le schmilblick.

Si les bases sont disjointes, il me semble que la réponse est simple,
au risque d'être simpliste : les id + changeset/version d'élément.
Les Id pour savoir de quoi on parle.
Les changeset/version d'élément pour repérer l'état (position, valeur
des tags) de l'élément pointé dans le temps.

J'ai peur qu'on ne puisse pas vraiment faire plus. Par exemple,
impossible d'envisager de contraindre la base centrale avec les bases
annexes car le modèle ne tiendrait pas avec l'évolution du nombre de
bases annexes, ou finirait par défavoriser des bases officieuses par
rapport à des bases officielles (et en libriste que je suis, je n'aime
pas les solutions qui privilégient certains utilisateurs par rapport à
d'autres).

En tout cas, et je ne pense rien apprendre à vous autres, ces
réflexions/expériementations sont de plus en plus nécessaires. Avec le
temps, OpenStreetMap fait son chemin et devient de plus en plus
crédible. Ce qui nous rapproche de plus en plus d'un nouveau type
d'utilisateurs, qui ont un SIG et qui veulent bien contribuer à
condition qu'on leur offre des outils de synchronisation et le moyen
de stocker de l'information qui leur est propre et qui s'appuie sur
les données OSM.

Bref, va falloir inventer l'équivalent de Git, mais pour OSM. :-)
-- 
Guilhem BONNEFILLE
-=- JID: guyou at im.apinc.org MSN: guilhem_bonnefille at hotmail.com
-=- mailto:guilhem.bonnefille at gmail.com
-=- http://nathguil.free.fr/




Plus d'informations sur la liste de diffusion Talk-fr