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


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 '10 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 '10 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 '10 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 '10 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. – Michael Todd Oct 6 '10 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 '10 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. – Michael Todd Oct 6 '10 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 '10 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. – Michael Todd Oct 6 '10 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

