Latest Contributions by KyleGruber

‎01-01-2020

Mark, Thanks for the info, looking forward to clarification. I have to admit that it would be very disappointing if this change was made without any sort of notice or warning. While in an ideal world all applications would be running in 64-bit by now, we all know it's not an ideal world. Brad Niemand‌ Any input/information you have on this?

‎12-31-2019

Here is what I think is a relevant thread. https://community.esri.com/thread/242403-reverse-geocoding-returns-different-attributes-with-composite-locator Having multiple roles of the same type in locators would be very helpful.

‎12-31-2019

Are you using the new style locators (Create Locator) and merging them into a composite locator by any chance? If so, this thread has relevant information. https://community.esri.com/thread/242403-reverse-geocoding-returns-different-attributes-with-composite-locator#comment-8… The bottom line is, while it's technically supported, new style locators and composite locators are virtually unusable.

‎12-30-2019

Mark Bockenhauer, In my case, yes. Turning off Prefer 32-bit and recompiling does fix the issue, but obviously is not a fix due to the fact that we need to continue supporting 32-bit OSes, and I would expect ESRI would give us a healthy cushion period if you were planning on deprecating 32-bit support from the SDK. Edit: Sorry if this sounded a bit harsh, I'm not suggesting you were suggesting making apps 64-bit as a resolution, I just wanted to make it clear that it definitely would not be a viable resolution for us (and I'd assume many other SDK clients) at this time.

‎12-27-2019

John, Just to clarify, I'm also using "Create Locator", I've been referring to them as "New Style Locators" since ESRI refuses to give us a definitive way to clearly separate locators (only available in ArcGIS Pro) and address locators. The only difference is mine only contains a street address role. Thanks for pointing that out as I realize the language in my original post was ambiguous, I edited to clarify.

‎12-23-2019

I was really hoping this was something screwy going on in my main (complex) project, but the same thing is occurring in a simple repro app. https://helpdesk.alertts.com/content/Debugging/ArcGISReproApp_12232019.7z I also verified that downgrading to 100.6 fixes the problem.

‎12-23-2019

Since upgrading to 100.7, any action I try with LocatorTask inside a MobileMapPackage seems to be bombing with an obscure exception. System.Windows.Threading.Dispatcher => Esri.ArcGISRuntime.ArcGISRuntimeException: Invalid response at Esri.ArcGISRuntime.ArcGISException.HandleCoreError(CoreError error, Boolean throwException) at RuntimeCoreNet.GeneratedWrappers.Interop.CheckError(IntPtr errorHandle, Boolean throwOnFailure, GCHandle wrapperHandle) at RuntimeCoreNet.GeneratedWrappers.CoreTask.Get() at Esri.ArcGISRuntime.Internal.CoreTaskExtensions.TaskCompletedCallbackHandler`1.OnCompleted(Object sender, EventArgs e) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Esri.ArcGISRuntime.Internal.CoreTaskExtensions.TaskCompletedCallbackHandler`1.<CreateInternal>d__7.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at [REDACTEDMETHOD] in [REDACTED].cs:line 755 at [REDACTEDMETHOD] in [REDACTED].cs:line 525 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) Literally, just calling LocatorTask.LoadAsync is causing this exception. Is there something I maybe missed in the release notes? This is with a v2.4 Locator with a Street Address role created in ArcGIS Pro 2.4.3 packaged inside an MMPK created with ArcGIS Pro 2.4.3. Esri.ArcGISRuntime/Esri.ArcGISRuntime.WPF 100.7. Project targeting .NET Runtime 4.6.2. I'll create a repro project when I get a chance. Thanks as always.

‎11-16-2019

Just wondering here, the obvious answer seems to be "use strings instead of SuggestResults", but obviously I'd like some clarification on why the overload exists, and what the difference between the two is. My assumption would be that the SuggestResult overload is for convenience, and under the hood it would use the string equivalent anyway, but clearly that doesn't seem to be the case.

‎11-11-2019

