Not All Information available from NHTSA DATA

[ride4sun]

It seems like there is way more data available from the NHTSA Data. Why is that not decoded?

[pmundt]

Mostly because the NHTSA data that's pulled in is to map in to the VIN data model, which has a fairly limited number of data points compared to the NHTSA data model. I'm not sure it makes sense to try and introduce more complexity into the VIN data model given that a lot of this information is not sufficiently generalized (e.g. we don't have an equivalent for European VINs), but I wouldn't be opposed to extending the NHTSA data model and adding new APIs for this if that's something that's going to be useful.

[ride4sun]

I think you are right but why not exposing a list entries which hold the key value pairs and the consumer can figure out what to use or maybe just showing the list of information.

…

On Tue, Aug 24, 2021, 19:36 Paul Mundt ***@***.***> wrote: Mostly because the NHTSA data that's pulled in is to map in to the VIN data model, which has a fairly limited number of data points compared to the NHTSA data model. I'm not sure it makes sense to try and introduce more complexity into the VIN data model given that a lot of this information is not sufficiently generalized (e.g. we don't have an equivalent for European VINs), but I wouldn't be opposed to extending the NHTSA data model and adding new APIs for this if that's something that's going to be useful. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3BZ22JC2BJVG6OHCVTWO3T6RJKPANCNFSM5CXX2EPA> .

[pmundt]

That should be pretty straightforward, we already parse all of the results, they're just not passed through to the upper layers as we truncate explicitly with the call to toExtendedVehicleInfo(). Perhaps the easiest solution is to convert the result pairs into a Map<String, dynamic> and pass this up to the upper layer, then pull out the make/model/year from there instead, which would allow the rest of the results to be accessed by the caller.

[ride4sun]

Yes, I did see that. I think that should be the default. Then all data is available.
Basically like that in the Vin class:
Future<List<NHTSAResult>> fetchExtendedVehicleInfo() async => ExtendedVehicleInfo.getExtendedVehicleInfo(this.number);

All the other calls like Future<String> getModelAsync() async
can be deleted.

[pmundt]

Ok, thinking about it a bit more, I came up with a slightly different approach. I'd rather not expose too much knowledge of the underlying NHTSA model within the VIN class, especially as we may end up using other sources for VINs from different geographic regions. As a compromise, I split out the NHTSA API accessors into their own class and exposed a library for this such that you can query it alongside your normal VIN processing code. There are now two methods by which to query the NHTSA data:

1. Querying a specific variable name or ID, pursuant to the NHTSA data specification.
2. Obtaining a Map<String, dynamic> map of populated key-value pairs pertaining to extended VIN data points.

I've updated the example to show how to use either of these approaches.