Plates not being recognized by CloudAPI

At a single location (in Illinois) we are having significantly less success with LPR. See images attached. IL (3.0 MB)

Matt, it does not appear that anyone from support has looked at this.

I apologize for the delay.

It looks like the plate numbers are being recognized correctly. However, the Illinois regex pattern does not have this plate format (2 letters and 5 numbers) in the current version. So it is choosing the second entry on the list that matches the pattern, even though the confidence is much lower. In this example, AY63465 was read as the correct plate number, but the best plate was likely AY6465 because it matched the current Illinois regex patterns

The next release is coming out soon (within a few weeks). However, you may be able to workaround this by adding some logic to use the first match if the confidence is a certain percent greater. For example, here the first match is around 95% but the second best estimate (that matches the pattern) is around 82%. That kind of logic would also help in the cases where we misclassify the state.

Thanks for the response Matt.

One thing I can say, as a former resident of Illinois, is that standard passenger vehicle plates can start with 0 - 7 letters, followed by 0 -7 digits, for a total of 7 alphanumeric characters.

For vanity and personalized plates, there can be 7 or fewer total characters. But numbers never come before digits.

I hope this helps.

New issue, on the same topic, in the attached image, the text on the lift was read, but the plate was not in the dataset returned (See attached JSON) (2.0 KB)