Geocoding limited to a Search Area broke with ArcGIS Online update

JoeHershman

We have an application with on-line geocoding that has been deployed for a few years and working fine.  All of the sudden (seeming to correspond to the upgrade to Geocoding Service) it stopped working.

We limit searches to a small geographic area  and because of this have never required the users to enter a  Zip or city.  As stated this worked perfectly for years until the other day.  Now unless a zip or city is entered we do not get a valid result.  We instead get a single result returned but with all the attributes empty, and the point is just in the middle of the extent

We are using Runtime version 100.6

So... before the other day

• Send request without city or zip code and we get a set of good results within service area at that number and street

Starting a few days ago

• Send request without city or zip, receive single (bad) results with empty attributes located at a random location
• Send request with city or zip and receive the same results as before when sent without city or zip 

-Joe

@MichaelBranscomb 

 

 

JoeHershman

This is very odd.  Mind you nothing has changed in this in years.

But I was noticing how it showed the region strings in the content.  This is how State is setup in the view, and the user just picks a value from the dropdown

<ComboBox Grid.Column="1" SelectedIndex="0" SelectedValue="{Binding State}">
	<ComboBox.Items>
		<ComboBoxItem Content="PA" />
		<ComboBoxItem Content="WV" />
		<ComboBoxItem Content="KY" />
	</ComboBox.Items>
</ComboBox>

But what I decided to do was make a change, because the string shown in my first post seemed odd.  Previously, I just had State bound directly, but I changed it to

State = ((ComboBoxItem)State).Content.ToString()

After this change I am again getting valid results without needing the additional input.

Based on the timing of the issue appearing and the fact that there was an April update to the geocoding service I am still going to put that update as the cause.  But what it seems is that prior to the change the string 

System.Windows.Controls.ComboBoxItem: PA

was parsed as PA.  But after the update that was no longer the case.  I will not argue that parsing the above string to 'PA' should have been expected behavior.  Simply that evidence points to that was what was occurring.  After making the change in the code things seem to be working as expeected.

Thanks for the help, putting everything down and also looking at what happened with the query (and some Fiddler) pointed me where I needed to find the solution

-Joe