[Talk-transit] Modelling complex stations / OpenTimeTables

Hugues Romain (RCS) hromain at reseaux-conseil.com
Thu Feb 26 23:49:52 GMT 2009


Hi everyone,

As a professional in public transport free software (routing, display screens, 
DRT, consulting, etc.) I am currently working on an extension of OpenStreetMap 
about public transportation schedules in order to be able to do full 
pedestrian routing (use of footways, streets, and public transport services).

This project is currently named OpenTimeTables (OTT).

This project should be initialized in the wide area of the french city of 
Toulouse and will of course be opened to all worldwide contributions with the 
same rules than OSM for the geographical data. It is planned that the local 
transport authority of Toulouse officially supports the project and pays some 
devs for it.

We have planned to open public servers in order to host all the schedule data 
(that cannot be integrated in the OSM model) and to offer several basic 
services based on these data (route planning and mapping at the beginning) 
using GPL softwares (Mapfish / SYNTHESE).

The geographical data will be the OSM data : there must not be any redundancy 
between the OSM schema and the OTT schema.

The question of modelling the PT stop areas is very important for this project 
: the stop point is the link between the two projects : a geographical point 
for OSM, a place served by the PT services at defined schedules.
The stop area is also the gateway between the road graph and the PT graph for 
the route planner. Some informations are required to obtain usable results 
(i.e. proper pedestrian guidance from the start address and the goal address).

So, this thread is very interesting for us.

The question of "joe the mapper" is very important : the PT modelling concepts 
are much more complex than the road ones because of the very large number of 
constraints of use of the services (eg : schedules, days of work, minimal time 
in transfers, non concurrency rules, compulsory reservations, fares, etc.). 
Route planning only on the graph of the lines does not produce any usable 
result. The difficulty is that each data producer (PT companies, or Joe the 
mapper ;) don't access to the same "data level".

To illustrate it, let's take an example : in France it is rare that the 
national rail company (SNCF) communicates the accurate departure platforms. 
They only give the stop area code. They decide which platform is used by the 
trains at the very last minutes before the departure. So the chosen data model 
must work without this information : a virtual halt can be plotted somewhere 
in the station. 
But some other railway companies give this information and respect it in the 
real time (eg : SBB in switzerland).

The model has to handle the information only when it is available but the 
route planning must work even if it is missing. This case appears on much 
objects of the model.
Some PT companies know the coordinates of each equipments they manage. Other 
ones know only the position of the middle of wide stop areas and will attach 
to it all contained objects without any further information (all platform, 
halt, equipment... has same coordinates). 

The best way to answer to this question is probably to design several 
compatible "levels of modelling" :
 - the most simple level can be defined to handle a routing algorithm on it.
 - the highest level of modelling will contain very precise informations that 
provide a full pedestrian guidance roadmap ability.
When a routing is done between "low level modelled area" and "high level 
modelled area", the routing software has to combine every available data to 
produce something usable.

I believe that optional fields is not a sufficient way : if a company knows the 
platform used by the trains, they will put the halt in the type=route 
relation. If an other company knows only that its trains stop at the station 
but does not know which platform will be used, they will put the entire stop 
in the type=route relation. Of course, even if the route is linked with the 
stop, the platforms can be mapped for display purpose only.

In this case, I think that the two way of modelling can be allowed. To help 
the mapper, the documentation should explain which modelling solution to use, 
according to the available informations.

Hugues Romain
http://www.reseaux-conseil.com/




> On Thu, 26 Feb 2009 11:25:21 +0000, Christoph Boehme <christoph at b3e.net> 
wrote:
> >> The Japaneze use the position on the platform to suggest where to
> >> board in relation to the exit at the destination station.  (see
> >> www.navitime.com - for the London Underground)
> >
> > A similar system exists for trains in Germany. Each platform is split
> > into sections (A to G typically) and a large chart explains for each
> > train stopping at the platform in which section each coach comes to
> > halt. That's handy if you have reserved seats.
> >
> > I assumed that the coloured zones on the West Coast main line where used
> > for the same thing (with the Gold Zone being the area where first class
> > coaches stop :-) )
>
> I would rather use additional nodes on the platform-way to mark these
> spots.
>
> In general: Please consider "joe the mapper" (sorry for that). We are a
> special interest group here. Whenever possible we should only decide on
> optional things. If its too complicated, noone outside of this group might
> use it.
>
> Gerrit
>
>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20090227/afebcc47/attachment.html>


More information about the Talk-transit mailing list