[OSM-talk-fr] Sous relations itinéraires cyclables

[Philippe Verdy]

le gros désavantage de créer des hiérarchies avec des références entre
relations exactement de même type, c'est qu'il est facile de créer des
référence circulaires.
Avoir des types différents évite totalement ce problème puisque la
hiérarchisation est imposée par le type ce qui permet des requêtes plus
spécifiques en sachant par où commencer une recherche de hiérarchie et dans
quelle dirction chercher les composantes ou les relations parentes. Cela
fige aussi le nombre de niveaux à scanner.

Si tout est du même type, on ne sait pas si on doit chercher en amont ou en
aval, donc on fait les deux directions, et en fin de compte on se retrouve
avec même plus forcément une hiérarchie mais un maillage (un mesh) formant
un réseau en fait sans plus aucune direction. Comment alors savoir de quel
itinéraire on parle?

Et ce sera très lourd à maintenir (et bon nombre d'outils ne sont pas près
à faire des recherches de ce type s'ils ne savent pas détecter les
références cycliques.

Bref si type=route représente un itinéraire complet, peut-être faudra-t-il
pour les étapes de l'itinéraires créer un type=subroute ou
type=route_fragment, puisque cette subdivision est en fait arbitraire (la
remarque vaut aussi pour les très longs itinéraires routiers euroasiatiques
(routes "E nnn") dont la plus longur va du Portugal au Japon avec des
étapes maritimes par ferries, en passant par de nombreux pays). Les routes
eurovélo sont aussi assez longues et compliquées (en plus du fait qu'elles
sont souvent des projets où il manque des sections dans des secteurs où
l'évaluation de cyclabilité n'a pas été évalue sur le terrain ou qui
n'existent pluis ou ne sont plus praticables, et qui obligent alors à
trouver d'autres moyens de transport que le seul vélo, ou emprunter des
routes pas faites du tout pour les vélos et pouvant même être dangereuses,
ou des routes qui sont maintenant interdites aux deux roues et qui
obligeront à transiter par un véhicule à moteur ou prendre un transport en
commun)

De plus certaines sections bien que cyclables sont très sportives et
demandent un entrainement ou un matériel adapté en tout terrain, ce ne sera
pas juste du cyclotourisme ou la route des enfants pour le chemin de
l'école ou aller chercher le pain au village d'à côté, et si l'itinéraire
c'est un des cols du Tour de France, ce ne sera pas pour le cycliste du
dimanche qui ne pourra pas aller jusqu'en haut (de plus les routes de
montagne vers les cols sont dangereux avec les autres véhicules qui peuvent
y circuler: le tout de France lui passe par des itinéraires protégés fermés
à la ciculation des cars, des camions, ou des voitures de tourisme ou des
caravanes, mais pire que la montée c'est la descente qui est très
dangereuse)


Le 1 juillet 2015 13:52, Jo <winfixit at gmail.com> a écrit :

> Pour le transport en commun le route_master représente une ligne, tandis
> que les route représente différentes variations des itinéraires en fonction
> de l'horaire.
>
> Pour le transport en commun il ne serait pas une mauvais idée de découper
> les routes en leurs composants. Cela permettrait de réutiliser les
> 'morceaux' communs.
>
> Il y a des avantages, comme le maintien qui devient plus facile et le fait
> que les ways ne doivent plus être membre dans une centaine de relations
> pour les axes importants.
>
> Il y a des désavantages. Ça devient un peu plus complexe, mais surtout il
> n'y a pas de support des programmes d'édition des données et sans cela ça
> devient à nouveau plus difficile de vérifier à vue si l'itinéraire est
> continu. MapCSS a des problèmes également, pour l'instant.
>
> Jo
>
>
> 2015-07-01 12:36 GMT+02:00 Philippe Verdy <verdy_p at wanadoo.fr>:
>
>> Une relation de type route qui inclue d'autres relations de même type ?
>> Ne devrait-ce pas être plutôt une relation de type route_master référençant
>> des relations de type route comme pour les réseaux de transport type bus ou
>> train ? En quoi cela doit-il être différent pour les réseaux en vélo?
>>
>>
>> Le 1 juillet 2015 11:47, GaelADT <gael.sauvanet at gmail.com> a écrit :
>>
>>> RainerU-2 wrote
>>> > je vois que votre stagiaire a commencé de fractionner les relations
>>> > bicycle en "étapes" (voir mon post sur la V81). Quand vous créez des
>>> > nouveaux relations il y a rien à dire la dessus. Mais supprimer des
>>> > relations qui sont souvent le fruit d'un travail de terrain de nombreux
>>> > contributeurs, les récréer sur las base des données ON3V qui ne
>>> > reflètent pas toujours la réalité du terrain, cela frôle le vandalisme.
>>>
>>> L'existant a seulement été déplacé dans des sous relations :
>>> http://www.openstreetmap.org/relation/3264259
>>>
>>> Rien de l'existant n'a été supprimé.
>>> Un gros travail de suppression de doublon a été effectué, car les données
>>> étaient loin d'être en "bon état". J'appelle plutôt cela un travail de
>>> mise
>>> en valeur des données car rien n'a été modifié, l'existant a été gardé.
>>>
>>> Si la modélisation en étape ne convient pas effectivement on le gérera de
>>> notre côté en interne, aucun soucis avec ça et nous remettrons donc des
>>> grandes relations énormes impossibles à gérer :)
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://gis.19327.n5.nabble.com/Sous-relations-itineraires-cyclables-tp5848869p5849264.html
>>> Sent from the France mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150701/272433fb/attachment.htm>