ANPR reads plates. It does not know who booked.

Every page that ranks for ANPR car park systems is written by somebody who sells cameras, and every one of them stops at the read. The read is the easy half. The hard half is the join: turning a string of characters into the right reservation, the one a reseller sent you two days ago under a name spelled three different ways, for a car the customer swapped on the morning of departure.

This post is about the join. It sets out the four states a plate can be in when a car reaches your barrier, what an operator should do with each one, and why the same camera is worth far more on the exit lane than on the entry lane of an off airport car park.

Say this part first: we do not sell cameras

ParkAgenda has no plate reader, no camera, no barrier controller and no hardware of any kind. Not a lite version, not a roadmap item. None.

What we have is the other half. Every stay in ParkAgenda carries the vehicle plate alongside the model, the colour, the spot, the flight numbers, the source and the commission, and the plate is indexed in a normalised form so a read can be looked up against it. An ANPR installation you already own can ask ParkAgenda which stay a plate belongs to, through our REST API. Connecting it is project work, scoped per site, and our team writes the connector with your supplier. There is no certified hardware partner list to publish today, and installation is usually handled by a local integrator near you.

If that reads as less than a camera vendor promises, it is. It is also the part that decides whether the camera pays for itself.

The plate is the only field two systems will ever agree on

Names do not join. Booking references do not join. The plate joins, because it is printed on the object.

Take a customer called Jean-Pierre Van der Meer. One reseller sends you VANDERMEER JP. Another sends Van Der Meer, Jean Pierre. Your own booking form has j.vandermeer typed by the customer at 23:40 the night before. None of those three strings match each other, and no amount of fuzzy matching makes them safe enough to open a barrier on.

Booking references are worse. Each reseller mints its own format, none of them is on the windscreen, and the customer cannot recite it at the intercom.

The plate has three advantages. It is short. It is on the car. The driver can read it back to you on the phone. It still needs work before it will match anything:

• Uppercase it, strip spaces, dots and hyphens. A French SIV plate arrives as AB-123-CD from one source and AB123CD from another.
• Decide what you do with the country band. GB, F, B, NL and CH prefixes turn up in some feeds and not others.
• Decide once, in writing, whether you fold O into 0 and I into 1. Folding raises your match rate and raises your false match rate with it.
• Keep the raw read as well as the normalised one, so a dispute has something to look at.

The four states a read can be in at the barrier

There are exactly four, and a system that only handles the first one will cause a problem in its first week.

One open stay matches

The good case. Log the read against the stay with a timestamp, and let the barrier system do whatever the barrier system does. Nothing else changes: the check-in is still a person's job, because a check-in also records the keys, the condition of the car and the spot.

More than one stay matches

This happens more than people expect. The same reseller sent the booking twice. Two resellers sold the same customer the same week. A company car comes back four times a year on four different bookings. A returning customer rebooked and the old stay was never closed.

Pick nothing. Show the operator every match with the arrival date, the source and the customer name, and let them choose in two seconds. An automatic choice here is a car in the wrong bay and a stay that never closes.

Nothing matches

A walk-in with no booking. The right customer on the wrong day. A plate nobody ever captured. A hire car that got upgraded at the counter. A misread on a dirty plate in the rain.

Do nothing automatic, and above all never create a booking from a camera read. A booking invented by a camera has no price, no source, no commission and no customer email, and it will corrupt your revenue figures for the month.

A stay matches, but it is not open

Cancelled last Tuesday. Marked as a no-show. Checked out three weeks ago. Arriving next Thursday. This is the dangerous one, because a naive integration asks the booking system a question, gets a row back, and reads any row as a yes.

Treat it as no match, and raise it. A checked-out stay reappearing at the entry lane is either a returning customer with no booking or a misread of a plate that differs by one character. Both are worth a person looking. The taxonomy of near misses goes deeper than this post has room for, and it is the whole subject of LPR at the entrance, and the four ways the plate does not match.

Whatever the state, the split of responsibility is the same. Your barrier system decides what opens. The booking system answers a question and records that it was asked. ParkAgenda never opens anything, and you should be suspicious of any booking product that says it does.

Entry and exit are not the same problem

