"Leap" into the unknown: The feedback thread

http://www.nationaltransport.ie/public-transport-services/fares/integrated-fares/

Don't think I've seen this before.

It is the ambition of the Authority to ensure that fares are simplified across all modes and that fares do not penalise those passengers who change services in their journey.

In the Authority’s Draft Transport Strategy 2011-2030 Measure INT 3 states:
“The Authority will implement a simplified fares system for the Greater Dublin Area, covering bus, rail, LUAS and Metro services, and will develop a fare arrangement within the Metropolitan Area that facilitates multi-leg and multi-modal journeys”

The mechanisms to achieve the Authority’s strategy include flat fares, fare capping (by time or distance), fare rebates and zonal fares.
The Authority is currently examining the feasibility of introducing single operator daily and weekly capping at an early stage. This would mean that there would be a maximum charge per day or week for the journeys done with one public transport operator. The next phase would be to introduce a cap across all operators for daily and weekly journeys. A fare rebate is where the public transport customer pays a reduced amount for second or multiple journeys within a particular time frame. The feasibility of introducing this fare on a single and multi-operator basis is also being examined.

Zonal fares schemes are most successful where the public transport customer tags on and off to complete their journey such as with Irish Rail and LUAS. However Dublin Bus does not operate a tag off on their smartcards so there is no way of knowing the length of the journey in order to apply a zonal fare. In some cities a flat fare on buses can accompany a zonal fare on other operators.

While the ambition of the Authority is stated above, it is important to note the financially constrained environment in which we are currently operating. Further integrated fares measures must be introduced without resulting in the overall revenue from fares being reduced. The key benefit of the introduction of the Leap Card is that it provides the platform to introduce any of these integrated fare schemes in the future.

It really wouldn't be that big a deal to bring in the option of tag-on tag-off on dublin bus if it is a significant obstacle.

It is a fine statement of intent.

They have till 2030

Hopefully we'll get capping and some sort of rebates long before that.

Well, it isn't just a matter of incrementally adding bits and bobs to the fare system. You just make it more complicated

It really needs an overall plan.

foggy_lad

Stevek101 wrote: »

They have till 2030 Hopefully we'll get capping and some sort of rebates long before that.

Going on their current performance I doubt if many people will trust the leapcard system to cap their spending at the correct limits. People just don't have enough faith in it considering how long it has already taken and that it was rolled out without any of the basic functionality one might expect.

The poor website experience, overcharging, top-up issues and problems with customer care because Dublin Bus are not on board and insist on dealing with all refunds by dragging the poor customers into their head-office gives the impression of something which even the transport operators don't fully trust!

Once I can stick a 30 Day Rambler on it, I'll be sorted. Mind you it probably won't switch between product and e-purse depending on your usage...

BrianD

Stevek101 wrote: »

Don't think I've seen this before.

http://www.nationaltransport.ie/public-transport-services/fares/integrated-fares/

Ok, I think it's fair to say that as an integrated ticketing solution, LEAPCARD is a failure after all the money that has been spent.

All LEAP is a method of payment that replaces is cash and the only convenience is that which normally comes with a cashless system - the tap on or off on some modes.

The passenger is not in control of their costs because every journey is priced as a single journey.

BrianD wrote: »

Ok, I think it's fair to say that as an integrated ticketing solution, LEAPCARD is a failure after all the money that has been spent.

All LEAP is a method of payment that replaces is cash and the only convenience is that which normally comes with a cashless system - the tap on or off on some modes.

The passenger is not in control of their costs because every journey is priced as a single journey.

In fairness that was always the plan for Phase 1. Phase 2 will see capping and products added for a single operator. I know DB seem to think tickets will be added in August, probably to coincide with the launch of the student Leap. But when that actually happens is anyone's guess.

Carawaystick

markpb wrote: »

Actually, without using the reverse system described by lxflyer (and which will be introduced on Leap), it's impossible. You cannot update a smartcard without introducing it to a reader. They're not internet connected, they don't have a phone line, they don't have any way to talk to the outside world. This isn't a Leap problem it isn't a Dublin problem, it's a fundamental characteristic of smartcards.

Why not apply the network connectivity similar to a shop to the reader on a bus?

The readers in train and tram stations do this afaik

If the 3G reception is too flaky over the areas DB serves, then apply the information overnight in the garages, so you'ld have a list of cards with online top ups to be applied, the amount of top up, and transmit back by 3G when a card has been presented.

Carawaystick wrote: »

Why not apply the network connectivity similar to a shop to the reader on a bus?

