GeocodeServer behaves differently than it's parent locator with StreetAddress role

09-23-2022 01:02 PM
New Contributor III

Two questions, Is it normal behavior for a GeocodeServer (Enterprise Version 10.8.1) published from an ArcGIS Pro Locator (Version 2.9.2) built using Create Locator to:

  1. Not honor the designated Output Fields set in the parent locator's properties?
  2. Provide different XY values and location than that provided by the parent locator in Pro for StreetAddress roles?

The top photo below is from Pro honoring the Output Fields designated in the Locator properties, and accurate XY values based on any offset criteria. The second photo is from the Geocoding Service built from the same locator with the unselected output fields showing and differing XY values.

I believe the Output Fields functionality isn't currently supported when publishing geocoding services or may only be supported for batch operations, and it's something I can live with. However, the XY discrepancy is geocoding to locations 20+ feet from the interpolated position along the centerline. The same behavior was observed even if the Offset parameters in the locator properties were set to 0 or 0.0. This XY discrepancy was only observed for data provided by the StreetAddress role and was tested with data in two spatial references, one being WKID 4326 (WGS 84).

I can't think of anything other then the Offset parameters that would be leading to this behavior, and I'm wondering if it is some sort of version conflict as I didn't observe it in some older locators.





0 Kudos
1 Reply
Esri Regular Contributor

@ScottFedak2085 Enterprise 10.9 and later supports offset settings for StreetAddress role locators. You may want to consider creating the locator with either Global Extra High or Local Extra High as the Precision Type, which is an optional parameter in the Create Locator tool. The Precision Type parameter is supported in Enterprise 10.8.1 or later.

I did not see a screenshot of the locator properties showing the output fields, but I suspect you may be running into ENH-000141201, which is resolved in ArcGIS Pro 3.0 and Enterprise 11.0.

0 Kudos