LocateXT Needs Gazetteer Support To Be Useful

[EricEagle]

The LocateXT documentation says this:

When custom locations are turned on, content in the documents that are being scanned is compared against the place names specified in the custom locations file. By default, the content has to exactly match one of the specified place names to create a location in the output feature class.

This approach is deeply, deeply flawed.  The entire point of using something like LocateXT is to crawl information for explicit and implicit locations so that a human doesn't have to read them in the first place.  Under this, a person would have to read all the content, and enter a place name-coordinate pair for each non-coordinate location in a "custom locations file."  This is insane!

This is exactly what gazetteers exist for.  This is precisely what Geonames and OSM Nominatim exist for.  So this idea is for LocateXT to support gazetteer sources out of the box, including an OSM Nominatim service so that plain text names can be checked (completely or fuzzily) against Nominatim or other custom gazetteer sources.

I just bought 12 of these things so I'll have more ideas as we go along but for now, this is baseline type stuff that is required for the extension to be useful.

[EricEagle]

Update: In an attempt to build a file-based gazetteer for LocateXT, I imported Geonames populated places layer, which created over 7 million entries in the list.  When I went to run it, the utility then wanted me to check a box for "exact match" or "fuzzy match" for EVERY SINGLE LOCATION.  There was no bulk action option presented.  Again, this is insane.  Please, please fix this.

[AlfredoConetta2]

I agree with this.  Why have the ability to create a custom location with the use of a Gazetteer in Desktop and then not have the same basic functionality in LocateXT in Pro?  

The same could also be said for the creation of hyperlinks automatically in Desktop, but not in Pro?

Two of the key feature that attract users in Desktop removed (or just not created in Pro?)

[RonnieRichards]

Agreed. Feature extraction should also be configured and able to be performed at the class level. So if we want zip codes features to be extracted ideally we could specify a regex expression , arcade expression or python and have those feature types be associated to a locator service. 

For the same document we might want to map any addresses mention so it would be defined we a regex which identifies address strings and want to geocode these against World Locator service?

Defining 1 feature at a time as the author is running into is not sustainable and defeats the purpose of the product. 

It does not appear to support regex for locations or custom attributes so will likely be creating an idea for this type of support. 

[AlfredoConetta2]

Does anyone in esri actually read these?  I have commented on the above an was hoping that someone would let me know what they are doing about our recommendations.