[Talk-transit] NaPTAN bus stop database import

Peter Miller peter.miller at itoworld.com
Sun Mar 1 22:35:52 GMT 2009

On 1 Mar 2009, at 21:51, Roger Slevin wrote:

> Peter
> It would be very misleading to the OSM community for them to take  
> any notice
> of your "hope" to have stopareas everywhere in the NaPTAN database.  
> More
> than half of the country do not use stopareas at all in the journey  
> planner
> that they use - and there is no reason for the three regions I am  
> familiar
> with to create stopareas where they don't exist.  Creating them as  
> explicit
> stopareas, where we have perfectly good procedures that maintain  
> implicit
> stopareas automatically, is not only a lot of work - but also requires
> continual maintenance.  We do not have the resources to do this - so  
> your
> "hope" is quite unrealistic.
> From a DfT perspective the stoparea is an optional feature within  
> NaPTAN -
> and there is no realistic prospect for that to change at a national  
> level.
> OSM should ignore stopareas in NaPTAN, therefore - and focus on the
> stoppoint records which are the fundamental content of NaPTAN.

The important thing from the modelling perspective is that what OSM  
call a Stop Area is the same as what Transmodel calls a Stop Area, and  
therefore what nearly every European transport profession sector know  
as a Stop Area and in many other places too.

There is a current proposal in OSM to use the term Stop Area for  
something that might be more like a Stop Place (in IFOPT). Nick  
Knowles has very helpfully added a good chunk of definitions onto the  
Stop Area proposal page giving the Transmodel terms for things and the  
OSM community should possibly look to hamonise terms with Transmodel  
where possible. It would certainly help avoid modelling issues later  
and make it much more attractive for other places considering offering  
public transport data.

Modelling a Stop Area is very simple. In Transmodel a Stop Area is  
purely a collection of Stop Points with a name and a reference. As  
such this could easily be modelled with a relation. With regard to the  
NaPTAN import , I see no reason why the OSM community should not  
import Stop Areas where they exist so that people can get used to  
modelling them and using them.

Stop Areas are a useful tool for producing less detailed mapping where  
one wants to loose excessing detail. Other examples of where one wants  
to loose detail are when one is making maps of dual carriageways and  
railways. When one is zoomed in one wants to see lots of detail (ie  
two carriageways, slip roads etc, multiple tracks) and when one zooms  
out one wants to see only a single line. The people writing code for  
the renderers need data to practice on, and by providing Stop Areas  
for even one part of the world (ie one UK county) they have something  
to chew on.

Another place where Stop Areas are useful is for journey planning.  
there is already GraphServer, a PT journey planning tool that uses OSM  
data (http://graphserver.sourceforge.net/gallery.html), and I am sure  
people in that project would be interested in seeing what use they can  
do with Stop Areas.

The OSM community could also create algorithms to create Stop Areas in  
places where they don't currently exist, based on the rules in NaPTAN,  
for example where there are stops almost opposite each other on a road  
a long way from any other stops. That is just to sort of thing that  
someone might do when the renderers start using them and there is a  
reason for better coverage.

Also, even if the UK NaPTAN import ignores them for now, then I know  
that there are some other potential imports in the EU area that could  
use them and so for that reason alone we should get the modelling and  
terminology right from the start.

I wonder if we might get the stops of Toulouse soon as part of the OTT  
project that Hugues Romain was talking about recently?

There are also loads of Stop Points avaiable from Google Transit  
Exchange data (http://www.gtfs-data-exchange.com/). Someone might go  
through those soon and see which ones are available on suitable  
licenses and import them. Again that is a big source of Stop Points,  
and as such a potential source of Stop Areas.

I think we should see the NaPTAN import as being a useful catalyst for  
all sorts of innovation, much of which will be unexpected, and as such  
we should chuck as much in the pot as the project can digest, and to  
date that it a lot!



> Best wishes
> Roger
> -----Original Message-----
> From: talk-transit-bounces at openstreetmap.org
> [mailto:talk-transit-bounces at openstreetmap.org] On Behalf Of Peter J  
> Stoner
> Sent: 01 March 2009 21:18
> To: talk-transit at openstreetmap.org
> Subject: Re: [Talk-transit] NaPTAN bus stop database import
> In message <DEF74E78D2F74302BDF48AD40609AAC4 at REDSOL>
>          "Roger Slevin" <roger at slevin.plus.com> wrote:
>> Thomas
>> 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.
> All the journey planners do use StopAreas in one form or another.
> Isn't it that some are completely "implicit", though not necessarily
> requiring identical common names, or just don't publicise their
> StopAreas in NaPTAN (NE England).
> While "Implicit" is useful and better than badly constructed
> "explicit", the explicit method gives more control and I hope that
> before too long we will have StopAreas in NaPTAN for all parts of the
> UK.
>> 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).
>> http://wiki.openstreetmap.org/wiki/NaPTAN/Local_schemes#York
> -- 
> Peter J Stoner
> UK Regional Coordinator
> Traveline                       www.travelinedata.org.uk
> a trading name of
> Intelligent Travel Solutions Ltd  company number 3826797
> Drury House, 34-43 Russell Street, LONDON WC2B 5HA
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
> _______________________________________________
> 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/20090301/cebe2254/attachment.html>

More information about the Talk-transit mailing list