ESRI Rooftop Geocoding Service?

[GeoffreyWest]

I have an application where I need to use a rooftop geocoding service.   The use case is a user geocodes an address and a spatial intersection is executed which returns the values of a parcel, since the geocoding service that I am using now is sidewalk or street level, the attributes are not returned.  Is there a rooftop geocoding service available by Esri to execute this process?

[MichaelVolz]

Robert:

In Pro when using the World Geocoding Service to geocode a table of addresses which of the two options (Address Location, Routing Location) would have the potential to provide a rooftop location?

Is BuildingFootprintUSA gathering the rooftop locations themselves or are they using ESRI's collaboration with enduser organizations of rooftop address points as the point source for the World Geocoding Service?

[RobertJensen]

Hi Michael,

BF-USA is collecting rooftop locations themselves in order to feed into the World Geocoding service. Currently the default location used by the World Geocoding service is "street" because of requirements for directions and navigation. This necessitates a geocoding user to specify "locationType=rooftop" in their requests today. The Geocoding recognizes that users have an expectation of getting the rooftop location by default, so in the near future, the Online system will make the switch, but this will require additional changes that permits users with directions and navigation needs to continue to be successful.

[Anonymous User]

Shana Britt‌ Robert Jensen

There appears to be a bug introduced in the Oct AGOL update. The parameters such as min character and rooftop do not work. (when you click on a result from the Suggestion list ie without magickey) I tested with TS and they have it already as a known bug.  Also I do not like how this magickey vs no magickey can result in a different location for the address point result.  Whether you click a Suggestion or hit enter, the top result should be in the exact same spot. Similar to how fake results that do not exist should never be populated in Suggestions, this conceptually should be an absolute. The x,y should be the same, no exception.

This parameter bug is relevant because of the general dysfunctional state of locators:  No units / suggestions in locators, Fake address suggestions, And no ability to create a Hosted Locator. geocoder Suggestions list in Search should not contain addresses that don't exist  And so in my app often the world locator service therefore is the only result providing suggestions.  And I wire it to click the result, to click the parcel, in www.sagis.org/map (if you click the result it fires an onclick of the of the map to show the parcel popup. Thus the address needs to be in the parcel! Usually it is close enough but sometimes, since 'rooftop' parameter is now broken, it will be in the street or even the wrong parcel)

While we are discussing parameters; I would like a way to disable world Locator service Suggestions via a URL parameter. disable Suggestions from Esri locator in Search widget Locators: add URL parameters. For example, extent, Suggest, others 

I wanted to use the world locator service with the 'rooftop' parameter for WebApp Builder. I put the parameter in to the Config:   but neither of these parameters worked. (I also tried minCharacters to 20 to confirm that parameters are now broken and do not work with the World Locator Service)

{
"url": "https://utility.arcgis.com/usrsvcs/servers/eb4e3b1d1996465e9d9e8f6d56f1d94f/rest/services/World/GeocodeServer",
"name": "Find a Business or Point of Interest         (Address is approximate)",
"singleLineFieldName": "SingleLine",
"placeholder": "Find Business - Point of Interest",
"countryCode": "",
"panToScale": false,
"locationType": "rooftop",
"minCharacters": 8,
"zoomScale": 3600,
"maxSuggestions": 6,
"maxResults": 6,
"searchInCurrentMapExtent": false,
"enableLocalSearch": true,
"localSearchMinScale": 300000,
"localSearchDistance": 50000,
"type": "locator"
}

[BradNiemand]

Kevin,

Can you please help clarify the following statement?

"There appears to be a bug introduced in the Oct AGOL update. The parameters such as min character and rooftop do not work. (when you click on a result from the Suggestion list ie without magickey) I tested with TS and they have it already as a known bug."

Can you please provide an example address please?  The locationType parameter is working for the REST API and we have many tests that verify this at every release which are still passing right now.  Did you add the parameter to the WebAppViewer properties JSON manually?  I see it in the the JSON snippet above but I am unsure how it got there because I don't believe the WebAppViewer currently supports this parameter.  What you can do is create a Locator View, configure the preferred location type to be rooftop for that view, and then use that URL for the Locator View for your app instead.

More information about Locator Views can be found here:

Geocoding and geosearch—ArcGIS Online Help | Documentation 

Another thing to note is that rooftop locations will only be returned if a rooftop location exists in the data for that address.  If the location does not exist in the data, the next best location will be returned instead such as the side of street or routing location.

Also, what is the minCharacters property?  I don't know what that is used for.  It is not a geocoding property.

With regards to searching without choosing a suggestion (no magicKey) versus searching with choosing a suggestion (with magicKey) returning different results, can you provide an example?  I would like to have some examples so that I can get a clearer understanding of the challenge you are having.

Brad