In message

..net, at 20:57:49 on Tue, 18 Dec 2012, Neil Williams
remarked:
"Finished your journey? Touch the purple validator to ensure you
are charged the correct fare".

Or perhaps more logical one to signify that you are continuing it.

Even better, just close the journey if a touch-back-in doesn't occur within
the OSI time period, if necessary the next time the card is used. Don't
see why that's hard.

I think you misunderstand the failure mode, which I think is people
leaving the OSI station to go about their business, and who then return
for an onward journey *before* the OSI times out, which then confuses
the system if their A-B-C (where B is the OSI) exceeds the quota for an
A-C journey.
--
Roland Perry

Recliner wrote:

But there's also the issue of the journey time limit, which is where the
problem can arise. For example, let's say journey 1 lasts 80 minutes (90
allowed), and the next journey, from the same station, starts 15 minutes
later (20 mins OSI allowed). The Oyster system will try and combine these
into a single journey, but the combined journey may well exceed the allowed
time, leading to two incomplete journeys.

A sensible solution for OSIs would be to add the time outside the system
while using an OSI to the maximum.

There is also no sense in allowing an OSI if you exit a station then
re-enter the same one, possibly except during disruption, because that's
either a break of journey or a return journey, not an out of system
interchange.

Neil
--
Neil Williams in Milton Keynes, UK. Put first name before the at to reply.

Neil Williams wrote:
Recliner wrote:

But there's also the issue of the journey time limit, which is where the
problem can arise. For example, let's say journey 1 lasts 80 minutes (90
allowed), and the next journey, from the same station, starts 15 minutes
later (20 mins OSI allowed). The Oyster system will try and combine these
into a single journey, but the combined journey may well exceed the allowed
time, leading to two incomplete journeys.

A sensible solution for OSIs would be to add the time outside the system
while using an OSI to the maximum.

There is also no sense in allowing an OSI if you exit a station then
re-enter the same one, possibly except during disruption, because that's
either a break of journey or a return journey, not an out of system
interchange.

OSI also applies in large complex stations like Kings X, so the second
journey may well start from a separate entrance in the same complex.

In article

, (Neil Williams) wrote:

wrote:

"Finished your journey? Touch the purple validator to ensure
you are charged the correct fare".

Or perhaps more logical one to signify that you are continuing it.

Even better, just close the journey if a touch-back-in doesn't occur
within the OSI time period, if necessary the next time the card is used.
Don't see why that's hard.

Isn't the problem that people re-enter the station within the OSI period
because their visit is a brief one?

--
Colin Rosenstiel

In message , at 18:43:53
on Tue, 18 Dec 2012, remarked:
"Finished your journey? Touch the purple validator to ensure
you are charged the correct fare".

Or perhaps more logical one to signify that you are continuing it.

Even better, just close the journey if a touch-back-in doesn't occur
within the OSI time period, if necessary the next time the card is used.
Don't see why that's hard.

Isn't the problem that people re-enter the station within the OSI period
because their visit is a brief one?

Yes that's the problem. And unless passengers are consciously trying to
use that as a loophole[1], then they should welcome a facility to break
the journey into separate legs in order to avoid the possibility of the
side effect/bug of a large excess charge.

The latter is more likely on a dog-leg or doubling back journey I'd have
thought, than one where the OSI was roughly on-route between the real
start and finish points.

[1] I've done that myself, in a manner of speaking. I took a trip from
Victoria (where my hotel was) to the Dome (to look at the cable-car
under construction), and on the way changed trains at Waterloo
using the opportunity of being on the main concourse to ask the ticket
office staff about the SWT ITSO card. (The knew nothing, but I digress).

--
Roland Perry

"Neil Williams" wrote in message
...
wrote:

"Finished your journey? Touch the purple validator to ensure you
are charged the correct fare".

Or perhaps more logical one to signify that you are continuing it.

Even better, just close the journey if a touch-back-in doesn't occur
within
the OSI time period, if necessary the next time the card is used. Don't
see why that's hard.

Journeys terminating at an OSI are closed.

It's the default to reopening when you touch back in again (within the
allowed time) that allows the problem.

(and you then only end up with a wrong charge if the total journey time is
more that allowed - but that's much more likely to happen if the second leg
isn't really a second leg at all)

tim

"Neil Williams" wrote in message
...
Recliner wrote:

But there's also the issue of the journey time limit, which is where the
problem can arise. For example, let's say journey 1 lasts 80 minutes (90
allowed), and the next journey, from the same station, starts 15 minutes
later (20 mins OSI allowed). The Oyster system will try and combine these
into a single journey, but the combined journey may well exceed the
allowed
time, leading to two incomplete journeys.

A sensible solution for OSIs would be to add the time outside the system
while using an OSI to the maximum.

I don't think the time outside the system is critical to causing the problem
here (except in as much as making it possible to transact your genuine
business within the transfer time).

You're just as likely to "time out" on a through journey that "wasn't" if
you spend 15 minutes transferring as 2 minutes.

tim

"tim....." wrote:

I don't think the time outside the system is critical to causing the
problem here (except in as much as making it possible to transact your
genuine business within the transfer time).

You're just as likely to "time out" on a through journey that "wasn't" if
you spend 15 minutes transferring as 2 minutes.

Maybe if it times out, then, it should be reconstructed as two journeys
split at the last OSI touched. Or can't it do that?

Neil
--
Neil Williams in Milton Keynes, UK. Put first name before the at to reply.

Neil Williams wrote:
"tim....." wrote:

I don't think the time outside the system is critical to causing the
problem here (except in as much as making it possible to transact your
genuine business within the transfer time).

You're just as likely to "time out" on a through journey that "wasn't" if
you spend 15 minutes transferring as 2 minutes.

Maybe if it times out, then, it should be reconstructed as two journeys
split at the last OSI touched. Or can't it do that?

It doesn't, but I think it should.

"Neil Williams" wrote in message
...
"tim....." wrote:

I don't think the time outside the system is critical to causing the
problem here (except in as much as making it possible to transact your
genuine business within the transfer time).

You're just as likely to "time out" on a through journey that "wasn't" if
you spend 15 minutes transferring as 2 minutes.

Maybe if it times out, then, it should be reconstructed as two journeys
split at the last OSI touched. Or can't it do that?

Well of course it should, but currently it can't.

The hard part here is that, theoretically, the journey could include two (or
more) OSIs and there (apparently) isn't enough memory on the card to keep
all of them to calculate the backtracking correctly.

But I don't see that this precludes them implementing a solution that works
automatically for the simple case. There might still be people who can't be
resolved this way, but unless I have thought this through wrongly, this
incorrect set is absolutely a subset of the current incorrect set (and
certain to be very much smaller).

tim