Too slow and too unreliable. If your tag on involved a trip over a wireless network connection to a host and back again, it would be orders of magnitude slower and wouldn't work if there was a problem/timeout/no connectivity. IIRC the target time for an ePurse transaction is about 350ms. It's not possible to guarantee that when you have to do the card interaction and then go to a remote host.

The readers in train and tram stations do this afaik

I don't think so. AFAIK all card transactions are offline.

If the 3G reception is too flaky over the areas DB serves, then apply the information overnight in the garages, so you'ld have a list of cards with online top ups to be applied, the amount of top up, and transmit back by 3G when a card has been presented.

The reason you can't pick up topups on buses is because DB's Wayfarer wouldn't have enough memory to hold all the possible topups for every DB nominated Leap card.

Carawaystick

markpb wrote: »

Too slow and too unreliable. If your tag on involved a trip over a wireless network connection to a host and back again, it would be orders of magnitude slower and wouldn't work if there was a problem/timeout/no connectivity. IIRC the target time for an ePurse transaction is about 350ms. It's not possible to guarantee that when you have to do the card interaction and then go to a remote host.

I don't think so. AFAIK all card transactions are offline.

How are online top ups collected at tram and train stations?
My understanding is you just tag on and your credit is applied

markpb wrote: »

The reason you can't pick up topups on buses is because DB's Wayfarer wouldn't have enough memory to hold all the possible topups for every DB nominated Leap card.

Memory is dirt cheap in the context of 50,000,000 spent on this crock so far.

Carawaystick wrote: »

How are online top ups collected at tram and train stations?
My understanding is you just tag on and your credit is applied

AFAIK (and I could be wrong), they're dispatched to each card reader at semi-regular intervals and left there for collection.

Memory is dirt cheap in the context of 50,000,000 spent on this crock so far.

Perhaps but it's still the reason. I'm not defending it, just explaining why. Perhaps the ticket machines can't be upgraded (they're not PCs after all....) or perhaps they're so slow that even if they could download all the actions, searching the persistent memory each time a person tagged on would be too slow.

Carawaystick

markpb wrote: »

AFAIK (and I could be wrong), they're dispatched to each card reader at semi-regular intervals and left there for collection.

This is what I thought

markpb wrote: »

Perhaps but it's still the reason. I'm not defending it, just explaining why. Perhaps the ticket machines can't be upgraded (they're not PCs after all....) or perhaps they're so slow that even if they could download all the actions, searching the persistent memory each time a person tagged on would be too slow.

So despite the money spent, the DB machines aren't fit for purpose?

Carawaystick wrote: »

So despite the money spent, the DB machines aren't fit for purpose?

The DB Wayfarer machines were bought years ago, perhaps around 2004-2006.

LXFlyer

Carawaystick wrote: »

So despite the money spent, the DB machines aren't fit for purpose?

They are no different to the machines used by London Buses so I'd hardly call them not fit for purpose.

The issue frankly is the delayed rollout of the online auto top-up.

foggy_lad

Carawaystick wrote: »

This is what I thought

So despite the money spent, the DB machines aren't fit for purpose?

The wayfarer machines could be used to store all top-up information for every top-up made overnight but it would mean every machine(several thousand?) would have details of every single top-up and would have to check each and every card presented throughout the day to see if it was due a top-up.

better to have a machine connected to the system delivering top-ups to cards, it willl be faster and will involve less crashes and less problems for all concerned.

It really wouldn't be that difficult to have the DB ticket machines support online top ups. It would work by:

- Every night, every bus gets a full list of all top ups for the next day.
- During the day the top up is applied when the card is presented. Only one top up is allowed per 24 hour period, to avoid the issue of the topup being applied twice on two different buses.
- When the bus returns to depot, all topups it made are reported back to the Leap back end.

I have don't the maths and the file with all available topups wouldn't be large. I've calculated that even if 400,000 topups were to be made in one day (very unlikely to actually happen, I picked that number as the total number of passengers carried by DB per day), the size of the file would only be 1.2MB.

In other words smaller then just one digital photograph or MP3 song. So ridiculously small. And the actual size would probably be much smaller as I'd expect the number of top-ups per day would be far less then a tenth of this.

If the DB ticket machines really have so little memory, it is truly shocking.

I wonder if they didn't bother adding this feature, less because of the abilities of the ticket machine and more because it wasn't added in London and they thought that if London Bus didn't need it, Dublin Bus didn't either.

In other words, ignoring the differences between London Bus and DB. In London, must people take the bus as only part of their journey, usually having also used the underground as part of the journey and therefore on bus topups aren't very important as you can topup on the underground part of the journey.

In Dublin on bus topups are much more important, as DB is the number one carrier of passengers in Dublin and most of them only use the Bus.

