1

I've been using ArcMap 10.8.2 the last few weeks in order to create a tool to streamline the creation of an Excel sheet used by a city's wastewater engineering technicians to list stormwater assets owned by the city (within a project area) by nearest street intersection. The tool works almost completely as intended, but for some reason the reverse geocode tool has been assigning some assets' intersection names in reverse order (e.g. Main & 1st vs 1st & Main) and I cannot figure out why. The issue is seemingly minor, but the goal of the tool is to output a layer with an attribute table that's formatted correctly to run a report on, and any required editing after the tool is run counteracts its usefulness severely. The tool's ModelBuilder workflow is here:

Modelbuilder workflow

(tried to make it readable without making it immensely small) and a sample output table is here:

Output table w/ intersections "N Nelson st & E Cleveland ave" and "E cleveland ave & N Nelson st"

As you can see, Objects 1, 2, and 7 are geographically located at the same intersection but for some reason #2 has had the title reversed. When the report doc is run on those features, the assets are separated despite being in the same geographical location. Is there a way for me to force the program to geocode intersections in a certain order? Alternately, is there a field editing tool or report formatting operation I can utilize to standardize the address field? Note: I don't have permissions to directly edit the source data for the locator or layers which are the source for the original inputs of the tool.

Update 4/5/23: A workaround has been established by creating an "intersections" feature class using the "Feature vertices to points" tool and geocoding those features. This removes any mishaps from running the reverse geocoding tool multiple times and allows use of the "Spatial Join" tool to add the intended address field to the project assets. Still confused as to why the address would be reversed at all.

4
  • An alternative work-around is to add model steps to break apart the reverse-geocode result into two string fields, intersection_1 and intersection_2. Then create and updated reported_intersection field which conditionally concatenates these two strings by alpha sorting int_1 > int_2 or int_2 >int_1. With the right conditional calculation, the reported field will be computed consistently for reporting purposes. Apr 5, 2023 at 17:05
  • Here's why it is happening, and TLDR you can't do anything about it: the geocode content is created with both intersections A at B and B at A included. Since the search algorithm see the two as equally-valid result scores, the output is arbitrary based on where the cursor is. Can't fix arbitrary. Apr 5, 2023 at 17:09
  • @JasonInVegas Thanks for the information! I thought maybe it had something to do with pathfinding logic (like if the asset was on one of those streets it would prefer that street first), but I see what you mean. Thanks for the tip on the workaround as well, I think alpha sorting the street names might be the way to go. Ultimately I'm looking for a way to force the "main street" to come first, but the way the streets layer geometry is set up make that a complicated process. Much appreciated! I'll mark the Q as answered. Apr 5, 2023 at 17:24
  • Since you like it, I'll transfer my comment to an answer for karma Apr 5, 2023 at 20:07

1 Answer 1

1

An alternative work-around is to add model steps to break apart the reverse-geocode result into two string fields, intersection_1 and intersection_2. Then create and updated reported_intersection field which conditionally concatenates these two strings by alpha sorting int_1 > int_2 or int_2 >int_1. With the right conditional calculation, the reported field will be computed consistently for reporting purposes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.