On Jan 25, 12:56*pm, Roland Perry wrote:

In message
, at
02:58:18 on Mon, 25 Jan 2010, MIG
remarked:

I thought I understood Oyster, but those remarks make no sense to
me. If someone is "always touching in and out", how they possibly
be charged more than the daily cap?

In a phrase "unresolved journeys". OSIs can accidentally create them.

Yes; eg you go from Greenwich to Charing Cross (with a change at
London Bridge), take your snaps of Nelson, then go into the
Underground for a trip to Kew Gardens. *Because Charing Cross is an
OSI, probably with a long timeout, the whole thing ends up as a single
journey which could go beyond the time limit, leaving you with an
unresolved journey and an unstarted journey at Kew, both of which are
charged at maximum. *Once you've got an unresolved journey (I'm pretty
sure) all capping goes out of the window.

That's bonkers! The system has the time I touched back in at Charing
Cross, and can therefore update its expectation of when I could possibly
get to Kew.

I've a suspicion the system might work on the basis of what the time
was when the (original) journey started - so in this example the card
gets presented to an Oyster pad at Kew which queries what time the
original journey started (i.e. when the first touch-in happened, not
what happened at CX), then checks this against the table of
permissible maximum journey times, then if it's exceeded it presumes
that the pax is in fact ending a different journey where they didn't
touch-in when they began it - voila, two 'max fare' charges end up
being applied (though the mechanism of these charges being applied is
actually that they're deducted at the beginning of a normal journey,
then refunded at the end on exit from the system - though in the case
of the touch-out at Kew it's just taken there and then).


On the other hand, if it wants to spot someone getting "too much value
for money", then rather than create two unresolved journeys, it could
split the trip at Charing Cross, and charge two individual journeys.

I think one possible issue would be that this would require the Oyster
pads and cards to perform calculations beyond their capabilities -
looking back at the recent journey history and then splitting
previously combined journeys, especially complex if there were
multiple OSIs during the journey.