Thus I say it was vital to the Leap project to have on bus online topups and automated topups working from day one.

bk wrote: »

I have don't the maths and the file with all available topups wouldn't be large. I've calculated that even if 400,000 topups were to be made in one day (very unlikely to actually happen, I picked that number as the total number of passengers carried by DB per day), the size of the file would only be 1.2MB.

Without knowing the structure or size of the data that is sent from the host to the card to update the balance, how can you make those calculations?

Another thing mentioned above is the early introduction of per operator daily capping, but only multi-operator capping much later.

This may actually take away from the goal of increasing integrated multi-modal transport.

Take myself as an example, normally I take a bus, followed by the DART to get to my girlfriends place, as it is the quickest option.

However with per operator capping, it would end up being significantly cheaper for me to take two buses, even though it would be longer.

Finally I'm convinced that DB and LEap must introduce either flat fares or tag-on and tag-off.

I use to be totally against tag-off on the bus, but now having seen how slow the driver interaction is with Leap *, I'm convinced tag-off will actually be significantly faster.

Specially if they set the maximum fare at the cost of a travel 90 or better yet, the 1.90 fare. This way making tag-off optional and probably necessary for only half of passengers.

* One day I watched as one poor driver had to put his reading glasses on to check the screen and issue a Leap fare :eek: I'm sure the poor guy can issue cash fares totally blind, but is struggling with the LEAP screen.

markpb wrote: »

Without knowing the structure or size of the data that is sent from the host to the card to update the balance, how can you make those calculations?

What more does the file need but the card number and top up amount in a comma or space separated file?

Sure, perhaps there are more stringent requirements such as an XML formatted file, etc. In which case it is a totally brain dead design for a low memory, low processing power embedded system.

With embedded systems it is all about KISS (Keep It Simple Stupid), the vast majority of embedded systems I've ever seen just use simple comma or space separated files.

However I will admit I made a mistake in my calculations

, it would come out at 8MB for 400,000 entries, but still probably less then 1MB for a more realistic figure of topups. I know this mistake weakens my argument, but I'm convinced it could be done. Here is my maths:

- 14 digit Leap card number
- 2 digit top-up amount
- 2 separator characters.

So total of 18 characters or 18 bytes of data. Round it up to 20 bytes x 400,000 entries you get 8MB.

BTW as you are only storing digits, and one separator character, you could use your own, more efficient encoding scheme then the standard byte. A byte is 8 bits, which allows you to encode 256 characters (roman alphabet plus some other stuff), but here we only need to encode 11 or 12 characters, so you could certainly make it much more efficient, with an adapted encoding scheme. 2 to the power of 4 would give you 16 characters and a much smaller file size.

bk wrote: »

- 14 digit Leap card number
- 2 digit top-up amount
- 2 separator characters.

