Option to collect/decode VIN data into token fields

darkbrewery,

That is something I looked into, but there are some fun issues with trying to develop a "catch-all" solution:

1. Most of the VIN decoding databases are proprietary beyond the WMI (first 3 digits, which is not exactly public domain, but can be compiled fairly easily).

2. Depending on the production volume of the manufacturer, the model, engine family, and factory of origin are encoded differently. If you don't know which WMI's these rules apply to, and which to apply, it can be hard to decode a VIN cleanly. Hence the hurdle in #1.

3. Some WMI's are shared by several brands - for instance, most Taiwanese/Chinese/Korean WMI's are going to map to the factory, not the brand (e.g. "Guangzhou Panyu Huanan Motor Co. Ltd." with a WMI of "LE8" will map to the brands Sachs, Peirspeed, Schwinn, Xtreme ATV, etc and their respective unique model names). How do you represent this in a make/model entry from an automagic decode?

4. Many of the commercial VIN decoding services out there will properly decode VINs using the logic referred to in #2, but the record format is not standardized across vendors.

I'd most likely have to implement some kind of hook system for subscription data retrieval and mapping columns. This might actually wind up being the safest way to do it so that people can roll their own VIN decoding (and maybe even content types) into a generic retrieval/mapping system that could accommodate the range of data returned from each vendor. For instance, Polk Data Systems returns a monstrous XML document for a given VIN right down to a list of factory-installed options, whereas other VIN decoding vendors will simply return make + model + year.

I'll dig into those other projects you referenced this week and see if anyone has attacked those issues and possibly see if their work can be leveraged to provide a nice decoding solution.

OK, I know this issue has been latent for a while as I was slammed changing jobs this summer. I'm actually implementing a provider-consumer interface for the VIN Field module that will allow the following:

1. Maintain default check-digit and character checking - but make it optional as older vehicles might not conform
2. Add the ability to hook in VIN lookup providers like VINQuery.com and Polk VINtelligence without much hassle, and allow users to select which providers to use and what order to progress through them looking for a successful VIN decode. The rationale behind this is that a site could try a free lookup first, and if that doesn't succeed the module could "work its way" up the search order from cheapest to most expensive (ranked by the admin, not by the module) service to find a match and not break the bank.
3. Force each provider to return at a minimum year, make, and model with extended information available in arrays or as tokens
4. Cache the data so that multiple queries don't need to be executed on the same VIN in the future. Also covers a VIN decode service being dropped or changed

I've got the basic provider hooks set up, and am actually testing against VINQuery.com and Polk VINtelligence right now. When version 2.x of the module is released, I will also be releasing the providers for both those services as separate modules to ease maintenance and updates. I'm also looking into writing flat-file, DB table, and XML file-based provider modules as well for those who don't want to subscribe to a service or have some internal VIN list they'd like to validate against.

Looking forward to this, subscribing

Just wanted to drop in an update... Unfortunately, bills have to be paid (I keep telling the landlord that it's all for a good cause - he's not amused) so I've had a couple small sites I've been hammering out the past week or two... Hopefully I'll have them wrapped up this week and can finish this thing up and launch it.

The only things left are the cache, finishing the VINquery.com and Polk VINtelligence modules, and testing. All the other admin and CCK logic appears to be working as hoped - er, um - designed.

One thing I have been kicking around is what to expose via Views integration. The only common fields I'm requiring are VIN (on input) and year, make and model (from the lookup provider module). Everything else will be jammed in a variable field for template processing. I figure year + make + model will give enough extra data for reporting and grouping purposes - am I incorrect in this assumption?

