In the following tutorial link, the code geocodes a structured address. In the example address fields are coded so that the program knows in advance 1) state = "CA" 2) city = "Redfield"... http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/How_to_geocode_a_single_address/00010000038r000000/

Is there a way to resolve unstructured address data in ArcEngine?

An example of unstructured address data would be a single string like this: "222 Ashland St N Cambridge MN 55008"

Where the user has not parsed the string down into its elements of street, city, state, zip

3 Answers 3


It's a simple matter to extract the zip and the state abbreviation from this format. The challenge is to identify town names that include whitespace, such as "Sioux Falls". This requires some actual information, not just syntactic parsing. But that information is easy to come by with a table of city name-zip code pairs: just look up the zip code and attempt to match the suffix of the remaining address (e.g., "222 Ashland St N Cambridge") to all the town names associated with the zip.

Naturally this procedure will choke on typographical errors. But so, likely, would the geocoding engine.

  • I know what you are saying, but if it's so simple why can't ESRI just do it for me, I don't think I should have to write my own address parser.
    – patrick
    Oct 11, 2010 at 20:09
  • @iterationx: ESRI cannot anticipate all possible formats in which addresses will be stored. A familiarity with the simple and powerful text processing tools (practically any that supports regular expression matching) is empowering: it gives you far more control over your data than you could expect to get within any GIS.
    – whuber
    Oct 11, 2010 at 22:23
  • When I use google maps api, I don't have to comma delimit my data, therefore your point that ESRI cannot anticipate possible data formats is demonstrably false, since a product exists already which does exactly that.
    – patrick
    Oct 12, 2010 at 15:22
  • 1
    @iterationx: You're being way too hard on ESRI. There has to be a lag between the introduction of a format and its incorporation into software. You could perhaps fault ESRI for having a long lag in reacting to what Google is doing. But the chief point is that before Google maps introduced this format, or before anybody introduces a format, the poor GIS vendor is faced with the impossible task of pre-inventing every format that might ever be devised! There are clever ways to cope with this (building some extensibility into a system), of course, but there are always limits.
    – whuber
    Oct 12, 2010 at 16:04

How about this: single line address geocoding with ArcObjects sample.

  • That looks good. It throws each element (e.g. 222, Ashland, etc.) into an array, then shoves those properties into the locator. Certainly better than trying to parse it yourself. Oct 6, 2010 at 18:28
  • @Michael Todd That doesn't actually work, in that example the user is expected to input address data with comma delimiters which are they loaded up in a sequentially structured way into an object called IPropertySet. I'm looking for an example that doesn't require the user to comma delimit their data.
    – patrick
    Oct 6, 2010 at 19:10
  • @iterationx Then you're probably back to having to parse it yourself. Good luck; it's not a lot of fun, especially dealing with raw data-entry. Perhaps you could "steer" users into entering the data as expected via your interface. Oct 6, 2010 at 19:22
  • @Michael Todd I found this which I am considering using, because it works right out of the box, but I need to navigate the google maps license, code.google.com/p/gmaps-api-net
    – patrick
    Oct 6, 2010 at 21:49
  • Google maps is easy to use and updated pretty regularly. I don't remember the details about licensing exactly, but, per this document, as long as you're not charging a fee (and have an iGoogle account, and get a code from them permitting access to the API, and agree to the privacy stipulations), you can use the API free of charge. Oct 6, 2010 at 21:55

I talked to esri developer support and the answer is no, but its not that bad since Housenumber and Street are the same field.

addressProperties.SetProperty("Street", Street); //can put both hn & str in here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.