From experience on other similar systems, I would expect it to be something like:
- card serial number (16 digits)
- card sequence number (if it exists, it's probably 2 digits)
- topup amount in cents (5 digits)
- cryptogram (probably 8-16 digits)

Then there would be other data like the type of command you're sending to the card and maybe a sequence number for the command itself. You would also need some kind of replay protection too. You can add in some overhead for the data structure and collection structure to that but I agree that it's unlikely (and stupid) that XML would be used.

I would estimate a maximum file size of between 8 and 16Mb. Assuming the ticket machine has space for that (which I very much doubt), asking an embedded device to scan a 16 meg file everytime someone tags on (plus all the other work it has to do to make the transaction happen) in less than 350ms is unlikely.

So just checked, the wayfarer 150 ticket machines used by DB only have 1MB of storage space for transactions :eek:

So yup, that is ridiculously low and probably no technical possibility of storing the file, along with everything else.

I don't think it would have space to even carry LEAP card black lists and it would call into question the ability to handle automated topups as well (which would need to be stored) :mad:

I hope I'm wrong.

For those interested, the embedded systems market is going through a revolution at the moment with the introduction of cheap as chips powerful ARM CPU's, Memory and Android OS with it's Java like language, from the smartphone market.

It just doesn't make sense going with very constrained embedded systems anymore, when you can get very powerful ARM based systems at very reasonable prices which are much easier to program for.

Future ticket machines I imagine will use such technology, making it trivial to do online topups. This is why I assume online topups will be possible with the private bus operators, they are using newer more powerful ticket machines. Hopefully DB will upgrade their ticket machines some day too and also thus support online topups.

Interesting thought experiment anyway.

LXFlyer

Well given the Wayfarer 150 is used in London I don't see this being such an issue with regard to online auto top ups.

Wayfarer are the main industry machines - again I'd hardly call them not fit for purpose.

Victor

lxflyer wrote: »

Well given the Wayfarer 150 is used in London I don't see this being such an issue with regard to online auto top ups.

I don't know about London buses, but aren't you required to specific a single location to collect a top-up with Oyster?

Wayfarer are the main industry machines - again I'd hardly call them not fit for purpose.

Fit as a ticket machine, but fit as a Leap top-up location is another matter.

bk wrote: »

* One day I watched as one poor driver had to put his reading glasses on to check the screen and issue a Leap fare :eek: I'm sure the poor guy can issue cash fares totally blind, but is struggling with the LEAP screen.

I get the impression the screens are much the same.

In London the system is really built with the Underground railway at its heart. That means the bus top up is not such an issue.

In Dublin the bus is at the heart.

AlekSmart

bk wrote: »

So just checked, the wayfarer 150 ticket machines used by DB only have 1MB of storage space for transactions :eek:

So yup, that is ridiculously low and probably no technical possibility of storing the file, along with everything else.

I don't think it would have space to even carry LEAP card black lists and it would call into question the ability to handle automated topups as well (which would need to be stored) :mad:

I hope I'm wrong.

For those interested, the embedded systems market is going through a revolution at the moment with the introduction of cheap as chips powerful ARM CPU's, Memory and Android OS with it's Java like language, from the smartphone market.

It just doesn't make sense going with very constrained embedded systems anymore, when you can get very powerful ARM based systems at very reasonable prices which are much easier to program for.

Future ticket machines I imagine will use such technology, making it trivial to do online topups. This is why I assume online topups will be possible with the private bus operators, they are using newer more powerful ticket machines. Hopefully DB will upgrade their ticket machines some day too and also thus support online topups.

Interesting thought experiment anyway.

I'm not technically up-to-speed with the TGX system here,but it seems that our machines interact via Wireless/LAN each night in the Depot.

Am I incorrect in my opinion that far greater use of this communicability could be made to facilitate Leapcard information,thus reducing the need for Machine Stored data ?

If,for arguement,BAC were to install c.12 Hot-Spots at City Centre locations it would allow some 90% of the fleet to exchange information several times daily,or am I totally away with the fairies here ?

I'm also suggesting that current RTPI installations offer a huge opportunity to push this forward as they have all the necessary data-linkage already in place ?

The avego system used for independent operators is Android based, using a Motorola Xoom tablet and with mobile connectivity built-in. It does all the desired things.

It was the only ticketing system chosen by the ITS team. All the other systems were chosen by the various operators and the ITS team had to integrate them. This integration is part of what made the whole thing so difficult.

Alek: adding more comms opportunities will make absolutely no difference to what the wayfarer can or cannot do. There are inherent limitations to the wayfarer platform. The ITS setup seems to be stretching things as it is. Programmers to work on the wayfarers seem to have been a major constraint for the ITS program and seem to have slowed it down.

As it is, the wayfarers could be continuously linked to head office via the transceivers used for RTPI. But there is basically no point in doing so.

LXFlyer

Victor wrote: »

I don't know about London buses, but aren't you required to specific a single location to collect a top-up with Oyster?

Initially yes. You have to go to a specific station or tram stop to activate auto top up having signed up for it.

But that is it with auto top-up. After that it tops up automatically whenever the balance falls below £8, with whatever amount you specified (£20 or £40) at the time you sign up for auto top-up.

AlekSmart

antoinolachtnai wrote: »

The avego system used for independent operators is Android based, using a Motorola Xoom tablet and with mobile connectivity built-in. It does all the desired things.

It was the only ticketing system chosen by the ITS team. All the other systems were chosen by the various operators and the ITS team had to integrate them. This integration is part of what made the whole thing so difficult.

And there,in Antoin's post,is THE inherent flaw in our interpretation of what an Integrated Ticketing System actually is.

The Dept of Transport/RPA/NTA chose to interpret ITS as being about bringing together disparate fare/ticketing systems and hopefully getting them all to work as one.

Others,perhaps better motivated or interested,might have spotted the potential inherent in the ITS,and imposed a single Fare/Ticketing regime on the Greater Dublin region well in adevance of what we rolled out in 2012...they had,after all some 10 years to lay the foundations of this.

Instead,we now have the NTA almost engaging in warfare as it attempts to stamp Leapcard onto Dublin Bus-DART-Irish Rail.

I shudder to think of whats ahead when Bus Eireann is assimilated (if ever) into the stew.

Why,given the very definite powers which were allocated to the Integrated Ticketing Implementation Group,did they not start at the beginning ....

As Mrs Beeton's menu for Rabbit Stew famously began....
...."First,catch your Rabbit...."