Anybody heard of any plans for Weekly capping ?

Presumably it would have to operate at a database level rather than from
the data held on the card, but surely this isn't beyond the ability of
TfL DBAs ??

I keep finding I do more travel than expected, and I'm paying way more
than I should do ... but I put off getting weekly/monthly travelcards in
the hope that I won't need to travel ...

Anybody heard of any plans for Weekly capping ?

Presumably it would have to operate at a database level rather than from
the data held on the card, but surely this isn't beyond the ability of
TfL DBAs ??

It does sound like it ought to be feasible though rather than spend capping
I should imagine it would have to be done on a refund basis. If that is the
case they might as well do it on a monthly basis or even a quarterly one.
I'd certainly like to see it, though it is well behind roll out of Oyster on
National Rail on my wish list.

On Mon, 15 Aug 2005, Andrew Smith wrote:

Anybody heard of any plans for Weekly capping ?

Nope.

Presumably it would have to operate at a database level rather than from
the data held on the card,

Why?

I keep finding I do more travel than expected, and I'm paying way more
than I should do ... but I put off getting weekly/monthly travelcards in
the hope that I won't need to travel ...

Same here. Weekly, monthly and annual capping would indeed be extremely
useful.

It is potentially very complicated, though - unlike with daily capping,
there are no fixed boundaries between weeks, so deciding which days to
cover with a ticket could be tricky. For example, say you do the following
travelling:

sun - spend the day going round Z1
mon - stay at home
tue - spend the day going round Z1
wed - spend the day going round Z1
thu - spend the day going round Z1
fri - spend the day going round Z1
sat - spend the day going round Z1
sun - spend the day going round Z1
mon - spend the day going round Z1

Daily capping would charge you for a Z1 1DTC (6.00 UKP) each day you used
the tube. A simple implementation of weekly capping would kick in once
your spend crossed 18.50 UKP, which would be some time on thursday
morning, replacing your three 1DTCs and one single with a 7DTC. That 7DTC
would cover you for friday and saturday too; you'd then end up with 1DTCs
for sunday - monday.

However, if you'd actually been buying tickets, you would probably have
bought a 1DTC on sunday, then a 7DTC to cover tuesday to monday. The naive
capping has charged you 6.00 more than you needed to pay!

Is this a problem? Personally, i think so - for capping to replace
pre-buying of period tickets, it has to guarantee to never be more
expensive, otherwise people won't trust it. Some may feel that as long as
the system is transparent and predictable, it doesn't matter if it's not
always perfectly cost-efficient - if it's going to shaft you, you'll know,
and you can buy a ticket upfront to defeat it.

If you do want a perfect system, then the complexity of the system
increases dramatically - i'm not at all certain, but my gut feeling is
that the problem of figuring out the optimal combination of tickets to
cover arbitrary travel patterns is what computer scientists call
'NP-hard', which is their way of saying 'bloody hard'!

tom

--
It sounds very much like a rock group consisting of a drum machine and a
few 56k modems. -- Jon

On Mon, 15 Aug 2005 16:46:30 +0100, Andrew Smith
wrote:

Anybody heard of any plans for Weekly capping ?

In a word, no.

Presumably it would have to operate at a database level rather than from
the data held on the card, but surely this isn't beyond the ability of
TfL DBAs ??

The problem is that there's no easy mechanism for the data on the card
to be updated according to changes that take place at the database
level.

On Mon, 15 Aug 2005 17:43:02 +0100, Tom Anderson
wrote:

If you do want a perfect system, then the complexity of the system
increases dramatically - i'm not at all certain, but my gut feeling is
that the problem of figuring out the optimal combination of tickets to
cover arbitrary travel patterns is what computer scientists call
'NP-hard', which is their way of saying 'bloody hard'!

I don't think NP-complete-ness is really the problem - I think it's
really the one which you described in detail, i.e. due to the
overlapping validity of weekly travelcards, it's impossible to decide
at any given time what the cheapest combination of tickets will be
without knowing about all future travel.

To extend your example:

sun - spend day going round Z1
mon - stay at home
tue - spend day going round Z1
wed - spend day going round Z1
thu - spend day going round Z1 [cheapest: 7DTC starting Sun]
fri - spend day going round Z1
sat - spend day going round Z1
sun - spend day going round Z1
mon - spend day going round Z1 [cheapest now: 7DTC starting Tue]
tue - spend day going round Z1
wed - spend day going round Z1
thu - spend day going round Z1 [cheapest now: 2x7DTC starting Suns]
fri - spend day going round Z1
sat - spend day going round Z1
sun - spend day going round Z1
mon - spend day going round Z1 [cheapest now: 2x7DTC starting Tues]
tue - spend day going round Z1
wed - spend day going round Z1
thu - spend day going round Z1 [cheapest now: 3x7DTC starting Suns]

....and so forth. Thus the system could have to be constantly
rearranging the combination of tickets you have owned for a
potentially unlimited time into the past.

In fact a similar problem exists with 1 day travelcards, due to the
fact that the current and next day's travelcard are valid for an
overlapping period between 0000 and 0429. Daily capping gets around
this by making the "capping day" last only from 0430 to 0429 the next
day - so any travel between 0000 and 0429 is always counted towards
the "previous" day's cap (and thus there are scenarios where a paper
ODTC is actually cheaper).

In theory the same sort of thing could be done to allow weekly capping
- by making the weekly cap only apply from (say) Sunday to the
following Saturday. If you wanted a "7DTC" starting on any other day
you would still have to buy it in advance in the usual way.

