Failed attempt at Creating an Address Locator from StreetMap Data

[GeorgeHaskett]

I am using ArcGIS 10.1 software.

Recently I tried to make my own Address Locator for the state of Idaho using the esri Streetmap data.
Unfortunately something did not work right, however I received no errors in the process.

When I open my results, they all look good attribute wise, however geospatially they all fall into the same location, which appears to be 0,0 for my Lat and Long.

Any guesses on where I went wrong?  The results window stated everything ran smoothly....

Thanks

[BradNiemand]

I think your best bet is to contact support.

Brad

[BruceHarold]

Hi

Also please check your source data and output locator have a spatial reference defined.

Regards

[BruceHarold]

...One more thing.  If your StreetMap data is not properly licensed then the geometry within it will appear null if exported (or used in locator creation) which will cause what you are seeing.

Regards

[GeorgeHaskett]

Thanks Bruce, I'll need to follow up with our IT guys on this one.

At this point the spatial reference is WGS1984 and pulls into a map without any issues.

The geoprocessing results state that it succeeded after 1min 15 seconds for the state of Idaho, which sounds a bit too quick when I think about it.

How do I tell if its properly registered, etc.

Thanks

[GeorgeHaskett]

(UPDATE)

Okay, it looks like the individual that set things up on our end only transferred the first disk and non of the locator data.

So my next question, if we have the Premium Streetmap data, what, if any, advantage does the new World Geocode Service have?

We currently use the data to create our own statewide network service and to geocode against.

If we can use the address locator that comes with the Premium streetmap data, why would we want to continue to use the World Geocode Service?

Won't the results from both address locators be the same?

Thanks,

[paultsushima · Accepted solution]

For the US, the same locators that feed StreetMap Premium Navteq also feed the WGS.  The only difference might be the data vintage, depending on which version of SMP you are using and when we last updated the WGS locators.  If you have SMP TomTom, then that would be a bigger difference.  In terms of functionality, you can do a lot of things with the SMP locators since you have them in-house and can change things about the locators and how you use them.  For instance, you can do things like use the individual locators by themselves (i.e. just the StreetAddress locator), change the properties of the locators (i.e. minimum match score), change the composite locator (i.e. remove ones you don't want to include), etc.  In the WGS, you basically have to just use the US composite locator as is.

To explain what you were trying to do when creating your own locator for Idaho, I'm guessing that you were trying to create a StreetAddress locator from the detailed streets layer (streets.sdc or Streets feature class in the FGDB)?  If yes, we specifically apply a special data protection to this layer because of our agreement with the data vendors (Navteq and TomTom).  This protection restricts any ArcGIS function from properly accessing the Shape field, such as exporting the data to another feature class, Buffer, Dissolve, any overlays, etc.  Since building a locator writes geometry to the locator files, this also will not work.  But what you experienced is the expected behavior.  The processes finish, but there is just no geometry in the output.

Hope this all helps.

Paul Tsushima

[GeorgeHaskett]

Thanks Paul.

So if I understand correctly, as long as we maintain our annual license for the StreetMap Premium package, then we should stay in line with the WGS in regards to the address locators.

Thanks again for the extra clarification.

Haskett