Parking stories in the News/media

Coupon-mad

I didn't get a chance. I drown in pm's and tend to forget about them because they are impossible to manage.

If people want me to see stuff you're best posting openly; I'll always read threads.

Fruitcake

With regards to random characters appearing when using a touch screen, and going straight to the payment page, it should be noted that most touch screens are not touch screens, they are proximity screens.

If you hover a finger over a digital button without actually touching the screen, it will often register that character.

I discovered this at Southmead Hospital when I noticed the cuff of my jacket was causing the machine to register random characters, even if my jacket was not actually touching the screen.

This means that the screens being used are too sensitive. This could be a deliberate programming feature, or simply an error. It should be possible for the operator to adjust the sensitivity (which they won't) in the same way that PDT machines should be typo-proof.

BikingBud

Fruitcake said:

With regards to random characters appearing when using a touch screen, and going straight to the payment page, it should be noted that most touch screens are not touch screens, they are proximity screens.

If you hover a finger over a digital button without actually touching the screen, it will often register that character.

I discovered this at Southmead Hospital when I noticed the cuff of my jacket was causing the machine to register random characters, even if my jacket was not actually touching the screen.

This means that the screens being used are too sensitive. This could be a deliberate programming feature, or simply an error. It should be possible for the operator to adjust the sensitivity (which they won't) in the same way that PDT machines should be typo-proof.

But there should be an obligation on the system designer to make the equipment fit for purpose and error tolerant.

Even if pauses and ask is this VRN correct and then requires positive action before printing the ticket.

We know that ANPS works, they get the correct number otherwise they would not be able to send out the invoices, it just need to have a look up function on the table, that any o'level computer studies student would be able to do.

If it's not in the table do not print ticket.

Car parks such as Gun Wharf Quays have it set up correctly.

You go in it captures your VRN. No ticket required really but it gives you one anyway. You go do your shopping or socialising and pay when you come back by putting your VRN into the machine it does the maths and tells you how much.

You drive out it recognises your VRN and opens the barrier - Simple

Le_Kirk

BikingBud said:

But there should be an obligation on the system designer to make the equipment fit for purpose and error tolerant.

Absolutely, I have been posting about this "error" for what seems like years.  As an ex-programmer (retired) there are all sorts of error checking routines available; if any of my programming errors were left unchecked, it wouldn't just issue an invoice to the wrong person but would be a disastrous calamity of machine breakdown, loss of production time, product and money.  Why aren't PDT/ANPR programmers held to some high authority/standard - oh, to answer my question, loss of opportunity to make a profit!

kryten3000

BikingBud said:

Absolutely, I have been posting about this "error" for what seems like years.  As an ex-programmer (retired) there are all sorts of error checking routines available; if any of my programming errors were left unchecked, it wouldn't just issue an invoice to the wrong person but would be a disastrous calamity of machine breakdown, loss of production time, product and money.  Why aren't PDT/ANPR programmers held to some high authority/standard - oh, to answer my question, loss of opportunity to make a profit!

Absolutely.  It annoys me a lot that the trivial software pattern matching to allow 0/O I/1 Z/2 and so on is not implemented.  It does not matter in the slightest if I enter AA03ABC  or AAO3ABC, they both uniquely identify the vehicle.  These minor keying errors should not be allowed to result in a PCN being issued.

Umkomaas

VRM plates show the digital '0' whether it represents an 'O' or a 'Zero'.

Nellymoser

Named and shamed, UK's biggest parking firm 'cowboys': Drivers are getting record 40,000 tickets a day despite Government promises to tackle 'bandit' operators

https://www.dailymail.co.uk/news/article-14444053/amp/Named-shamed-UKs-biggest-parking-firm-cowboys.html

Haven't summarise anything here it's long article covering many points.

Thorndorise

kryten3000 said:

BikingBud said:

Absolutely, I have been posting about this "error" for what seems like years.  As an ex-programmer (retired) there are all sorts of error checking routines available; if any of my programming errors were left unchecked, it wouldn't just issue an invoice to the wrong person but would be a disastrous calamity of machine breakdown, loss of production time, product and money.  Why aren't PDT/ANPR programmers held to some high authority/standard - oh, to answer my question, loss of opportunity to make a profit!

Absolutely.  It annoys me a lot that the trivial software pattern matching to allow 0/O I/1 Z/2 and so on is not implemented.  It does not matter in the slightest if I enter AA03ABC  or AAO3ABC, they both uniquely identify the vehicle.  These minor keying errors should not be allowed to result in a PCN being issued.

This and what @Umkomaas has said, the DVLA do NOT differentiate between the two whenm it comes to plates, therefore there is no onus on the provider of the details at the 'keyboard' interface to get this 100% correct too, as actually they equally correct in terms of what is written on the plate.

Half_way

Thorndorise said:

kryten3000 said:

BikingBud said:

Absolutely, I have been posting about this "error" for what seems like years.  As an ex-programmer (retired) there are all sorts of error checking routines available; if any of my programming errors were left unchecked, it wouldn't just issue an invoice to the wrong person but would be a disastrous calamity of machine breakdown, loss of production time, product and money.  Why aren't PDT/ANPR programmers held to some high authority/standard - oh, to answer my question, loss of opportunity to make a profit!

Absolutely.  It annoys me a lot that the trivial software pattern matching to allow 0/O I/1 Z/2 and so on is not implemented.  It does not matter in the slightest if I enter AA03ABC  or AAO3ABC, they both uniquely identify the vehicle.  These minor keying errors should not be allowed to result in a PCN being issued.

This and what @Umkomaas has said, the DVLA do NOT differentiate between the two whenm it comes to plates, therefore there is no onus on the provider of the details at the 'keyboard' interface to get this 100% correct too, as actually they equally correct in terms of what is written on the plate.

No one should  receive a parking charge notice as a result of typing the letter O instead of the number 0, the number 1 instead of the letter I as there is no distinction between these letters/numbers in the UK number plate font

 and other terms that may generate a parking charge notice, such as asking for a licence number -as not everyone may carry their driving licence with them and asking for a licence number is asking for data that they have no need to process.

Coupon-mad

Agreed.

And nobody should see their credit rating affected by a normal day out shopping:

https://www.nwemail.co.uk/news/24795001.windermere-booths-store-faces-protest-parking-fines/

"Wealthy supermarkets should not have the power to stop ordinary working people from getting a mortgage".

A compelling message.

And I'm GLAD he is peeing off Booths because that's what will work best to make retailers think twice about using ANPR firms.