Is this a problem? Personally, i think so - for capping to replace
pre-buying of period tickets, it has to guarantee to never be more
expensive, otherwise people won't trust it. Some may feel that as long as
the system is transparent and predictable, it doesn't matter if it's not
always perfectly cost-efficient - if it's going to shaft you, you'll know,
and you can buy a ticket upfront to defeat it.

I guess the key point is whether a capping or other usage based discounting
system would run alongside period tickets or if it would eventually replace
some or all of them. In the longer term would period tickets even be
necessary? It seems to me a complete change to the fares model can be
achieved once paper tickets are eliminated.

On Mon, 15 Aug 2005 18:12:11 +0100, asdf
wrote:

...and so forth. Thus the system could have to be constantly
rearranging the combination of tickets you have owned for a
potentially unlimited time into the past.

I think we need to think outside the box on this, and a possibility
would be, once seasons are all on Oyster, to abandon the concept of
season tickets completely. You'd then define:-

1. One or more single fares, as few as feasible.
2. A daily rate, perhaps with a peak/offpeak differential.
3. A specific value of discount if, in any given 4-week period, 5 days
are capped at the daily rate (yes, including split weeks - why not!).
4. A specific value of additional discount if, in any given 4-week
period, 20 days are capped at the daily rate.
5. A specific value of additional discount if, in any given 12-month
period, N[1] 4-week discounts are given.

These are *almost* equivalent to a weekly, monthly or annual - but
much easier (though not simplicity itself) to implement.

Paper tickets are designed for issue on paper. We need a totally
different fares structure for Oyster.

[1] I can't be bothered working it out, but it would be the number of
workdays in a year minus a slightly above-average number of holidays.

Neil

--
Neil Williams in Milton Keynes, UK
When replying please use neil at the above domain
'wensleydale' is a spam trap and is not read.

Andrew Smith wrote:
Anybody heard of any plans for Weekly capping ?

No, I've never so much as a whisper, at least not from TfL. The only
place I've ever read the words 'weekly capping' is on this newsgroup
(or on uk.railway).

As other posters have mentioned it would be very complex to implement,
and even if it were possible, it could well cause a large amount of
passenger confusion.

asdf wrote:
On Mon, 15 Aug 2005 17:43:02 +0100, Tom Anderson
wrote:

If you do want a perfect system, then the complexity of the system
increases dramatically - i'm not at all certain, but my gut feeling is
that the problem of figuring out the optimal combination of tickets to
cover arbitrary travel patterns is what computer scientists call
'NP-hard', which is their way of saying 'bloody hard'!

I don't think NP-complete-ness is really the problem - I think it's
really the one which you described in detail, i.e. due to the
overlapping validity of weekly travelcards, it's impossible to decide
at any given time what the cheapest combination of tickets will be
without knowing about all future travel.

To extend your example:

sun - spend day going round Z1
mon - stay at home
tue - spend day going round Z1
wed - spend day going round Z1
thu - spend day going round Z1 [cheapest: 7DTC starting Sun]
fri - spend day going round Z1
sat - spend day going round Z1
sun - spend day going round Z1
mon - spend day going round Z1 [cheapest now: 7DTC starting Tue]
tue - spend day going round Z1
wed - spend day going round Z1
thu - spend day going round Z1 [cheapest now: 2x7DTC starting Suns]
fri - spend day going round Z1
sat - spend day going round Z1
sun - spend day going round Z1
mon - spend day going round Z1 [cheapest now: 2x7DTC starting Tues]
tue - spend day going round Z1
wed - spend day going round Z1
thu - spend day going round Z1 [cheapest now: 3x7DTC starting Suns]

...and so forth. Thus the system could have to be constantly
rearranging the combination of tickets you have owned for a
potentially unlimited time into the past.

In fact a similar problem exists with 1 day travelcards, due to the
fact that the current and next day's travelcard are valid for an
overlapping period between 0000 and 0429. Daily capping gets around
this by making the "capping day" last only from 0430 to 0429 the next
day - so any travel between 0000 and 0429 is always counted towards
the "previous" day's cap (and thus there are scenarios where a paper
ODTC is actually cheaper).

In theory the same sort of thing could be done to allow weekly capping
- by making the weekly cap only apply from (say) Sunday to the
following Saturday. If you wanted a "7DTC" starting on any other day
you would still have to buy it in advance in the usual way.


I think both asdf's and Tom Anderson's hypothetical examples hit the
nail on the head. It's a good point to note that not all days are equal
- on saturdays, sundays and public holidays an off-peak Day Travelcard
is acceptable for use all day long and passengers benefit from the
off-peak Oyster fares, whilst normal weekdays have the added
peak/off-peak division (the boundary of which is at different times -
Day Travelcards and Pre Pay on buses become off-peak fares at 9.30am,
but Pre Pay on the Tube only becomes off-peak at 7pm).

And it's a good point that asdf makes regarding the fact that a paper
Day Travelcard (because of it's 28 and a half hour validity) may be
better value than a capped Pre Pay fare. This is particularly apparent
should one be travelling on a late tube after midnight, and also need
to travel the next day.

On Mon, 15 Aug 2005, Neil Williams wrote:

On Mon, 15 Aug 2005 18:12:11 +0100, asdf
wrote:

...and so forth. Thus the system could have to be constantly
rearranging the combination of tickets you have owned for a
potentially unlimited time into the past.

I think we need to think outside the box on this, and a possibility
would be, once seasons are all on Oyster, to abandon the concept of
season tickets completely.

I agree entirely!

That is all.

tom

--
All we need now is a little energon and a lotta luck