Let me lay out a scenario, you have street address centerline and address point layers for Generic County, IL. You create a locator (I've been referring to them as "new style locators" that can only be created with ArcGIS Pro, we really need an official term for them) with an Point Address role and a Street Address role. User enters 265 Main St. This exists both as an address point, and a street address in a range (200-300 Main St, Springfield). The values in the centerline file and the address point file match exactly, so the Suggestor is only going to show one entry (as it should, the user shouldn't need to pick one if they represent basically the same thing (of course it's not the same exact thing, but that's another discussion)). Obviously, if a county has address point data, they're going to want to use that if an address matches, and fall back to the centerline if there's no exact address point. When you pass in a SuggestResult of 265 Main St, Springfield, it seems to only be pulling the StreetAddress. When you pass in the text of this same exact SuggestResult (I'm literally using SuggestResult.Label), I get two results in the order expected (PointAddress then StreetAddress). Any ideas? Sorry if this post seems erratic, I initially was suggesting there was a problem with the suggest behavior when I realized that suggest does nothing but returns text suggestions, nothing related to location coordinates or what type of feature it is. Now seems to be an issue with the Geocode overload. For reference: ArcGIS Runtime 100.6 (WPF) ArcGIS Pro 2.4.2 Local file Locator embedded in MMPK

‎10-22-2019

Brad, Thanks again. For option 1, I'm assuming one would use the merge tool, combine the common fields (L_F_ADD, L_T_ADD, etc), then leave additional fields for information one dataset may have and the other doesn't (SPEED, REST). Just want to verify this a practical way to go about this. Once again, you are a lifesaver, greatly appreciate all the assistance. I feel like you've given me more straight information about the new locators/geocoding in the past hour than I've gotten in the last 3 months.

‎10-22-2019

Brad, Thank you!! This is a huge help and solved this particular issue. Now, there is a question I have about this. Since you can only have one role of one type, what if you have multiple centerlines or address points from multiple cities? Is there currently no way to combine new locators of the same type, would you for instance just package them individually in a Mobile Map Package (not sure how this would be done publishing to Enterprise/Online)?

‎10-22-2019

Robert, I greatly appreciate the input. This dataset is coming directly from the county, and in the case I'm showing, it's actually an address points layer as opposed to the centerline. As an engineer for a CAD (Computer Aided Dispatch) company, I deal with a lot of bad map data, but I will say this particular dataset was originally created by one of the most respected GIS experts in the country (Shoreh Elhami). I'm not discounting anything you've said here, but this appears to purely be a bug in the runtime.

‎10-22-2019

Hi all, I currently have a support ticket open with ESRI about this, but figured it wouldn't hurt to also post it on the forum. Reverse geocoding with a local file-based locator returns completely different output attributes when it's a composite locator vs single locator (point address or street address). Single locator: Composite Locator: This issue is not seen with forward geocoding. I'm using a Composite Address Locator made up of a Point Address Locator and Street Address Locator created with ArcGIS Pro 2.4.2. I'm running ArcGIS Runtime v100.6 in a WPF application. The code used with both composite and non-composite locators is identical and very simple. var userLocation = MainMap.APSSMapView.ScreenToLocation(e.Position); ReverseGeocodeParameters p = new ReverseGeocodeParameters(); p.ResultAttributeNames.Add("*"); var closest = await MainMap.BaseMap.LocatorTask.ReverseGeocodeAsync( userLocation, p);‍‍‍‍‍ Any ideas? Is this expected behavior?

‎09-12-2019

David, Unfortunately, I believe this is a known bug that still exists in the 100.6 release. BUG-000114932 When the map view is zoomed or panned, labels do not reposition to move in view as they do in ArcGIS Pro.

‎07-18-2019

.NET Runtime Team, More fun with locators! When feeding a suggestion to a street address locator created in ArcGIS Pro 2.4 (and presumably every version before where the Create Locator tool was first available), using SuggestAsync on a Locator task with a street name that is just a number and contains a predirection (ie. 12944 S 124 W Ave, Tulsa, OK), the 124 part seems to “reset” the suggestions and it uses 124 as the address number instead of the address street name. Using the same locator in both ArcGIS Runtime SDK and ArcGIS Pro: Just to clarify, this is using v100.5.0 of the ArcGIS Runtime SDK for .NET. The issue does not seem to manifest in runtime when excluding the predirection (S), but including the predirection is necessary in our workflow. Pro and Runtime are using the same locator (TulsaOK_Centerline_Locator6). Here is the code snippet being used to get the suggestions from the locator. if (BaseMap.LocatorTask != null && BaseMap.LocatorTask.LoadStatus == Esri.ArcGISRuntime.LoadStatus.Loaded && BaseMap.LocatorTask.LocatorInfo.SupportsSuggestions) { var suggestParams = new SuggestParameters { MaxResults = 10, SearchArea = BaseMap.Maps[0].InitialViewpoint.TargetGeometry }; var suggestions = await BaseMap.LocatorTask.SuggestAsync(LocationSearchBox.Text, suggestParams); ObservableCollection<SuggestResult> sr = new ObservableCollection<SuggestResult>(suggestions); LocationResultsListBox.ItemsSource = sr; } BaseMap is the MobileMapPackage that the locator was exported with. The MMPK was created in ArcGIS Pro 2.4. I have noticed that subtle parameter differences in SuggestParameters cause large differences in the outcome. For instance, if SearchArea = BaseMap.Maps[0].InitialViewpoint.TargetGeometry was removed from the SuggestParameters, the results would be radically different, so I’m wondering if there’s another SuggestParameter property that needs to be set.

Online Status	Offline
Date Last Visited	‎08-05-2025 08:44 AM

My Ideas

Latest Contributions by KyleGruber

Re: Local Locators not working in 100.7?

Re: Create Multirole Locator With Multiple Instances of the Same Role

Re: Composite Locator has matches but returns no spatial information

Re: Local Locators not working in 100.7?

Re: Local Locators not working in 100.7?

Re: Local Locators not working in 100.7?

Local Locators not working in 100.7?

Re: Locator Geocode Result Returns Different Result - SuggestResult vs String?

Locator Geocode Result Returns Different Result - SuggestResult vs String?

Re: Reverse Geocoding Returns Different Attributes With Composite Locator

Re: Reverse Geocoding Returns Different Attributes With Composite Locator

Re: Reverse Geocoding Returns Different Attributes With Composite Locator

Reverse Geocoding Returns Different Attributes With Composite Locator

Re: Polygon Labels Disappear

Locator Suggestion Issue When Street Predirection Is Present

Re: Locator Custom Output Fields In Runtime

Re: Is URISA using the "P" in GISP correctly?

Local Locators not working in 100.7?

Re: Local Locators not working in 100.7?

Re: MMPK - Scale-Based Sizing