On the way in, you only know the plate if somebody gave it to you in advance. On the way out, you know it because your own operator typed it or corrected it at intake. The join is weak at the entry and close to perfect at the exit, and almost nobody prices their ANPR project that way round.

A worked example

Take a 400 space off airport car park selling 60 per cent of its nights through resellers, with an average stay of about eight nights. These are example figures, constructed to show the shape of the problem. They are not measured from a customer.

On a busy Friday in July that car park handles around 90 arrivals and 85 departures, with roughly 320 cars on site.

• 54 of the 90 arrivals came through resellers, 36 through the parking's own site and the counter.
• Say the plate is present on 7 in 10 reseller bookings by the time the car turns up. That is 38.
• Own channel bookings ask for the plate on the form, so say 9 in 10. That is 32.
• Roughly 70 plates known in advance, 20 not known at all.
• Of the 70, a few are wrong. The customer took the other family car, the hire company upgraded them. Call it 5 per cent, so three or four cars.

So on the entry lane the camera identifies about three quarters of arrivals and needs a human for the rest. That is useful. It is not the automatic entry the brochure showed you.

Now look at the exit. Every one of those 90 cars was checked in by a person who typed or corrected the plate against the physical car. On the way out the plate on file is right for effectively all of them, and the read gives you something you otherwise have to remember to do by hand: a departure timestamp.

That timestamp is what an overstay charge is calculated from and what a departure board is honest about. If you are only funding one lane of ANPR this year, fund the exit lane.

The rule to put in the specification

Write it as four lines, and make the integrator quote against them.

1. One open stay: record the read against the stay, then hand the decision back to the barrier system.
2. Several stays: return all of them, decide nothing, surface them to an operator.
3. No stay: return nothing and never create a record.
4. A stay that is not open: return it flagged as not open, and treat it as a refusal that needs a person.

Five questions to ask a camera vendor before you sign

• What does your system do when two reservations share a plate? If the answer is a shrug, the integration is your problem, not theirs.
• Can it call another system and wait for an answer? How long does it wait, and does it fail open or fail closed when the answer does not come?
• What read rate do you quote, and is that per frame or per vehicle pass? The two numbers are not close to each other.
• What happens to a foreign plate with a country band, and to a plate hidden behind a bike rack or a tow bar?
• Who owns the images, how long are they kept, and where. That is your question to answer to your customers, not theirs.

The wider version of this conversation, including who does the wiring and who carries the risk when it slips, is in what integrating with a car park actually means.

How the join works on our side

Bookings arrive in ParkAgenda from four directions: a reseller's own email format through a per vendor adapter, an API pull, a CSV import, and an operator typing at the counter. They all produce the same stay record, attributed to its source. Anything that cannot be applied safely is quarantined with the raw email and the reason, and a person promotes it, reprocesses it, whitelists the sender or dismisses it.

That matters here because the quality of your ANPR join is decided upstream, in the ingest. A plate that never made it into the stay cannot be matched by any camera at any price.

Duplicate stays from two resellers can be merged, which shrinks the several matches case over time. Plates are searchable in normalised form. And a read that arrives through the API resolves to zero, one or several stays, with the answer returned as it is rather than guessed at.

FAQ

Does ParkAgenda include ANPR?

No. There is no plate recognition, no camera and no barrier control in the product. ParkAgenda connects to the ANPR and barrier systems you already run, through our API and a connector our team builds with your supplier.

Can a camera read check a customer in automatically?

A read can tell you a car is at the entry, and it can be recorded against the stay. It cannot be the check-in. A check-in also records the keys, the condition of the car, the spot and, for a valet stay, a signature. Those need a person standing next to the car.

What if the customer arrives in a different car?

Change the plate on the stay. It takes ten seconds at intake and it is the highest value keystroke of the day, because it is what makes the exit read work three weeks later.

Where to start

If you already run cameras and want to know whether a read can be joined to your bookings, the useful first step is small: send us one day of your reseller feed and a sample of reads, and we will tell you what proportion actually match before anybody signs anything.

You can see how bookings and plates are held on the features page, and the integration work is described on the integrations page. If you want the match rate test, get in touch.