"Ben Nunn" wrote in message ...
"Gareth Davis" wrote in message

Performing all the calculations required to get the 'instant' capping
to work (based on your last few journies) in the time you have your
card over the reader then to write back the refund to the card while
it is still in range is a non-trivial exercise - and is limited by the
length of the journey record kept on the card. This record needs to
hold every journey over the capping period for the calculation to be
correct.


This seems like poor design to me - surely all the card needs to contain is
a unique ID, and all the other information could be contained within a
centralised database?

BTN

Which would require all card readers to be perminantly connected to
the central database. While this is easy with the fixed station
readers it is far more difficult to do with the bus ticket machines,
or the hand held terminals in use on the DLR or by the RPIs -
especially given they are often underground well out of range of the
GSM networks. I would expect (although I'm only guessing since I don't
work for LT or Cubic) that the mobile readers will store details of
all transactions then offload them to the central database when they
are docked at the end of each working day. Hence working it all out
retrospectivly is much easier (and likely to be more accurate) than
working in real time.

It is for the same reason that you cannot (and never will) be able to
buy a travelcard over the internet from home then use it on a bus
straight away - the bus won't know you have purchased it. Depending on
how large the drivers memory cards are in the bus readers it may be
possable to download the _entire_ list of _all_ online purchases into
them every 24 hours so you could pick up your travelcard on the bus
first thing - provided you purchased it the previous day. IMHO that is
the best that could be achieved with the current hardware without
installing some kind of mobile data link to each bus.

Unless someone 'on the inside' knows better....

--
Gareth Davis

Ian Tindale wrote in message ...

But how do the weekly season tickets work? Are they some sort of blanket
'I've paid' signal that last a whole week? I'd have thought the same sort
of system would work for an off-peak one day travelcard* that simply says
'I've paid, let me through' and the oyster reader says 'is it after 9:30?

If you buy the peak travelcard in advance it will work as you suggest.
But in my example the passenger had not and it was upto the capping
system to work out that he/she should have done that to get the
cheepest fare for the days travel, rather than paying for the journeys
seperatly, then refund the excess prepay spent so they only ended up
paying for the peak travelcard even though he/she didn't buy one to
start with.

yep, okay'. Capping sounds complicated, whereas a straightforward off-peak

I don't think anyone will disagree with that!

one day travelcard itself that works in the same way as a weekly (ie, don't
need to plonk on the reader on the way in or out of the station, but
nevertheless registers as valid when the driver comes up and inspects your
ticket) sounds quite simple in concept.

To bring this back to the subject of this thread, I agree if you
ignore prepay than there is no reason why it could not be set up very
quickly - it's just a shorter validity version of the tickets already
available. However the lack of the one day travelcards/tickets on
Oyster makes a nice excuse for capping not to be available - after all
Oyster does not do day tickets so it can't cap the prepay fares down
to them


* Certainly not a peak - what's the point in such a minority-use ticket -
costs too much - never ever used one, never heard of anyone else paying for
one either.

If you need a travelcard for the day - but your first tube journey is
during the morning peek it is cheeper to get a peak day travelcard
than to buy a single then an off-peak travelcard in most (all?) cases.

--
Gareth Davis

In article , Gareth
Davis writes
For example if only the last 10 journeys are held and the period is 24
hours then a two zone tube journey could be made on peak (£2 prepay),
followed by 10 bus journeys (that would be capped at £2.50 for a one
day bus pass), followed by another £2 tube journey. The bus journeys
would have 'pushed off' the first tube journey resulting in a £6.50
total for the day rather than a £5.30 day travelcard because the first
journey can no longer be 'seen' by the program in the gate responsible
for the capping. While I admit this is a very contrived example it
illustrates the problem well

And the answer is obvious - don't program it that way. Instead, keep a
sufficient state to allow you to deduce what possibilities could come
up. So, for example, the pass slots can hold entries on the amount of
bus and rail fare paid that day. If I modify your example slightly, and
start with a completely blank card, the sequence would be:

Passes Last 10 journeys
1.00 0.00 Bus
1.00 2.00 Bus, Rail
2.00 2.00 Bus, Rail, Bus
BusP 2.00 Bus, Bus, Rail, Bus
BusP 2.00 Bus, Bus, Bus, Rail, Bus
BusP 2.00 Bus, Bus, Bus, Bus, Rail, Bus
BusP 2.00 Bus, Bus, Bus, Bus, Bus, Rail, Bus
BusP 2.00 Bus, Bus, Bus, Bus, Bus, Bus, Rail, Bus
BusP 2.00 Bus, Bus, Bus, Bus, Bus, Bus, Bus, Rail, Bus
BusP 2.00 Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Rail, Bus
BusP 2.00 Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Rail
BusP 2.00 Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus
T/card Rail, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus

- especially if the capping period is
scaled up substantially (to say, 1 week) without increasing the
journey storage capacity on the cards.

Same solution.

And once you increase the
amount stored on the card it takes longer to read and write back -

