[Talk-transit] NaPTAN bus stop database import

Roger Slevin roger at slevin.plus.com
Sun Mar 1 08:36:15 GMT 2009


You comment that York doesn't appear to be aware of the stoparea principle
... this is widespread.  There are no downstream national applications that
make use of stopareas - and no pressure, therefore, to create stoparea data.
In the areas of South and East England (SE, EM and EA regions on traveline)
which (from this week) will be working with a combined multi-region database
which also includes London, our system handles stopareas in two ways :
- explicit stopareas contained in NaPTAN records, and
- implicit stopareas created from the stoppoint records where stoppoints
have identical commonnames and are within certain proximity limits of each
other (a span of 150m for two stoppoints, or 250m for three or more
This "implicit stoparea" process means that the stoparea data maintains
itself when stoppoint data is maintained according to the rules - and works
well for us.  But it is an approach which works only with our particular
supplier's data import processes each week.
Where implicit stopareas exist in our regional journey planner they do not
appear in NaPTAN and cannot be used in any other system (unless they apply
the same rules when importing stoppoint data from NaPTAN).

I would counsel the use of care with stopareas, therefore - as they are not
widely used.

You also referred to "national" stopareas - those with prefixes which begin
with 9 and refer to Rail Stations, Airports, Ferry ports and
Tram/Metro/LightRail stations.  The existence of these stopareas is indeed
in the relevant "national" area database - but they can also contain
stopareas or stoppoints from local geographical data.  Again the use of this
is most significant in the SE, EM and regions - as these relationships
define locations at which interchange can take place in the regional journey
planner.  I am not aware of any other regions where this is significant.

Finally, I should note that because EM and EA are changing system supplier
and adopting a system which relies completely on NaPTAN, a lot of data
editing and improvement is going on in both regions (and will continue to do
so for some time yet).  So, although the development of the process of
importing NaPTAN data should go ahead now, I will recommend that a fresh
download of data is supplied in due course so that the current phase of data
improvements in these regions in particular are captured when it is
appropriate to do so.

Best wishes


2009/3/1 Thomas Wood <grand.edgemaster at gmail.com>:
> 2009/2/28 Brian Prangle <bprangle at googlemail.com>:
> In other news, whilst on the train to (and from) York today, I wrote a
> sizable chunk of the StopArea code for the converter. It's in a mostly
> working state, the only issues I have to work out are StopArea
> hierarchies, particularly when a StopArea is defined in another
> region's dataset, the national rail one, for example.
> I'm either going to have to do a mass convert of the whole dataset at
> once (which I'm not looking forward to, since I suspect the memory use
> will skyrocket), or try and resolve the dependencies by parsing the
> national datasets to get a hash of all the StopAreas, and then append
> on the county level StopAreas as and when they're created, finally we
> can then upload the national StopArea points, as and when we get
> around to those types of data. (AIrports, NatRail, to name a few)

Whilst in York, I was able to photograph some bus stops, I've done a
quick comparison of the data, it seems to be the worst in terms of
standards compliance so far, but seems to be quite self consistent,
which is a small bonus.

Why quote the above? Well, it seems that York is unaware of the
existance of the StopArea principle. (At least, I couldn't find it in
a quick grepping of the data).


Thomas Wood

Talk-transit mailing list
Talk-transit at openstreetmap.org

More information about the Talk-transit mailing list