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.
http://wiki.openstreetmap.org/wiki/Proposed_features/unified_stoparea
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!
Regards,
Peter
Best wishes
Roger
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Peter J
Stoner
Sent: 01 March 2009 21:18
To: [email protected]
Subject: Re: [Talk-transit] NaPTAN bus stop database import
In message <def74e78d2f74302bdf48ad40609a...@redsol>
"Roger Slevin" <[email protected]> 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 <[email protected]>:
2009/2/28 Brian Prangle <[email protected]>:
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
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
_______________________________________________
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
