Re: Oysterisation

On 12 Jan, 18:07, "Mizter T" <mizte...@xxxxxxxxx> wrote:
On 12 Jan, 13:22, Jens Kr. Kirkebø <jkirkebo.tabortde...@xxxxxxxxx> wrote:



On Mon, 12 Jan 2009 04:58:24 -0800 (PST), plcd1 <pl...@xxxxxxxxxxx>
wrote:

Sort of.  The real issue was with those people who worked part time (3
days a week) or whose work locations were highly variable making it
hard to commit to a long term product that is partly defined by zonal
geography.  They'd end up probably having to commit to Z1-6 when in
reality may only use one day a week - that's obviously not value for
money.  At the time we did not have peak one day travelcards either so
peak hour travel was another issue for people who may travel in the
peak one day a week but off peak the rest of the time.   You can see
how Oyster Capping works to deal with some of these issues but only on
a daily basis rather than weekly or longer caps.

That is puzzling, why does the system not deal with longer caps ?
Surely there should not be a problem computing the cheapest possible
fares for any periode ? Like if you travel zone 1-2 for a week except
one trip to zone 6, the cheapest should be a one week travelcard with
one extension ticket ?

This has been discussed a number of times on uk.transport.london before -
the basic conclusion is that the underlying calculations that would be
needed in order for such a scheme to work would simply be too complicated..
Bear in mind that capping is something that happens without recourse to a
central database - the Oyster card and the validators interact and
appropriate caps are applied according to the rules. The processing required
to work out whether weekly, monthly or annual caps would apply is just
totally infeasible in this situation for many reasons - the complexity of
the calculation is one thing, the fact that the card would have to hold a
record of all its usage in the past week/ month/ year is another.

OK, you might say, in that case let the central database work it out. But
that's not a workable scenario either. Each time a card is validated
(touched-in/out) there is *not* a live transaction with the central
database - if there was then the whole thing would be much much slower and
would simply die if the live link with the central database got cut for
whatever reason (and there are a multitude of reasons). Then the central
database would be having to carry out an immensely complicated calculation
each time a card got validated anywhere on the system and then feed back the
results of that calculation to the validator, and this would all have to
happen in an instant. It's just not going to work.

So it's not really that puzzling why it doesn't happen. In many many years
to come when the technology could handle it, maybe - but now, it's just not
a goer.

See this August '05 utl thread for a past discussion on this issue:http://groups.google.co.uk/group/uk.transport.london/browse_frm/threa...

I don't know....thinking about it, I think there's no reason a
distributed system could not be developed. Computing hardware is
(relatively) dirt cheap and tiny these days. Each station site could
quite easily hold a replicated mirror of the entire database and
obviously the hardware required to work with it. Such mechanisms are
already present in most if not all mainstream database products that
are more than toys, so it's far from the realm of fantasy to expect a
specialist system to handle it. If the slave system cannot contact the
master database, queue up the transactions, continuing to operate as
normal. When contact is restored, reconcile the transactions. Hell, I
suspect you could conceivably fit the hardware into a little black box
on a bus no bigger than a spare wheel and sync up via wireless at the
depot or at hotspot at the end of the route. If you need immediacy,
push updates (debits/credits/journeys?) to the mothership via the
mobile network when it can. I'm sure a peer to peer system could also
be investigated to distribute the updates, removing the need for a
super-powered central master server, meaning that if there were things
like power failures somewhere important the system would just plod on
as normal, routing around the damage. Not to mention, you'd always
have plenty of backups :)

....I don't know, probably expensive, but certainly not "It's just not
going to work.", and it /would/ be very robust and flexible.
.

Relevant Pages

  • Re: Form quit, bypasses cancel in textboxes BeforUpdate
    ... Just about every pc database product. ... would love to find that shortcut, and the instant pain killer. ... >> have to resort to using the forms before update event). ... there is lots of reasons for the above: ...
    (microsoft.public.access.formscoding)
  • Re: 3vl 2vl and NULL
    ... >> number of NULLs to denote the various reasons why data can be missing. ... You, like any database, have only the values. ... >> fact at all for Uncle Vernon in the fact table for a person's age. ... >- My family member Aunt Marge has an age of 47 years. ...
    (comp.databases.theory)
  • Re: Error Message: Two few parameters, Expected 2
    ... reasons the records are not saving properly to the database. ... Here the sql statement is referencing the form for the susgrant ... >> Dim rst As Recordset ...
    (microsoft.public.access.modulesdaovba)
  • What does this NULL mean?
    ... The number of long threads about NULLs indicates that they are a source of difficulty and disagreement. ... All this situation is telling us is that there is no C value in the database for this value of A. It does not matter how many possible reasons there are for the existence of this situation, we do not know why there is no value. ... Actually presenting lots of possible reasons was a very bad argument because only if there was exactly one reason would we know what was going on. ... There is no guarantee that there is a single form of representation for each of the reasons, and hence no general way of implementing a NULL. ...
    (comp.databases.theory)
  • Re: What is the difference between logging into an AD Domain versus connecting to network resource?
    ... The term "domain" means nothing than the "central database of user ... you can provide either login/pwd that is stored locally - ... When you log on by using a login/pwd that is stored in the central database ... the same way as with your local account. ...
    (microsoft.public.windows.server.security)
Loading