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:

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 18 Jun 2004 14:03:43 -0700, (Gareth
Davis) wrote:

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)

And, IMO, *that* is the problem. Most sensible European public
transport systems do not have single-mode fares, as it is assumed that
any given journey is likely to include more than one mode. Also, the
artificially high Tube single fares really do not help here.

IMO, the entire fare structure needs to be rewritten to fit with
Oyster as a concept, not the other way around. As it is, it's too
complicated.

Neil

--
Neil Williams in Milton Keynes, UK
To e-mail use neil at the above domain