And doing it this was doesn't affect the amount to be transmitted (in
particular, you don't need to send the list of previous journeys).

--
Clive D.W. Feather | Home:
Tel: +44 20 8495 6138 (work) | Web: http://www.davros.org
Fax: +44 870 051 9937 | Work:
Please reply to the Reply-To address, which is:

(Gareth Davis)typed


If you need a travelcard for the day - but your first tube journey is
during the morning peek it is cheeper to get a peak day travelcard
than to buy a single then an off-peak travelcard in most (all?) cases.

It certainly was for me yesterday, when I did a *lot* of travelling.
I ended up using three types of ticket to get the cheapest options.

Bus Pass for my first trip from home.
PrePay Oyster to get to Kings Cross for 7.20am
6 zone ODTC to go to class in Golders Green, return to Burnt Oak & then
Met Line to Uxbridge in the evening...

--
Helen D. Vecht:
Edgware.

In ,
Ian Tindale typed:

*and that's another thing - why was I penalised £3 just to carry
around this useless card for a while?


I have always presumed that the £3 deposit is charged to cover the potential
cost of somebody making a multi-zone journey when there isn't enough credit
left on the card. An Oyster with a travelcard can just block use until a
'pre-pay journey in excess of credit' has been undertaken, whereas a PrePay
only card-holder could just throw the card away and buy another if it were
not for the deposit which has been paid.


Bob

"Gareth Davis" said...

While this is easy with the fixed station
readers it is far more difficult to do with the bus ticket machines,
or the hand held terminals in use on the DLR or by the RPIs -
especially given they are often underground well out of range of the
GSM networks. I would expect (although I'm only guessing since I don't
work for LT or Cubic) that the mobile readers will store details of
all transactions then offload them to the central database when they
are docked at the end of each working day. Hence working it all out
retrospectivly is much easier (and likely to be more accurate) than
working in real time.

So, is it possible to retrospectively work out capping details after the end
of each working day, and then refund the difference back into each Oyster's
prepay account if needed?

Solar Penguin wrote:
"Gareth Davis" said...

While this is easy with the fixed station
readers it is far more difficult to do with the bus ticket machines,
or the hand held terminals in use on the DLR or by the RPIs -
especially given they are often underground well out of range of the
GSM networks. I would expect (although I'm only guessing since I don't
work for LT or Cubic) that the mobile readers will store details of
all transactions then offload them to the central database when they
are docked at the end of each working day. Hence working it all out
retrospectivly is much easier (and likely to be more accurate) than
working in real time.


So, is it possible to retrospectively work out capping details after the end
of each working day, and then refund the difference back into each Oyster's
prepay account if needed?

I think so - but only when the Oyster comes back into contact with the
system again, which may not necessarily be for some time. I think this
would be extremely confusing for passengers too.

--
Dave Arquati
Imperial College, SW7
www.alwaystouchout.com - Transport projects in London

And the answer is obvious - don't program it that way. Instead, keep a
sufficient state to allow you to deduce what possibilities could come
up. So, for example, the pass slots can hold entries on the amount of
bus and rail fare paid that day. If I modify your example slightly, and
start with a completely blank card, the sequence would be:

[...snip...]
T/card Rail, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus, Bus

The problem here is that there isn't enough information passed to apply the
cap. In the example the first rail journey was zone 1 and 2 costing 2 quid,
but two single journeys in any of zones 2 to 6 would also come to 2 quid.
So a peak 1-2 travelcard might not be valid for the day's journeys.

However I do acknowledge you said "sufficient state" and "for example". A
practical solution would presumably require booleans indicating zones passed
through by rail, both in peak and off-peak, as well as running totals.

The last journey would also need to be read, of course, to allow for the
'continuation of exit' situation mentioned elsewhere recently, and to allow
for things like feeder buses and permitted changes of tram on Tramlink.
Indeed having pondered the Tramlink situation where you are required to
touch in at the tramstop even when changing trams as part of a single
journey (thus at the moment being charged more than a paper ticket), I can't
see anyway they can implement the capping on it unless they consider all
journeys within a 90 minute period as a single journey. In this case
validators will have to read the rest of the journey history anyway to see
if they need to charge. So even with sufficient state the journey history
probably needs to be transferred anyway (at least it does on Tramlink).

Does anyone actually know how it is being done, by the way. I haven't been
clear if other contributors have actually been speaking authoritatively or
just speculating as wildly as I am.

"Graham J" wrote in message ...

However I do acknowledge you said "sufficient state" and "for example". A
practical solution would presumably require booleans indicating zones passed
through by rail, both in peak and off-peak, as well as running totals.


I've been having a think about this, trying to work out prepay rebate
just from the journey history already stored on the card is crazy -
even if it was me that suggested it It will never work without a
huge journey history which will take longer to read-process-write and
so add to the wait before the touch pad gives you the green light.

My best guess is that it would work by keeping count of each of the
possible journey types that can be made by prepay, which (for an
adult) I reckon is only 24 based on:

