nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

MMPK Locator Discrepency Between Pro and Runtime

KyleGruber

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:

Pro Locator Search

Search in Runtime:

Runtime Locator Search

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.

Vind meer berichten getagd met

Accepted answers

PreetiMaske

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};

```

All comments

KyleGruber

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.

KyleGruber

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!

PreetiMaske

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

KyleGruber

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.

KyleGruber

Thanks as always Mike!

MichaelBranscomb

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

KyleGruber

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.

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.