[Talk-transit] Public Transport routing
Peter Miller
peter.miller at itoworld.com
Sat Sep 5 11:25:35 BST 2009
On 5 Sep 2009, at 11:11, Roger Slevin wrote:
> Peter
>
> I think you are reflecting the situation in Germany - with set
> change dates
> each year, and very little change between those dates. The
> situation in the
> UK is quite different - with the market deregulated, and therefore a
> lot of
> change going on all the time.
>
I have been comparing the timetables for October 2009 and August 2009
for my home town in Ipswich and I would estimate that 20% of the
routes have changed in that time. Some have merged, some have moved
operator some have disappeared. That is a lot and I haven't even
checked the individual timing for journeys or days of operation. There
are some 1.4 million bus journeys in the UK database so if 20% of them
disappear randomly every 10 months that is 300,000 changes to spot.
In addition, in order to be able to do correct scheduling at all times
you need to be able to deal with the christmas period, market days and
school days. Holidays for different authorities and different schools
can be on different days so a service for 'school days' that passes
two different schools with different holidays is a puzzle. Different
operators will shut down services at different rates over christmas
and it is good to know exactly what is going to happen because that is
precisely the time a lot of people will want to check. What exactly
happens with the timetables change? - the buses can't just disappear
off routes at midnight on the date of the change and immediately
teleport to new positions, so actually there is a migration over a
number of hours to the new schedules.
All this matters a lot to transport professionals and they will have
to provide free access to the full schedule information to allow good
3rd party information services to be developed and to avoid 'home-
brewed partial services' being developed that offer less accurate
information.
Having said all that, there will be a need for crowd-collection of
data for some time to come, but why not collect and present that
information as GTFS files?
Regards,
Peter
> Roger
>
> -----Original Message-----
> From: talk-transit-bounces at openstreetmap.org
> [mailto:talk-transit-bounces at openstreetmap.org] On Behalf Of Péter
> Connell
> Sent: 05 September 2009 10:52
> To: Public transport/transit/shared taxi related topics
> Subject: Re: [Talk-transit] Public Transport routing
>
> To be honest bus information is not that difficult to keep up to date,
> as most of the changes are fairly trivial and keeping up to pace is
> unlikely to take much more than a day a month for anyone.
>
> What would be more interesting would be using it as a proof of concept
> for [crowd-sourced] PT data and developing a framework for other
> countries where electronic PT information is difficult/impossible to
> get
> hold of; in much the same way as OSM has mapping for India.
>
> In the same vain here:
>
> http://www.öpnvkarte.de/?zoom=15&lat=53.81149&lon=-1.55207&layers=BT
>
> I have gone for the route of the 62 advertised on the stops, but in
> reality (being an infrequent and poorly used services) it takes a
> different route each time [from Moorland Road and Hyde Park Road] ~
> but
> what should I go for?
>
>
>
> Roger Slevin wrote:
>>
>> As someone sitting on the periphery of OSM, with a particular
>> interest
>> in the use of NaPTAN and equivalent data for stop points, perhaps I
>> can give a slightly different perspective on where I would see the
>> boundary that Peter Miller refers to.
>>
>> Stops are (reasonably) static features. Railway and Tram Tracks (and
>> monorails!) likewise. And because tracks are essentially static, the
>> scope for different “routes” to be operated over tracked networks is
>> relatively limited – and therefore the speed of change of routes on
>> tracked systems is quite slow.
>>
>> But the reason that journey planning systems have to build data every
>> week in the UK is that we have a free market for public transport
>> provision, and there are changes happening continually – changes
>> which
>> can only be reflected in continually maintained data. The changes are
>> in timetables and in routes – new routes, routes ceasing, routes
>> being
>> described differently. Some “routes” are really a collection of
>> subtly
>> different routes – sometimes with different numbers (or names), and
>> sometimes not. My advice to the OSM community is to focus on the
>> things which you can do well, and can maintain easily, without trying
>> to replicate data from other fast-moving sources which it would be
>> difficult to keep up with.
>>
>> One of the problems with Google Transit is that the “stops” displayed
>> on Google Maps are only refreshed when the tiles are repainted – and
>> that happens three or four times a year. For public transport
>> information even that sort of update frequency is too slow for the
>> stops, let alone for routes or times (Google does update weekly for
>> routes and times, thank goodness – so it is only the visualisation of
>> the stops that lags behind).
>>
>> That’s my perspective! I am sure there are other views!
>>
>> Roger
>>
>> *From:* talk-transit-bounces at openstreetmap.org
>> [mailto:talk-transit-bounces at openstreetmap.org] *On Behalf Of *Peter
>> Miller
>> *Sent:* 05 September 2009 09:57
>> *To:* Public transport/transit/shared taxi related topics
>> *Subject:* Re: [Talk-transit] Public Transport routing
>>
>> On 5 Sep 2009, at 07:50, Sarah Hoffmann wrote:
>>
>>
>>
>> On Fri, Sep 04, 2009 at 07:42:58PM +0100, Péter Connell wrote:
>>
>> To not use timetables would case various aberrant behaviours like
>>
>> routing Yorkshire-Scotland traffic via Settle (side-note: does
>> NRES
>>
>> still need to be forced to route this way?)
>>
>> Speed differentials are such that you'd need scheduling
>> information for
>>
>> any meaningful set up, e.g. here http://osm.org/go/evjiG2F_- where
>> the
>>
>> fastest buses run along the bypass
>>
>>
>> This problem might be solved by adding approximate travel times to
>> the routes. While timetables themselves are far to complex to add
>> to OSM, the time it takes to travel between two stations stays
>> fairly constant. It might be a nice use for the role in route
>> relations.
>>
>> The routing still wouldn't be perfect because change times are
>> also hard to predict when there is no timetable information.
>> Nonetheless, it would be immensily helpful to plan travels that
>> involved multiple modes of transport and multiple operators.
>> If you ever tried to plan a trip from a small town in France
>> to a small town in Spain, you will know what I'm talking about.
>>
>> I see huge mission creep[1] here. Wikipedia defines Misson Creep like
>> this:
>>
>> *"Mission creep* is the expansion of a project or mission beyond its
>> original goals <http://en.wikipedia.org/wiki/Objective_%28goal%29>,
>> often after initial successes.^[1]
>> <http://en.wikipedia.org/wiki/Mission_creep#cite_note-0> The term
>> often implies a certain disapproval of newly adopted goals by the
>> user
>> of the term. Mission creep is usually considered undesirable due to
>> the dangerous path of each success breeding more ambitious attempts,
>> only stopping when a final, often catastrophic, failure occurs. The
>> term was originally applied exclusively to military operations
>> <http://en.wikipedia.org/wiki/Military_operation>, but has recently
>> been applied to many different fields, mainly the growth of
>> bureaucracies <http://en.wikipedia.org/wiki/Bureaucracy>.
>>
>> Now of course the whole story of OSM has been one of huge mission
>> creep but at some point are we not going to need OpenStreetShedules
>> (or whatever it is called) and should that not be the place to access
>> schedules that link neatly to OSM and get updated on a very regular
>> basis?
>>
>> Personally I would strongly advocate adding bus stops etc and public
>> transport routes to OSM because they are the connectors between the
>> schedules and the physical infrastructure, but where do we stop? I
>> see
>> a creepage with people adding just a bit more and just a bit more
>> when
>> I think we all agree that we can't get all the timetable information
>> into OSM, and even if we could then is it appropriate given that it
>> changes so often?
>>
>> Clearly there are many people who want access to all the information,
>> so all we need to do now is agree where we are wanting to get to and
>> how the project(s) will be organised. Are we wanting to get to:-
>>
>> A) A point where all the world's public transport access points (bus
>> stops,station etc) are in OSM (but not the routes) and then all the
>> route and other schedule information is available from some other DB
>>
>> B) A point where all the world's public transport access points (bus
>> stops,station etc) and all the routes are in OSM and all the other
>> schedule information is available from some other DB
>>
>> C) A point where all the world's transport schedules are in OSM and
>> get updated on a regular basis by Bots?
>>
>> Personally I think we have already gone past point A and I think that
>> is good. I am happy with B, but don't think C is right for a couple
>> of
>> reasons. Firstly it will be a lot of data that most people won't be
>> interested in and does fit very comfortably in the OSM structure.
>> Secondly there are good reasons why people might want to use
>> different
>> timetables (future or past ones) and they will then have to have a
>> different DB. The main adgument for C) is that OSM is adaptable and
>> has accommodated additional data in the past, so why do it again?
>>
>> I suggest that we focus for now on getting all the bus stops and
>> public transport routes from all of the 85 Google Transit feeds that
>> are already available for reuse[2] (but only the ones where the
>> licensing in compatible with OSM) into OSM and then think about
>> setting up OpenStreetSchedules, OpenTimetableService,
>> OpenStreetTimetables or whatever to contain all the details we need?
>> For the time being people can dip into these GTFS data feeds
>> individually, but in time a single big DB might be useful which can
>> get to chopped up by country or state as is happening with OSM data.
>>
>> [1] http://en.wikipedia.org/wiki/Mission_creep
>>
>> [2] http://www.gtfs-data-exchange.com/
>>
>> Regards,
>>
>> Peter
>>
>>
>>
>>
>> Sarah
>>
>>
>>
>> I think this is something that road routing software has struggled
>> with
>>
>> a while so there may be some helpful potential approaches from
>> there.
>>
>> Though getting the timetables, however difficult, might still be
>> easier!
>>
>> _______________________________________________
>>
>> Talk-transit mailing list
>>
>> Talk-transit at openstreetmap.org <mailto:Talk-transit at openstreetmap.org
>> >
>>
>> http://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>> _______________________________________________
>> Talk-transit mailing list
>> Talk-transit at openstreetmap.org <mailto: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
>>
>
>
> _______________________________________________
> 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
More information about the Talk-transit
mailing list