I'm seeing a difference in the way the suggestion/geolocation functionality works in ArcGIS Pro compared to Runtime. I've finally come up with a locator that works the way I want it to in pro, but it does not work the same way in runtime.
Search in Pro:
Search in Runtime:
If I put 9 E Broad in the locator search in runtime, it turns up a result, but that's exactly what I'm trying to avoid. As far as I understand, I'm using the same exact locator in both Pro and Runtime. Please tell me I'm missing something obvious here!
Repro Project:
https://helpdesk.alertts.com/content/ArcGISApp1.7z
Edit: Just FYI, this is a Street Address Locator created in ArcGIS Pro 2.3.2 being consumed by Runtime SDK 100.5.
Solved! Go to Solution.
Hello again Kyle,
I have some update on the issue with differences in suggest results returned. When performing Suggest operation, Pro automatically uses an extent to limit results. So doing a runtime search with just the text is not the same. So, to do a search that is similar/same you need to set SearchArea on SuggestParameters to the same search area Pro uses. But getting the two to use the exactly the same values is not easy. I tried following extent that gave me first two matching results that I see in Pro. You might have to refine search extent to get results matching Pro.
```
private async void LocationSearchBox_KeyUp(object sender, KeyEventArgs e)
{
if (e.Key == Key.Enter && !String.IsNullOrWhiteSpace(LocationSearchBox.Text))
{
Geometry searcharea = new Envelope(-10679603.1849148, 4311158.5891781, -10670629.0567609, 4315725.11168142, SpatialReferences.WebMercator);
var suggestParams = new SuggestParameters { MaxResults = 10, SearchArea = searcharea};
```
Any ideas on this? The behavior in Pro is absolutely perfect for what I'm trying to accomplish, but if there's no way to replicate the behavior in Runtime then I'm going to have to go a different route such as querying the feature layer, which may be what Pro is falling back to behind the scenes, just need to know.
Hi,
We're just about to investigate a similar issue recently reported - we'll let you know the results of that investigation.
Thanks for the repro and software versions you stated - that makes triage much easier.
Cheers
Mike
Thanks as always Mike!
Just wanted to further clarify, this does not seem to have anything to do with MMPKs specifically, just locators. I tried loading the .loc file directly using LocatorTask.CreateAsync and got the same exact behavior.
Hello Kyle,
I spent some time with your repro case and found two issues:
1. In LocationSearchBox_KeyUp, you would need to call SuggestAsync() instead of GeocodeAsync() since at that point you ar etrying to get the suggetsions.
2. I also found the binding of results doesn't work with Telerik Autocomplete control. If I replace the control with the list box, I see the results as expected.
Can you try these changes and let me know if it works for you?
--Preeti
Preeti,
I must admit I'm a bit shell shocked right now. I replaced the Telerik RadAutoCompleteBox with a simple TextBox/ListBox combination and the behavior seems to work perfectly as exacted now, putting in 100 Main now for instance pulls up all of the 100 N/E/S/W Main(s) as desired. I have no idea why the RadAutoCompleteBox was causing different behavior, I can only guess that SearchText is behaving differently than Text does on a normal text input element.
Also, on the KeyUp routine, I was using that basically as a last resort. It's checking for the Enter key, not a text change, and if there are no suggestions it's trying to geocode what is typed in the box as a last resort.
Thank you very much!
Michael Branscomb Preeti Maske
Hate to do it but have one last question on this. Everything seems to be working with the exception of intersections, passing the / or & character in the SDK to SuggestAsync appears to be completely ignored. Whereas in the screenshot above, I'm able to find an intersection E 49 PL & S 90 E Ave in Pro simply by putting in 49/90, no combination of input seems to work in SDK.
Hello Kyle,
I did observe the behavior you are reporting with intersections. I will have to take a look why there is a difference. I will get back to you.
Thanks,
Preeti
Just wanted to check in and see if this has been looked at yet, and if it's possibly been declared a bug with a case number I could be assigned to for tracking purposes. I also might reach out to the Pro team to see if there's any insight they can share on what they're doing internally when they make the locate call.