On 10 Sep 2009, at 09:01, Frankie Roberto wrote:
2009/9/10 Peter Miller <[email protected]>
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
wrong?
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
complicated.
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).
Regards,
Peter
--
Frankie Roberto
Experience Designer, Rattle
0114 2706977
http://www.rattlecentral.com
_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
