On Sun, 10 Aug 2008, asdf wrote:

On Sun, 10 Aug 2008 10:56:02 -0700 (PDT), MIG wrote:

I think it's the OP's wording that's confusing me. It read as if the
£2 was coming up when he went through the barrier at Stratford, rather
than when he got off at Canary Wharf.

However, having gone through that barrier, he ought to be deemed to
have gone via Stratford anyway, one would have thought.

Arg. No. Can we please put this misconception to bed once and for all?

The Oyster system does NOT have an internal representation of the Tube
map, on which it runs some sort of AI software, to dynamically work
out what route you've taken, taking into account any touches you may
have made along the way, and from that work out what zones you've
passed through.

Okay. But can we also agree that it bloody well should do?

I think your implication that it would take 'some sort of AI software' to
do this is excessive. You could do it with a table.

Instead, it simply takes the origin and destination, and looks up in a
static table what zones that journey is considered to have passed
through.

Yes, much like that. But with multiple entries for journeys where there
are multiple, distinguishable, sensible routes with different sets of
zones, along with the information needed to distinguish them, which would
simply be a third station which would be on one route but not the other.
In this case, Stratford.

Routes where there isn't an intermediate Oyster contact couldn't be dealt
with like this, and would cost the highest fare. But for those where there
is such a station, and there aren't many, really, this doesn't seem like
it'd be too hard.

In order to keep complexity down, you could group routes into, er, groups,
each of which has an intermediate station, and a set of zones to be
excluded or included if that station is visited. Entries in the main route
matrix could then indicate which group they belong to, or if they belong
to no group. The group rule here would say something like "if Stratford
was visited, exclude Z1", and would contain routes from all points along
the NLL to all points on the Jubilee line east of Canada Water, or
whatever.

You need to be able to include zones too, so you can mark Wembley Park
(Z4) to Acton Town (Z3) via Rayner's Lane as including Z5, while it
excludes Z12. Although you also need to include Z3, so you can use it for
Wembley Park to Hammersmith. Does that break anything? Or use a different
group.

Maybe you could express the nature of the route simply by indicating that
it's a special route, and then assuming that the zones visited were only
the ones needed to get from the start to the zone of the intermediate
station, and then from there to the destination. No, because that breaks
on South Acton (Z3) to Canning Town (Z3) via Stratford (Z3), which goes
via Z2.

Ah, maybe you could use the routing information for the intermediate
station: if South Acton to Stratford is recorded as visting Z23, and
Stratford to Canning Town is Z3, that gives you Z3 for the whole trip.
Wouldn't that cover all possible cases fairly straightforwardly? You
wouldn't even need a special entry in the tables.

tom

--
What we learn about is not nature itself, but nature exposed to our
methods of questioning. -- Werner Heisenberg

On Sun, 10 Aug 2008 12:15:54 -0700 (PDT), MIG wrote:

But what's the difference between calculating fares between
intermediate touches and calculating fares between end points? I
can't see that it would require different software from that which
handles OOS interchanges and the rest. Oh well. It was an aside
anyway.

Ah, I see what you mean. An A-B-C journey would be deemed to have
passed through the combined zones of an A-B journey and a B-C journey.

But, well, that's not how they've done it. I suspect it would probably
be far too expensive for too little benefit to retrofit it now.

Tom Anderson wrote:
On Sun, 10 Aug 2008, asdf wrote:

I think your implication that it would take 'some sort of AI
software' to do this is excessive. You could do it with a table.

Instead, it simply takes the origin and destination, and looks up in
a static table what zones that journey is considered to have passed
through.

Yes, much like that. But with multiple entries for journeys where
there are multiple, distinguishable, sensible routes with different
sets of zones, along with the information needed to distinguish them,
which would simply be a third station which would be on one route but
not the other. In this case, Stratford.

Routes where there isn't an intermediate Oyster contact couldn't be
dealt with like this, and would cost the highest fare. But for those
where there is such a station, and there aren't many, really, this
doesn't seem like it'd be too hard.


