Bus Fare Tables
julianlstar
fare tables into GFTS. There are a number of issues with this as GTFS
doesn't seem to support the idea of Fare Stages
http://code.google.com/p/googletransitdatafeed/wiki/FareExamples only
point to point journeys. Also there doesn't seem to be anything in the
spec for concessionary journeys and half fares - let alone promotional
offers.
At the moment GMPTE fare tables are in text format with fare stages
having archaic names that don't necessarily reference the NaPTAN
datasets.
So the challenge is referencing the fare stages to the NaPTAN. Even
though there might be one fare stage which works in both directions
the NaPTAN has an outbound and inbound reference. I'm figuring that
that the first task can be chunked down to find instances of unique
names and converting these to NaPTAN > This might be a manual task.
This will give a NaPTAN identifier and latlong. This will then have to
be cross-referenced with GTFS stop ID.
It is then a process of going through the routes and breaking routes
down into point to point journeys. This looks like an horrific task
but the Fare Stages haven't been updated since pre-1988 except when
new routes have been created. Also when bus fares go up, they tend to
go up on an operator basis and are global.
This would all be unnecessary if we had an integrated transport
system.
Any thoughts apart from "your mad" would be appreciated. Especially
thoughts about how to make this robust and maintenance lite
Cheers
Julian
aph
No, you're not mad, just asking a challenging question. I have had
a quick google and there isn't much out there regarding far etable
software/parsers to help. Do we know how the data is produced because
the
raw data maybe in a better format than the 'formatted' output?
Having looked at some of the sample data, there is clearly an issue in
rationalising the fare stage names with some other data set. One
thought
would be to extract all of the fare stages from the files and then see
which fare stage names match the names in the GTFS data set. Once
one match is found for the route, then there should be a relatively
'easy'
way of matching the other names to the GTFS data - whether that can be
automated, I don't know. I can clearly see how to load each faretable
into
a database, though.
I need to think how the process can be made as automatic as possible
to refine the
data and need to have a play with some of the data and see what
patterns
emerge. Failing that we could use the ODM network to do the data
refining working
through the various fare stages (lets say 100 at a time) until we have
finished.
Having looked at the GTFS fare example, it would appear that the
system is
more set up for a zone based system rather than a point-to-point fare
scheme.
I am sure it can be manipulated into a form that can be made to work
but
I would imagine that this wouldn't be too easy.
Of course, if we can't find a suitable way of automating the process
we could always ask (or suggest) GMPTE to ensure fare stages match
NaPTAN data to make the task somewhat simpler :-)
Regards
Anthony
julianlstar
that the files aren't really fit for purpose. As thought, the Fare
Stages don't necessarily map on to the NaPTAN and in some senses they
are a totally ambiguous - as a name given might be a road and the road
might have several stops - Also a fare stage is bi-directional
(mostly) and therefore has to map onto two bus stops. Taking a sample
of the data shows errors such as fares not complete and names
misspelt, also as pointed out previously some of the files are pretty
old.
Taking the larger files into Google Refine shows that the structure of
the data, especially of the bigger files, is insane.
I have come to the conclusion that the simplest way of doing this is
asking GMPTE for locations of their fare stages - not fares. I think
this should hopefully be a simple request. Once these are known these
would probably have to be added to the "stops.txt" file in the GTFS -
As a fare stage effects all services. When this is done it should be a
relatively simple process of creating the "fares_rules.txt" and
"fare_attributes.txt should be easier - hopefully.
Julian
aph
and have created
a number of csv files ready for loading into a database (one for the
stops, one for
the routes and one for all the fare details). I need to weed out the
historical
files (some of the files go back to 1998) which whilst it might be
interesting
from an historical perspective, it isn't very useful for a live
journey planner.
The quality of the data is variable with inconsistent stage names
(e.g. use
of LN or LANE for the same stage) and even some typos which is going
to make the
rationalisation of the fares against NapTAN data interesting. I
haven't checked yet to see if there is at least
one file each all of the routes with the data used to create the GTFS
dataset.
I will try and manually create a fares file in GTFS format so that I
can assess
how difficult it will be to automate (some of) the conversion.
Do we know if the fare tables are going to be released on a regular
basis, ideally
with the ATCO data?
Regards
Anthony
Julian Tait
Fare data is a bit contentious as it could be seen to be commercially sensitive information - The reason why it was released in the first place was by a FOI request by Sam Easterby-Smith and the reason from their legal department was that it was already in the public domain.
Fares aren't increased that often annually at most so don't need to be updated as regularly, also the fare structures that are released are maximum adult single fares - no returns, savers, passes, concessions or other promotional offers. The concession and child/scholar fare wasn't an issue as it was a flat 80p single journey anywhere in GM (no transfers allowed) This will change soon when concessionary fares are going to become half adult fare.
Although the data isn't in an ideal state the actual ways that fares increment over fare stages is pretty simple.
Julian
Peter J Stoner
>
You might find it reassuring to know the problems you have encountered
are along the same lines as in electronic interpretation of fares data
elsewhere. So don't assume that other areas are any better than
GMPTE!
I have a rather simple mind and find it helpful to consider that a
field can be described by the fences that surround it, which is like
the fare stage approach, or by what is in the field, which is more
like a fare zone approach, which I think you will find works much
better in database systems.
So rather than map the "fences" to th enearest NaPTAN points, or ask
GMPTE to add ghost NaPTAN points, you may find it helpful to identify
the NaPTAN points that lie between the given fares stages. Where a
NaPTAN point does coincide with a fare stage then the NaPTAN point is
in two fare zones, which is correct so far as when you alight, the
stop is considered as part of the preceeding zone, and when you board
you get the fare for the zone that is ahead. When calculating a zone
to zone fare this nay give rise to two fares applying to a single bus
stop. Both are valid but obviously the passenger will pay the lowest
of the two.
This approach comes into its own when you get a fares stage which in a
rural area is given as "the village". If the village has three bus
stops in it, this does not mean that the fares stage is the central
bus stop. It means that you get the same fare whichever bus stop in
the village you use, and you can't make the fare stage the first stop
either as it will penalise people alighting in the village. All three
bus stops are therefore in two fares zones.
I hope this perspective is of some assistance
Best wishes
--
Peter J Stoner
UK Coordinator www.travelinedata.org.uk
Traveline
Traveline Information Ltd company number 3826797
Drury House, 34-43 Russell Street, LONDON WC2B 5HA
Julian Tait
I can see how the fare zones structure is necessary for rural stops. It is also expressed like that in GTFS. This is where the challenge lies in order to get to a zoned format you have to define the zones and as mentioned the fare stages define the zones.
With GTFS you have to describe every possible journey from a given stop and each stop is in itself called a zone. I am wondering whether fare stage structure is unique to the UK.
Julian
Julian Tait
Open Data Cities and Social Sensing
M: 44 (0)7802 851 394
Skype: Julianlstar
FutureEverything - Innovation Lab and award winning global festival of art, music and ideas.
FutureEverything 2011
11-14 May, Manchester UK
http://www.futureeverything.org
Twitter: @FuturEverything
Tag: #futr
Transport Action Group
http://www.stagecoachbus.com/uploads/stagecoachmanchesterfaretables03april2011masterlinks.pdf
from this page:
http://www.stagecoachbus.com/Fares%20information%203%20April%202011.aspx
Limited to one operator, but a bit clearer
Bill
--
MERCi - Ideas into action for a sustainable future
Bill Harrop
Transport Strategic Engagement Worker
Bridge 5 Mill
22a Beswick Street
Ancoats
Manchester
M4 7HR
T: 0161 273 1736
F: 0161 274 4598
E: tran...@merci.org.uk
W: www.tag-mcr.org.uk
Facebook: http://www.facebook.com/#!/group.php?gid=19190904229
Twitter: http://twitter.com/TAG_Manchester
The Transport Action Group is part of the Environment Network for
Manchester based at MERCi and is funded and supported by the
Community Network for Manchester
http://www.en4m.org.uk/
http://www.merci.org.uk/
http://www.cn4m.net/
Need to find a local group covering other issues?
Want other groups to know about you?
One central Place the online directory for voluntary and community
groups in Manchester:
http://www.onecentralplace.org/
Charity number: 1077362
Company number: 3518490