On Feb 28, 9:43*pm, wrote:

(Mizter T) wrote:
On Feb 28, 9:44 am, MIG wrote:

On 28 Feb, 08:32, Walter Briscoe wrote:

On 24/02/10, I entered Moorgate at 16:30 and left Euston at 16:43.
I entered Euston Square at 16:49 and left Moorgate at 17:10.
I was charged 5.80 for Euston Square entry and 6.00 for Moorgate
exit. I had already capped travel in Z1-2 on my registered
Oystercard. On 28 February 2010 03:22:49, TfL sent me an email
"... Due to an operational issue, we calculate that you are due a
refund of 11.80. This is now ready for pick-up at Moorgate. ..."
I am a little impressed.
Weekend mornings are good times for Oyster help on
0845 330 9876.
I was unable to get an explanation for the systemic failure.

This isn't the typical OSI problem that people have talked about
though, is it?

It just looks like the system was charging completely the wrong fares
to everyone and they couldn't miss it.

See my reply downthread - my suspicion is this is some sort of problem
with Moorgate being the starting and finishing station to the overall
journey. It's an odd one though. Do note that I'm not saying this to
excuse what's gone on, with these problems I'm just trying to seek to
understand what has actually happened. But I don't think it's a case
of the system being configured to charge the wrong fares per se.

So I don't infer that the inexcusable situation where people are
repeatedly getting overcharged, because the system strings separate
resolved journeys into one and then decides that the resulting journey
is too long and splits it into unresolved/unstarted journeys, is
likely to be addressed in such a helpful way.

I don't think the last paragraph is an accurate reflection of the
actual mechanism at play - the common issue is that separate journeys
are considered to be one continuing journey from the Oyster system
POV, and the problem occurs when that complete journey is not resolved
because it times out - in other words saying that several *resolved*
journeys are being strung together to make an unresolved/unstarted
journey is not accurate (IMO). That's not to say the passenger was
doing anything wrong as they were simply following the instructions
for touching-in and out.

I do hope that such problems can be addressed somehow - I dunno
how much flexibility there is to change things, and how much of
the underlying infrastructure w.r.t. the Oyster system is set in stone.

All I will say is that such problems seem rather more likely to
occur to people who are out for a 'joy ride' (or however you want
to describe it). Pretty much everyone I know uses the public
transport system to get from A-to-B - I'm the exception!

Surely the first thing the system should do if a journey involving an OSI
times out is to check if undoing the OSI assumption makes the journey
appear logical? In the OP's example the clue is that what it thinks is one
journey starts and ends at the same station!

I'm not sure the system architecture has the capacity to untangle
things like that - ultimately though I dunno, I'm just an observer.