11 tube fares (both on or off peak)
1 bus fare
1 tramlink fare (needs to be seperate from bus to work out travalcard
validity)

You would also need to store the current 'capped' state of the card
which would be something like uncapped/Z12 peak travelcard/bus pass
etc. plus the amount refunded onto the card.

So based on the original example:

-------------------- Information Stored --------------------
Journey: Charge: Refund: Status: Z12Pk: Bus: Z12OPk: All others:
Z12Peak 2.00 0.00 Uncapped 1 0 0 0
Bus 2.70 0.00 Uncapped 1 1 0 0
Bus 3.40 0.00 Uncapped 1 2 0 0
Bus 4.10 0.00 Uncapped 1 3 0 0
Bus 4.80 0.30 Bus Pass 1 4 0 0
......
Bus 9.00 4.50 Bus Pass 1 10 0 0
Z12OffPeak 11.00 5.70 Z12Pk TCard 1 10 1 0

In addition you would need to store the last couple of validations for
spotting out of station transfers and passbacks.

Provided some kind of integer overflow does not occur then you can
make a couple of hundred journeys a day with the system still able to
keep track of you. Although full details of the last couple of
validations will still be required in order to spot continuations and
passbacks.


Does anyone actually know how it is being done, by the way. I haven't been
clear if other contributors have actually been speaking authoritatively or
just speculating as wildly as I am.

I'm making it up as I go along! However if someone from TfL/CTS does
want to know how my 'best guess' can be extended to work in a period
longer than 24 hours (I know it won't work for a longer capping
period) then I'm sure I can discuss it for a small consultation fee

--
Gareth Davis

On 15 Jun 2004 16:10:43 -0700, (Gareth Davis)
wrote:

"Ben Nunn" wrote in message ...

Capping needs to be introduced, and it needs to be smart and effective. The
£90/50 Prepay limit needs to be abolished and the 'nominate a specific
station to pick up your credit' thing must go. Also, a Non-prepay
Pay-as-you-go that bills your credit/debit card would also be far better
than having to add value to the card periodically.

Performing all the calculations required to get the 'instant' capping
to work (based on your last few journies) in the time you have your
card over the reader then to write back the refund to the card while
it is still in range is a non-trivial exercise - and is limited by the
length of the journey record kept on the card. This record needs to
hold every journey over the capping period for the calculation to be
correct.

For example if only the last 10 journeys are held and the period is 24
hours then a two zone tube journey could be made on peak (£2 prepay),
followed by 10 bus journeys (that would be capped at £2.50 for a one
day bus pass), followed by another £2 tube journey. The bus journeys
would have 'pushed off' the first tube journey resulting in a £6.50
total for the day rather than a £5.30 day travelcard because the first
journey can no longer be 'seen' by the program in the gate responsible
for the capping. While I admit this is a very contrived example it
illustrates the problem well - especially if the capping period is
scaled up substantially (to say, 1 week) without increasing the
journey storage capacity on the cards. And once you increase the
amount stored on the card it takes longer to read and write back -
causing lots of '96 Seek Assistance' errors as people pull the cards
away too fast without waiting for the green light. These are not easy
(or cheep) problems to solve - which probably explains the length of
time it is taking to come up with a 100% working solution - if one is
ever found.

Right - I have NOT seen the official documentation for capping but
surely the logic is something like this from your example.

Z12 peak Tube journey - automatically means that the ticket capping
price has to have Tube validity, cover Z12 and be peak priced. As NR
stations do NOT have validators you will be capped to the Z123456 One
Day LT Card price £8.20. All subsequent pre-pay journeys will simply
add up against this total until it is exceeded. If you travel to another
zone beyond Zone 6 then the cap will increase.

Where this gets horrendous is the complication with NR services. One Day
Travelcards are obviously valid on these services but if Pre-Pay
validation facilities are not available at the majority of stations -
and they aren't - then I do not see how TfL can introduce capping set at
Peak or even Off Peak One Day Travelcard prices because the validity of
the pre-pay capped product cannot match that of the paper encoded
ticket.

Another poster mentioned the Tramlink issues and while I understand that
issue as well as the DLR "within gateline" validation issues I think
these are small scale when compared with the fundamental pricing point.
I suppose TfL could introduce a surrogate LT Card pricing scale that
sets caps for Z12, Z1234 combinations as well as off peak prices to
avoid everyone howling that a cap of £8.20 is a rip off.

Other issues to be borne in mind include how capping works with rail
replacement services, when gates are in evacuation mode, when tube
passengers are transferred to local bus services and when a station
close to or at a zone boundary is closed and people have to travel
beyond their zone to exit. If such a journey was to trigger a higher cap
being activated then the public would be rightly annoyed. While the LU
system has features to cope with these eventualities and they were in
the very earliest documents I saw these need a significant amount of
testing in order to ensure they work seamlessly and that the public can
be told that they have not been financially disadvantaged.

--
Paul C


Admits to working for London Underground!