[OSM-talk-fr] Topographie physique du métro parisien

hamster hamster at suna.fdn.fr
Lun 14 Déc 16:41:41 UTC 2009


Jean-Marc Liotier a écrit :
> hamster wrote:
>   
>> si quelqu'un connait un moyen d'avoir le trace des 
>> couloirs pietons dans les stations de metro pour pouvoir
>> estimer le temps de marche aux changements ca serait un
>> plus enorme
>>     
>
> Si on souhaite rapidement disposer d'un calculateur d'itinéraires en
> transports en commun, je crois qu'un modèle simplifié est nécessaire
> dans l'intérim - un intérim qui risque d'ailleurs de durer vu la
> complexité affreuse d'un modèle physique complet des stations de métro,
> quoique qu'on est jamais à l'abri d'un maniaque tachéomètre trompant son
> ennui.
>
> En abstrayant la réalité physique, on peut raisonner strictement en
> temps de parcours. Par exemple avec un modèle dont l'objet central n'est
> pas la gare mais le quai. On peut passer d'un quai à l'autre par un
> métro par exemple s'ils sont reliés par une ligne - ou à pied si les
> deux quais sont dans la même station. On a donc un réseau où les
> segments sont les liens entre les quais, qualifiés par un temps de
> parcours quels que soit le moyen de transport - et on peut alors
> calculer un itinéraire en parcourant la matrice représentant la
> connectivité du réseau.
>
> J'ai donc l'impression qu'en attendant la navigabilité du modèle
> physique des stations de métro, la solution au problème du routage dans
> les transports en commun restera extérieure à OpenStreetMap. Quelqu'un
> avec de l'expérience du domaine le dit d'ailleurs à
> http://wiki.openstreetmap.org/wiki/Train_routing#Does_it_belong_to_the_map.3F
>  : "I've done some routing before [..] and the map info seems very
> auxiliary. You can route very well if you have time tables but not map.
> Map would be slightly useful to display proposed track, but it seems
> that timetables are separate problem and importing train positions from
> osm seems to be enough".
>
> On peut donc imaginer que les applications qui fourniront le routage
> seront indépendantes d'OSM mais l'exploiteront pour représenter le
> parcours sur une carte, d'autant que les informations d'horaires et de
> fréquences sont dynamiques et ne peuvent donc pas être considérées comme
> des attributs des nodes et des ways.

ah mais je n'ai pas parle de routage automatique !
quand je regarde un plan de transports en commun avec mes yeux et que je 
cherche a estimer le temps que je vais mettre je compte les arrets (vous 
savez, un, deux, trois, du calcul mental quoi, fait avec des neurones et 
pas du silicium), mais les temps de marche aux changements sont 
imprevisibles parce que non indiques sur le plan
donc la solution de chronometrer les temps / mesurer les longueurs de 
parcours entre les differents quais serait deja tout a fait 
fonctionnelle, meme si on a pas la geometrie precise du couloir souterrain

je pense egalement que ce genre d'info ferait partie de la description 
du terrain, et aurait donc sa place dans osm




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