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.

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.
--
Roland Perry

On Jan 25, 12:13*pm, MIG wrote:

On 25 Jan, 11:59, MIG wrote:

On 25 Jan, 11:49, Mizter T wrote:
[snip]
Seems to me the basic issue with OSIs and Oyster is that the system
cannot retrospectively spilt a previously combined journey (i.e. one
involving an OSI) into two distinct journeys and charge them as such,
instead of just 'timing out' the combined journey.

If the system could do this, then I think a whole host of problems
might be resolved, however I've no idea whether it would be remotely
do-able - it would require the system to do many more calculations
each time an Oyster card was presented, I think. Maybe this is
something that the next-gen Oyster cards could do? (i.e. the on board
chip could be more complex perhaps...)

I am not sure that that approach would be necessary. *If the system
can already cope with variable timeouts, all it has to do is reset the
timeout at the same time as recalculating an OSI as a continuation.
It wouldn't need to resplit the journey with regard to the fare.

I suppose then there's the (minimal) risk of someone travelling around
all day, doing a few minutes' business only at OSIs, all charged as
one journey.

But is it justifiable to risk overcharging lots of people just to rule
out the tiny possibility of being scammed by someone whose business
involves spending a few minutes at OSIs all day?-

A question (relating to "Bob" in another thread).

Is it possible for a ticket office to terminate a journey for you, eg
when you are in an OSI but want to start a new journey, either with a
long timeout or it's now off peak but wasn't when the first journey
started?

I don't think so - at least, I've never heard of such a thing.


And if so, can they do it without resetting the cap at the same time
(which went wrong for me at Canary Wharf once)? *For the off-peak
scenario, I guess that wouldn't matter.

What happened at Canary Wharf? Let me guess - you were refunded a 'max
journey' charge back on to your card, but that all happened outwith
the context of capping on that day?

In message
, at
04:13:34 on Mon, 25 Jan 2010, MIG
remarked:
Is it possible for a ticket office to terminate a journey for you, eg
when you are in an OSI but want to start a new journey, either with a
long timeout or it's now off peak but wasn't when the first journey
started?

It's an added complication, but maybe you need a new kind of validator
(on the wall somewhere near a ticket office) which terminates your
journey *now* if you touch on it.
--
Roland Perry

On 25 Jan, 12:59, Mizter T wrote:
On Jan 25, 12:13*pm, MIG wrote:





On 25 Jan, 11:59, MIG wrote:

On 25 Jan, 11:49, Mizter T wrote:
[snip]
Seems to me the basic issue with OSIs and Oyster is that the system
cannot retrospectively spilt a previously combined journey (i.e. one
involving an OSI) into two distinct journeys and charge them as such,
instead of just 'timing out' the combined journey.

If the system could do this, then I think a whole host of problems
might be resolved, however I've no idea whether it would be remotely
do-able - it would require the system to do many more calculations
each time an Oyster card was presented, I think. Maybe this is
something that the next-gen Oyster cards could do? (i.e. the on board
chip could be more complex perhaps...)

I am not sure that that approach would be necessary. *If the system
can already cope with variable timeouts, all it has to do is reset the
timeout at the same time as recalculating an OSI as a continuation.
It wouldn't need to resplit the journey with regard to the fare.

I suppose then there's the (minimal) risk of someone travelling around
all day, doing a few minutes' business only at OSIs, all charged as
one journey.

But is it justifiable to risk overcharging lots of people just to rule
out the tiny possibility of being scammed by someone whose business
involves spending a few minutes at OSIs all day?-

A question (relating to "Bob" in another thread).

Is it possible for a ticket office to terminate a journey for you, eg
when you are in an OSI but want to start a new journey, either with a
long timeout or it's now off peak but wasn't when the first journey
started?

I don't think so - at least, I've never heard of such a thing.



And if so, can they do it without resetting the cap at the same time
(which went wrong for me at Canary Wharf once)? *For the off-peak
scenario, I guess that wouldn't matter.

What happened at Canary Wharf? Let me guess - you were refunded a 'max
journey' charge back on to your card, but that all happened outwith
the context of capping on that day?-

Sort of. I was young and foolish and thought that the Jubilee gateline
would continue an OSI from Heron Quays, having marched well beyond the
(rather badly placed) DLR pad and not bothering to turn back. Instead
it hit me with a "seek assistance", and also terminated the first
journey. I sorted that out at the ticket office, but it seemed to
reset everything, so it was charged as a new journey and the previous
stuff of the day didn't count to the cap as I recall. In that case, I
think I only lost 40p.

"martin" wrote in message
...
On Jan 25, 10:50 am, "Steve Dulieu"
wrote:
Because it doesn't always work properly. This is what happened to me over
the weekend;
As I work for LUL I'd got a new PAYG loaded Oyster with 20 quid on it for
use on National Rail.
I thought I'd read somewhere (or possibly just imagined) that LUL
staff passes could now be loaded with a PAYG balance for use where
they're not free. I take it that this isn't the case?

Indeed, PAYG cannot be added to a staff pass, we had a circular come round
at work telling us that if we wanted to use NR we should get a separate PAYG
oyster.
--
Cheers, Steve.
Change jealous to sad to reply.

On Jan 25, 1:09*pm, Roland Perry wrote:

In message
, at
04:13:34 on Mon, 25 Jan 2010, MIG
remarked:

Is it possible for a ticket office to terminate a journey for you, eg
when you are in an OSI but want to start a new journey, either with a
long timeout or it's now off peak but wasn't when the first journey
started?

It's an added complication, but maybe you need a new kind of validator
(on the wall somewhere near a ticket office) which terminates your
journey *now* if you touch on it.

No, that would make it all to complicated.

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.

In message
, at
07:32:52 on Mon, 25 Jan 2010, Mizter T remarked:
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

Yes, it probably does. That's why it's bonkers!

- 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.

Doesn't it talk to a mainframe?
--
Roland Perry

In article ,
(tim....) wrote:

wrote in message
...
In article , (Roland
Perry) wrote:

In message

,
at 16:02:48 on Sun, 24 Jan 2010, MIG
remarked:
And someone on a touristy visit is particularly likely to be caught
out, spending short amounts of time at what may turn out to be an
OSI, thus paying maximum fares and cancelling all capping.

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.

Bearing in mind that the original question is from a newbie to the
group, using such terms as OSI in a reply is stupid IMHO

I was answering Roland who is a regular here. The OP seemed to be up to
speed on the risks.

--
Colin Rosenstiel

On Jan 25, 3:43*pm, Roland Perry wrote:

In message
, at
07:32:52 on Mon, 25 Jan 2010, Mizter T remarked:

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

Yes, it probably does. That's why it's bonkers!


- 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.

Doesn't it talk to a mainframe?

No, not to perform that calculation - it's done there and then,
without any need to talk to the central database to work it out. None
of the transactions between card and Oyster pad involve live
communication with the database, which makes a lot of sense for
several reasons.

That's not to say that Oyster pads at stations aren't all hooked up to
the system, but that's not the same thing as live database look-ups
happening whenever an Oyster card is presented.

I dare say that in this and other discussions we're making a whole
host of dodgy and inaccurate assumptions, are not taking several
important factors into account, and are perhaps guilty of leaping to
conclusions - I can imagine someone who understood the guts of the
system grimacing as they read it! Nonetheless, a function that's
supposed to make life smoother and more seamless for pax - that of out-
of-station interchanges (OSIs) - does often appear to be at the root
of the problems that people encounter with Oyster.