View Single Post
  #1   Report Post  
Old January 30th 09, 11:11 PM 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 Fri, 30 Jan 2009 06:54:52 -0800 (PST), MIG
wrote:

Some time ago there was discussion of touching in with a travelcard on
Oyster on the DLR.

Obviously, if one subsequently goes beyond zones (eg has zone 1 - 2
travelcard and needs to go on to Stratford) one needs to have touched
in.

Also, if one enters or leaves at a point where the travelcard is
valid, it lets one through any barriers regardless of touching at the
other end.

I was wondering what would happen if one touched in when making a
journey in zones 1 and 2, where the PAYG journey would be priced as
via zone 3.

I had a zone 1 - 2 travelcard and touched in at Mudchute and went to
Hackney Wick via Old Street and Highbury (ie covered by the
travelcard). The Oyster single fare is £1.10, ie assumed to be zone
2/3 (and impossible without zone 3 at Stratford).

So did it just check that the travelcard was valid at each touching
point, or did it deduct £1.10 for an assumed PAYG journey via zone 3?

The former (good). It didn't deduct anything.


I think other posts have covered the basics but here is my understanding
although I am not 100% up to date.

A travelcard is checked at entry and exit against the zones held on the
ticket / card. If there is no out of zone travel then there is no PAYG
transaction initiated - i.e. the origin or destination are both in the
zones on the ticket. If either or both were outside the travelcard
zonal validity then I believe an auto extension transaction would be
initiated by creating a transaction in the PAYG part of the Oyster Card.

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.

What I am not sure about is if you had taken a route involving JLE and
Stratford whether the JLE interchange gateline would have set a charge
for Zone 3 or not. Clearly that is a rare example as virtually no flows
have interchange gatelines on them. If you had gone solely via DLR and
not touched a validator inside the paid area I imagine there would be no
issue. Quite what a DLR train captain might have said or done I don't
know if he'd checked your card on the approaches to Stratford!

There is a proposal for the extended PAYG system (that will cover NR) to
have a concept of extension transactions so that if people exit LUL on
PAYG and then re-enter on NR (e.g. interchange at a London Terminal)
there will be a transaction set on exit from LUL that there may be a
further journey on NR. Once re-entry has taken place at the NR gateline
/validator line then the total permissible journey time will be extended
for the full through journey. This will recognise the full overall PAYG
fare due on exit while also preventing two journeys being charged
because maximum journey time would otherwise have been exceeded. That
was certainly the concept the last time I read about it but I have to
warn that the final implemented solution may differ. I'm sure I'll know
more later in the year as we get closer to implementation.

Sorry for a long explanation but I hope the "logic" is a bit clearer.

--
Paul C