c0shea / IdParser

Parses PDF417 AAMVA-compliant driver's licenses and ID cards

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is Missouri's ID any different?

malkurwi opened this issue · comments

Hello there,

When I used the test IDs, all worked.
But when I use my ID (a Missouri ID), I get all null values!
Looking closer at the scanned Text (from a 2D scanner), it looks different than all other test IDs.
I also tested a new Missouri version ID (my friend's ID), and all I got is his name!
so do you think Missouri's IDs should be handled a little different?

Thanks.

It's possible that they don't conform to the AAMVA standard the way I expected or the scanner is doing something odd to the barcode. Are you able to provide a sample of the scanned text? If so, please change your personally identifiable information (e.g. name, DOB, ID Number, etc.) to sample data.

@
ANSI 6360300102DL00390191ZM02300053DLDAQX100097001DAALastNameTest,FirstNameTest, ,DAG123 ABC TEST ADDRESS 2ND FLDAIST LOUISDAJMODAK633011      DARF   DAS          DAT     DAU508DAW155DAYBRODBA20180204DBB20170809DBCMDBD20110630
ZMZMAST LOUIS CITYZMB112001810097ZMC          ZMD

That was a Missouri ID posted by my friend Jeff.

Missouri Example:
http://dor.mo.gov/pdf/newlicense.pdf

Helpful for other states:
http://dcm.uhcl.edu/caps7g8/Drivers%20License.pdf

I scanned a few states, I am not sure if any are the same as MO:
@
AAMVA10093001DL00270194DAQ999000680DAASAMPLE,SUSAN,DAGP.O. BOX 1272 ROOM 2120DAILITTLE ROCKDAJARDAK72205 DARD DAS DAT DAU511DAW121DAYBR DAZBR DBA20031212DBB19701212DBCFDBD20010416
@
AAMVA36018001DL 28 204DLDABDAUGHTERDACOFDADTESTDAL1400 SE 5THDANDES MOINESDAOIADAP50301DAQ999999999DARCDASBVDATODAU604DAW321DAYBRODBA20030307DBB19470307DBCFDBD20010130DBGYNDBHYDBJ9990099999901ZAA33389327
@
ANSI 6360020101DL00290136DAALAST-NAME,FIRST,MIDDLEDAGPO Box 1234DAIAnytownDAJMADAK12345DAQS99988801DARDMDASBDATDBA20050122DBB19550122DBCMDBD20001020

I fixed a bug in this commit to handle licenses where M/F is used for sex instead of 0/1, which is what the standard is. I also added your Missouri example to the test project and released 3.0.2-beta, which is now available on NuGet (updated client is also available).

That said, that doesn't explain only having the name parsed and everything else null. I'm not sure if it's GitHub removing the newlines, but can you ensure that the output from your scanner includes a carriage return followed by a line feed. Each record (DCS, DAC, DAD, etc.) should be on their own line and not all mashed together. It should look like this.

I got the updated version.
I added new lines manually to the sample data that I gave you, and it worked fine.

So the problem is with my 2D barcode scanner, that is not including the NewLines.
I tried using the Scanner and PosExplorer Classes, but no luck. I don't know why I can't find any Device from the explorer.GetDevices() Method. I'm not even sure if that going to change anything!
I will probably buy a scanner that read DriverLicense properly.

Thanks a lot for the PROJECT and for the HELP!!!

If you are trying to use OPOS to communicate with your scanner, you typically need to scan a configuration barcode with the scanner, install the OPOS service objects from the vendor (e.g. Symbol), install Microsoft POS for .NET, and give the scanner a logical device name. Once you've done that, you can use my library to make working with OPOS easier, or you can test it with the IdParser.Client app.

Otherwise, there might be some other configuration barcodes for your scanner to reset it to default settings or change the options for PDF417 barcodes. There might be something in there for the newlines not coming through.