There was a London Travelwatch report back in February which discussed
having two different fares from Richmond to Stratford, apparently it was
'deemed Z1' at that time (and probably still is). Presumably the only
reasonable way of differentiating would be by time taken, ie the NLL fastest
timetable is held in the rules, and if you beat it you're charged the higher
fare, if you don't you're charged the lower?

Paul S

On Sun, 10 Aug 2008 12:15:54 -0700 (PDT), MIG wrote:

The Oyster system does NOT have an internal representation of the Tube
map, on which it runs some sort of AI software, to dynamically work
out what route you've taken, taking into account any touches you may
have made along the way, and from that work out what zones you've
passed through.

You don't need very advanced software to do this. In fact, the problem
would be a suitable exercise for an introductory course on data structures
and algorithm analysis.

--
jhk

On Sun, 10 Aug 2008 21:37:30 +0200, Jarle H Knudsen wrote:

On Sun, 10 Aug 2008 12:15:54 -0700 (PDT), MIG wrote:

The Oyster system does NOT have an internal representation of the Tube
map, on which it runs some sort of AI software, to dynamically work
out what route you've taken, taking into account any touches you may
have made along the way, and from that work out what zones you've
passed through.

Oops, I replied to the wrong article. The above was written by asdf, not
MIG. Sorry.

--
jhk

On Sun, 10 Aug 2008 20:36:10 +0100, Paul Scott wrote:

There was a London Travelwatch report back in February which discussed
having two different fares from Richmond to Stratford, apparently it was
'deemed Z1' at that time (and probably still is). Presumably the only
reasonable way of differentiating would be by time taken, ie the NLL fastest
timetable is held in the rules, and if you beat it you're charged the higher
fare, if you don't you're charged the lower?

I suppose they could gate off the NLL at Stratford, and if you pass
through that gateline, you get charged the NLL fare. But your way is
fairer, in that if you take the Z1 route but there are delays, you
don't still get charged for the faster journey.

Although at peak time, considering how overcrowded the NLL is, it's
questionable whether people should be incentivised to switch from the
high-capacity radial routes to the 12-carriages-per-hour NLL...

On Sun, 10 Aug 2008, Jarle H Knudsen wrote:

On Sun, 10 Aug 2008 12:15:54 -0700 (PDT), MIG wrote:

The Oyster system does NOT have an internal representation of the Tube
map, on which it runs some sort of AI software, to dynamically work
out what route you've taken, taking into account any touches you may
have made along the way, and from that work out what zones you've
passed through.

You don't need very advanced software to do this. In fact, the problem
would be a suitable exercise for an introductory course on data
structures and algorithm analysis.

Indeed. Maybe it would be a good idea to send the Oyster developers on
one?

tom

--
What we learn about is not nature itself, but nature exposed to our
methods of questioning. -- Werner Heisenberg

On Aug 10, 8:26 pm, asdf wrote:

But, well, that's not how they've done it. I suspect it would probably
be far too expensive for too little benefit to retrofit it now.

Too little benefit for who? The passengers? I think they'd be quite
happy to save a quid a trip.

B2003

On Aug 10, 8:37 pm, Jarle H Knudsen wrote:
On Sun, 10 Aug 2008 12:15:54 -0700 (PDT), MIG wrote:
The Oyster system does NOT have an internal representation of the Tube
map, on which it runs some sort of AI software, to dynamically work
out what route you've taken, taking into account any touches you may
have made along the way, and from that work out what zones you've
passed through.

You don't need very advanced software to do this. In fact, the problem
would be a suitable exercise for an introductory course on data structures
and algorithm analysis.

They shouldn't even need that. Anyone with half a brain could solve
this problem - if you didn't start or end your journey in zone 1, you
travelled on the NLL and only travelled on tube lines that directly
connect to the NLL then you didn't go through zone 1.

B2003

On 11 Aug, 11:53, Boltar wrote:
They shouldn't even need that. Anyone with half a brain could solve
this problem - if you didn't start or end your journey in zone 1, you
travelled on the NLL and only travelled on tube lines that directly
connect to the NLL then you didn't go through zone 1.

[cough]West Hampstead[/cough]

U