[Talk-transit] Should railway station relations includebusstops?

Peter Miller peter.miller at itoworld.com
Thu Sep 10 11:59:37 BST 2009

On 10 Sep 2009, at 09:01, Frankie Roberto wrote:

> 2009/9/10 Peter Miller <peter.miller at itoworld.com>
> On 10 Sep 2009, at 00:45, Thomas Wood wrote:
> > NaPTAN provides relations for stations (or at least it should, I've
> > yet to check), in most cases, this will contain the station node,  
> and
> > entrance nodes, and child relations eg, the stops outside of it.
> > I've yet to import them, but I do have all the backreferences stored
> > to do so.
> NaPTAN allows for a hierarchy of stop areas.
> In NaPTAN there should be a Stop Area for all the features directly
> associated with the railway station.
> There can then be other (un-related) stop areas associated with groups
> of bus stops around the station
> I believe that an additional Stop Area can then be used to bind all of
> the above into one. The rendered can then choose to do one blob for
> all the public transport features around the station, or one for
> station itself and to identify every feature individually.
> Stop Areas are not well used across the UK, some areas use them, some
> don't and where they are used the data can be a little suspect.
> Possibly we could aim to do a better job over time?
> So, in the case of a large train station that's surrounded by bus  
> stops, we should aim for one relation that contains all the train  
> station elements (platforms, walkways, stopping points, etc), one  
> relation that contains all the bus stops, and then have both of  
> those relations belong to a parent relation...?
To be clear, there may be many groups of bus stops around the station  
in their own logical groups and these would be modelled separately in  
NaPTAN and also in IFOPT. Let's decide what we want, rather that just  
following the standards but I think the approach is pretty sensible.

> These seems a little over-complicated to me - are there any benefits  
> to doing it this way, rather than having a single relation in OSM?

It allows more finessing of the level of detail as one zooms in. The  
overall Stop Area is also a good indication to routing engines that  
one can reasonably transfer between modes

> Also, what happens in the case that there are multiple modes (tram,  
> metro) within a train station - does each of these get its own  
> relation, or is it more the case that we should simply separate  
> features within a station building, and features outside of the  
> building on the road network (bus stops, maybe tram stops) that are  
> simply used to connect to the station?
A pair of tram stops would be in a relation separately from a groups  
of bus stops, and then these might be combined.

However... do feel free to create simpler stop areas to start with -  
the model can build in complexity as needed over time, even if the  
stop areas need to be refactored later.

> Frankie
> P.S Waterloo station seems to have 3 relations: http://wiki.openstreetmap.org/wiki/United_Kingdom_train_stations

It does appear to be a little complex around Waterloo and possibly  

The stop areas you refer to have type codes which are described in the  
NaPTAN schema document, but I am not clear that it is at all correct  
based on a quick look I also notice that many of the areas have  
duplicate names which also makes it harder to sort out.

I believe that there is another relation in NaPTAN for the station  
that has not yet been imported into NaPTAN which makes it even more  

Let's use Waterloo as a test case for OSM. Bank/Monument would also be  
useful because it is given as an example in the NaPTAN documentation.  
Lets also focus on the stations given in the IFOPT documentation  
examples. Incidentally Waterloo is used as an example thoughout the  
IFOPT documentation.

Possibly we should have a mapping party there (I passed though it  
yesterday as it happens).



> -- 
> Frankie Roberto
> Experience Designer, Rattle
> 0114 2706977
> http://www.rattlecentral.com
> _______________________________________________
> 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/20090910/f05751a7/attachment.html>

More information about the Talk-transit mailing list