The extra fields (check out http://vinquery.com/samples/xmlSample.xml for a sample VINquery.com 'lite' report) could be grouped under a "catchall" internal node field picked up by templates and themes as needed (or desired) via the exposed template variables.

Am I missing anything? If so - speak up!

I just wanted to post an update. I have the VINquery provider working, and the caching logic in the core module is also working (to prevent redundant lookups, which many services will charge you for). Now I'm working through the tokens and Views integration.

Due to the fact I have freed up some time from other obligations, I should be able to focus on getting those final bits in and get the core module released, and the VINquery module at the same time. I've still got to hammer out some details on the Polk VINtelligence module, but it shouldn't be too far behind.

I am very excited about this module, as I am in discussion with a car dealership about making a website. It seems like you are very close to making a release of your module. Any word when you'll be ready? I will definitely test the new modules and let you know how it goes.

@arosboro, thanks for the interest! I'm finishing up the following tasks right now before releasing the first beta:

1. Complete Polk VINtelligence lookup module. This might honestly get put on hold as there appears to be a compatibility issue between their J2EE-based Oracle SOAP server and the PHP 5.x SOAP layer. They are working with me to figure it out, but I don't want to hold up a beta release based on what will wind up being an independently-published module anyway.
2. Complete themed field output. Right now I have a couple basic field display formatters (plain text VIN, year + make + model) and a "default" format that at present is generating DIV tags for each value. Ideally I'm trying to get a field-specific template hooked up so that you can override the output using TPL file(s), but it's fighting back a bit (the first time I've attempted a module-based template override).
3. Implement Views 2 support. I realize that generating Views-based queries on year, make and model are probably going to be important for users of this module, so I'm working on getting this completed before going beta.
4. Code cleanup. I've got some cleanup to the lookup provider hook system left to finish up, but that is actually not a huge issue.

If you've got expertise in any of these areas, I'm open to suggestions/pointers/help to get it out the door quicker. Otherwise I've only got about 10-15 hrs/week to dedicate to this project right now, and with some features involving a learning curve, probably realistically 2-3 weeks out from beta.

BTW, the VINquery.com module appears to be working as designed, so at least it will roll out with one lookup service available. If you have any others you'd like me to look into building plugins for, please let me know who they are - or if you're up for a coding challenge, I can provide a sample plugin you can use as a skeleton to build a new provider module with!

Latest updates:

• Added support for DataOne's web service tonight
• Polk claims that in the 5-7 years they've had the VINtelligence service running, I'm the first developer to try to access it with a non-Java SOAP client. They've also tested with soapUI and are receiving the same server responses I am, so they are digging into it with vigor to figure out what's up. Lookup provider module is still in a holding pattern for them.
• Snapped off some screenshots of the settings screens for the field. These are system-level settings right now as many of these services are pay-as-you-go, and I wanted admins to be able to restrict the order and service availability in one place instead of on the individual field settings pages. If this was a no-no, let me know how you'd rather like to see it and I'll make it work as needed, not as perceived!

  http://screencast.com/t/qg4FDa5bINa
  http://screencast.com/t/ppJTFhADGp
  http://screencast.com/t/tiNP2CWcCo4e
  http://screencast.com/t/czf0g1vcLmt

• Still wrestling with the Views 2 integration - AFAIK I have the hook_field_settings('views data') return array set up properly - but apparently I don't. Anyone wanting to chime in is more than welcome to!
• Still playing with field formatters and leveraging CCK's inherited field-level templates.
• Field-level tokens for year, make, model, and trim level are in now and working

As far as I'm concerned, Views integration is the only critical feature left that needs to be implemented before going into a dev release, and I can polish the rest of it up for beta... Almost there!

Sorry arpieb,

Unfortunately I have very little experience writing modules for Drupal. I have a copy of Pro Drupal Development 2nd edition, and I'm trying to write my first module for another project right now. It's going kind of slow, because I'm finding the form arrays and hooks to be kind of confusing.

I'm really glad that you've decided to implement support for views 2 though. I hope you get some help or eventually figure out what's wrong with your implementation. Maybe someone in #drupal on irc.freenode.com could help.

@arosboro - Kudos to you for taking on a module project! Once it clicks and starts to make sense, you'll have one of those headslap-to-the-forehead moments and it will all come together. I cut my teeth way too many years ago (and I'm about to date myself) writing Windows 3.1 resource files and event handlers from scratch (Stroustrup was still working on developing the C++ language, so there were no nice frameworks), and the Drupal FAPI is not far from what those dialog definition were like, as well as the hook architecture. Drop me a PM if you need some help sorting something out - I'd be glad to help if I can!

I think with the way a decoded VIN field would be used, Views support is pretty much mandatory. I know when I was in the powersports biz, I was constantly asked to run reports for model years, VIN ranges, makes, models and trim levels. I really wish I'd had the opportunity to implement Drupal and this module back then...

If I don't get the Views integration sorted out by this evening, I'll most likely hit the IRC. There's just so much traffic on there, I kind of use it as a last resort... ;)

Opened against the D6 version, closing as the D7 module is only in bugfix status and no new features are being added.

@arpie - Thanks for all the work you've already put in to this module. I've installed and enabled both VIN Field (vinfield) and VIN Field Check Digit Validator (vf_checkdigit). The field I added to my content type shows up fine. Not sure where to add the vinquery.com provider information.The module does not have a help file and I'm having trouble understanding how to get it to work. The links to the slides are now dead as well. This may not be the right place to as this question but can you please point me in the right direction.

Moving the above to a new support issue #2779021: D7 VIN lookup provider setup for housekeeping.