Geocoding Against a Parcel Map

Although I’m sure most of you are aware, last year Intergraph released a geocoding expansion pack. Last year I began playing with it against our Thomas Brothers street centerline data. I was able to create the index against the street centerlines with a little bit of effort. However, overall, it was simple…especially once I understood what the software prompts and lingo meant.

Fast forward to this past week. Since I had such good success with the street centerlines, I thought I’d look into geocoding using my parcels. Long story short – it was actually EASIER to setup. In large part this is due to the lack of off-the-shelf options. Where Intergraph provides three Geocoding Model Files for street centerlines, they only provide one for parcels. It’s named US_rooftop_gcm.xml. So, I selected this model and hit the next button.

Next it wanted me to connect to my my source for my parcels. In my case, this is in Oracle. So I made the connection and hit the next button.

In the third screen it wants you to select your address definition. This is simply how your parcel attribute data are parsed. There is only ONE that comes with the software. You can create more yourself by editing XML files.

It’s interesting to note that my original parcels did not match the default definition. As  a result, I worked with another agency to acquire updated and better-parsed parcel attributes. I joined the updated parcel attributes to my parcel geometry and used the new set of attributes as opposed to my original attributes. This is actually what spawned last weeks entry Some SQL for the Day. Anyhow, then you map the columns in your parcel attribute table to the respective text fields. In other words – City column to "City", ZIP column to "ZIP", etc.

The next screen asks you to define the rules for how to determine matches. I left the default. If so inclined, you can select create your own matching index.

Next it prompts you to identify where the index should be saved and also its name. The utility is creating an index to better optimize the geocoding engine. The biggest benefit is speed. The biggest drawback is that the index is a snapshot in time. So if you update your parcels, you’ll need to recreate your index. Now, I have read (I think), that the indexing engine can be scripted via a DOS batch script. As a result, you should be able to create a fairly simple batch script to update your index at pre-determined intervals.

Next it prompts you to locate a geocoding directory. This is simply the location where you’re going to store the index and the XML pointer file (created at this step). The XML pointer file is used in the geocoding tools inside of GeoMedia.

Finally, hit the OK button and wait.

The index creation process took less than a minute to go through 250,000 parcels. In other words, the index creation is VERY fast.

A few things to note:

1) Make sure to save your profile (on the last screen) so that you don’t need to run through the wizard when you choose to update your index.

2) In GeoMedia, locating a single address using Find Address is amazingly fast.

3) I’ve heard a few people complain about the amount of time it takes to setup the index creation. Like much of what Intergraph does, they give you a myriad of choices. This can be good when you really like tweaking. However it can be bad if you just want to get something done…fast. I recommend reviewing the documentation. It’s not hard to understand, but the options can be a little inundating the first time. Especially if trying to create a street centerline index.

4) One of the HUGELY valuable aspects about this application is its parsing ability. In the end, after it has run through your address source, it’s going to spit back all of the address in a very normalized attribute table. This is great if you’re looking for a way to normalize address data.

In the end, it does take some setup, but in my eyes the results make it well worth the time. It was a long time in the waiting, but Intergraph has really outdone themselves with this one!