View Single Post
  #5   Report Post  
Old January 31st 09, 09:52 AM posted to uk.railway,uk.transport.london
Paul Corfield Paul Corfield is offline
external usenet poster
 
First recorded activity at LondonBanter: Jul 2003
Posts: 3,995
Default Oyster Experiment Done at Last

On Sat, 31 Jan 2009 09:40:07 -0000, "Peter Masson"
wrote:


"Paul Corfield" wrote

I believe, but am not 100% certain, that TfL introduced a rule
concerning "doughnut or polo mint" fraud. In other words people do not
have Zone 1 on their Travelcard but have some of the outer zones. I
believe the system does a secondary check to see if the origin /
destination pair for the journey (which may both be within the zonal
validity of the card) can *only* be achieved by travelling via Zone 1.
If that is the case then a PAYG transaction will be created to charge
for Zone 1 travel.

Clearly it becomes very complex when you have orbital routes that allow
legitimate travel on the TfL farescale that avoids Zone 1. TfL have
clearly decided to allocate particular journeys to zone 1 or non zone 1
fares. In your example your ticket included Zone 1 so the secondary
check for a Z1 PAYG charge was never initiated. As both origin and
destination were within the zones you'd bought then there is no need to
do anything to trigger a PAYG additional charge.

Now that Oyster has been extended to London Overground there aren't many
journeys between Z2-Z6 starting and end points that can't be made by a route
avoiding Z1, and avoiding out-of-station interchanges where touching out and
in would be necessary, even if the route might be very convoluted - St
John's Wood to Whitechapel via Finchley Road, Rayners Lane, Earl's Court,
Kensington Olympia, Willesden Junction, Gospel Oak, and Barking. On PAYG
time outs would no doubt come into effect, and being charged the obvious
Z2-Z1 fare would not be unreasonable, but I can see issues if the passenger
held a Z2-Z5 season ticket on Oyster.


In future PAYG will be able to hold more than one fare and there will be
additional validators positioned on outer zone interchange routes to
allow people to register an intermediate routing point that the reader
at the final exit station can use to determine the fare to be charged.
This is certainly planned to be the case on LUL - whether it extends to
Overground and NR I do not know. I appreciate there are all sorts of
potential issues "I forgot to touch my card but I did go that way" etc
etc but at least something is being done to create some flexibility and
recognition that people opt to travel via longer but cheaper routes.

The same concept could be used on NR to deal with some of the examples
used by Mizter T - i.e. interchange validators at Clapham Junction. I
recognise people may be less inclined to use them if they were to be
charged more but it's an option. The other is to always default to a
higher charge but to provide for intermediate validation on the cheaper
route (assuming people change lines at one location) which would reduce
the PAYG charge or any supplementary charge on PAYG if a zonal
travelcard was held for part of the journey.

Where there are OSIs en route then the final exit validation process
will always read back through the history on the Oyster card to
determine original entry and also the interchange. At present Zone 1
OSIs would, I am sure, register the zone 1 routing to determine if a
charge on PAYG was needed for travelcard holders. It must the case in
future that OSIs will also be used for routing purposes too - it would
be daft not to use that information if the general concept of
intermediate validation is being introduced anyway.


The issues with tweaking the system to cope fairly with the myriad of
possible journeys when Oyster is extended to the whole London rail network
seem to be incredibly complex, especially when LO starts running on the East
London Line, giving even more orbital possibilities, and interchanges which
don't involve a gateline.


I agree this presents what people might term "a challenge" but there are
ways of dealing with this via assumed routes or else use of intermediate
validation. There will be compromises that some people will be unhappy
with but this is what happens when you have such a complex rail network
to deal with.
--
Paul C