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

Reverse Geocoding Returns Different Attributes With Composite Locator

KyleGruber

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.

<SPAN class="keyword token">var</SPAN> userLocation <SPAN class="operator token">=</SPAN> MainMap<SPAN class="punctuation token">.</SPAN>APSSMapView<SPAN class="punctuation token">.</SPAN><SPAN class="token function">ScreenToLocation</SPAN><SPAN class="punctuation token">(</SPAN>e<SPAN class="punctuation token">.</SPAN>Position<SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
                ReverseGeocodeParameters p <SPAN class="operator token">=</SPAN> <SPAN class="keyword token">new</SPAN> <SPAN class="token class-name">ReverseGeocodeParameters</SPAN><SPAN class="punctuation token">(</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
                p<SPAN class="punctuation token">.</SPAN>ResultAttributeNames<SPAN class="punctuation token">.</SPAN><SPAN class="token function">Add</SPAN><SPAN class="punctuation token">(</SPAN><SPAN class="string token">"*"</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
                <SPAN class="keyword token">var</SPAN> closest <SPAN class="operator token">=</SPAN> <SPAN class="keyword token">await</SPAN> MainMap<SPAN class="punctuation token">.</SPAN>BaseMap<SPAN class="punctuation token">.</SPAN>LocatorTask<SPAN class="punctuation token">.</SPAN><SPAN class="token function">ReverseGeocodeAsync</SPAN><SPAN class="punctuation token">(</SPAN>
                    userLocation<SPAN class="punctuation token">,</SPAN> p<SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN><SPAN class="line-numbers-rows"><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN></SPAN>

Any ideas? Is this expected behavior?

Najděte více příspěvků označených jako

Accepted answers

BradNiemand

Kyle,

It looks to me like you are using our new tool to build locators, "Create Locator tool". Is that correct? If so, I would recommend you create a multirole locator as opposed to two separate locators and then creating a composite. The locators created with this tool allow for multiple datasets to go into a single locator. Benefits include, size of the locator, performance, eliminating duplicate results, better reverse geocoding logic, and it is a single locator.

All that being said, what you are seeing is a byproduct of mixing older technology and newer technology. The new locators return more fields when performing reverse geocoding but when you put that same locator in a composite locator, that additional information will no longer get returned. This is because the composite locator only ever returned the values for the input fields of the participating locators (typically this is Address, City, State, Zip) plus some other fields like Loc_name and Match_addr.

Hope this helps.

Brad

All comments

BradNiemand

Kyle,

You can either create an empty featureClass based off of a schema that has the superset of the fields that are from all of the reference data, make a copy of one of the featureClasses, or just append to one of the featureClasses. Each one would use the "Append" GP tool and you will need to map each of the corresponding output fields to the destination featureClass.

In the "Append" tool, you would select "Use the field map to reconcile schema differences" option and then for each output field select the "Add New Source" button to choose the fields from the input datasets that line up with the output field.

You might want to set this up as a model if you are going to be doing this more than once.

Brad

KyleGruber

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.

BradNiemand

Kyle,

I think you have a few options and I will list them in order, top being best.

1. Combine the multiple reference data sets into a single featureClass. This is an additional step but lets you take advantage of all of the new features for the new locators. You can create a featureClass that is in a schema that works for all of the data and ETL the other datasets into that new featureClass.

2. Add all of the locators separately to the MMPK in the order that you would want them. This works sort of like a composite but with less limitations.

3. Create locators for individual cities and combine them into a composite. As you already know, there is a limitation to doing this.

KyleGruber

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)?

BradNiemand

Kyle,

Hope this helps.

Brad

RobertBorchert

It is an interesting choice to create address point features rather than address ranges along a centerline.

Please post your findings when you get a solution.

KyleGruber

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.

RobertBorchert

Geocoding is a science that has been mostly ignored by some for awhile now.

I believe your issue is the quality of the source road center line data.

I started off in GIS designing E911 systems for counties in the state I live in. The first step was to Stream GPS all the roads. Then assign address ranges with a left and right and direction of increasing address. Then when you geocode or reverse geocode the point looks for the centerline, then the address ranges for that segment and what side it is on. It them makes an approximation of the address based on percentages of how far down the line it is. Blah Blah Blah (technical term). An issue is this is not very exact on long segments.

I developed E911 for 5 different counties. To this day I can go to Google or Bing Maps and get the address almost exact by clicking the location for 3 of those counties. The other two the address will either show as unknown or be a range. Why, because the counties own the data and decide how much of it to share.

I was just working on addresses for our remote facilities. One of those counties I developed does not nicely share their data. But I was still known to their GIS person and she gave me the address based on their county data. Even when I put that address in a locator it was several miles away.

So, a possible reason why it is not working well is poor data. A solution may be to go to your counties and ASK for the accurate centerline data. Or in some cases you can find the Centerline data with address ranges in it, though they use an unknown dead language sometimes and split the data in to multiple parts. then you can make your own service and be more accurate.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

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