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

Point Address Locator - House Number From-To range - Odd vs Even

ToyotaT18

I've built a Locator with 'Point Address' role. My addresses sometimes have a single house number (e.g. 34), and sometimes have a range (e.g. 40-46). Odd numbers and Even numbers are on opposite sides of the street, so a range will cover one or the other, eg 40-46 covers 40 & 42 & 44 & 46 only.

When I geocode in ArcGIS Pro using my Locator, it seems to not apply the Odd/Even numbers rule. So if I search for 41, it will geocode to the location with range 40-46, and still report a perfect match score of 100.0

The thing is, even if there is a more appropriate range to match to, eg 39-43, a search for 41 will still match to 40-46. I'm guessing it finds 40-46 first, decides that's a perfect match for some reason, then stops searching further? This happens even if the first number of the range matches exactly, eg 41-45.

I'd appreciate any advice on how to ensure the most appropriate match is made.

Encontre mais publicações marcadas com

Accepted answers

ToyotaT18

Ok I think this now solved, thanks to @ShanaBritt . My issue was to do with parity, my data had a bunch of values such as 'M' which allow for any match. I calculated a new parity value (either 'E' or 'O' only) based solely on the first number, and specified this as the parity parameter when creating the locator. It appears to be working, ie it only allows 'O' values to be matched with odd numbers being searched, and 'E' with even. So exactly the answer I was looking for, thanks @ShanaBritt !

All comments

JudithWammack

I might be misunderstanding the original post, but I thought the Point Address Locator role is intended to match discrete address that already exist in your reference data. In that case, it would not really enforce odd/even parity logic the way a Street Address Locator role does with address ranges.

Since your data includes ranges like 40-46, it sounds like street address interpolation behavior, A Street Address Locator role is generally what handles range matching and odd/even side logic.

I use Point Address Locators frequently, and they will usually return the closest matching feature even if the searched house number would technically fall on the opposite side of the street. So if parity and interpolation accuracy are important, I would expect a Street Address Locator role to be more appropriate than Point address.

Hopefully I'm understanding the original issue correctly.

PA Locator.png

ToyotaT18

Hi thanks for your reply, however I am indeed dealing with discrete address points. It's just some of the points represent/cover a range of house numbers, eg 40-46, rather than a single number. This is very common in Australia and the US, and is accounted for in the 'Create Locator' tool which allows for 'House Number From' and 'House Number To' fields when the 'Point Address' role is selected.

My query isn't necessarily around parity, it's around which is the best match. Suppose there there are 2 reference address points, each with a house number from-to range:

Address #1 is 374-384

Address #2 is 375-385

I search for 375 - which is the best match? The locator is matching to Address #1, with a reported score of 100 (and no other suggested matches). But clearly Address #2 is the better/correct match.

ToyotaT18

Ok I'll add it as an idea for ESRI to implement, if there's no current solution.

ToyotaT18

An update on this, in case anyone is following, or comes across a similar issue in the future.

I have submitted the fix as an idea, will have to wait and see if it is ever implemented.

Meanwhile I have come up with a workaround. I created 2 new 'subset' Point Address Locators - one which contains only address reference points with an 'Even' house number range, and one which contains only 'Odd' house number range records.

So my code first matches to the Full address Locator as usual. If it gets a match, I check if the result includes a value for the 'AddNumTo' attribute, eg geo_result[0]["AddNumTo"] <> ""

If there is an AddNumTo value then I know it's matched to a house number range. Now I check if it's a correct match, by comparing the search number with the house number range (AddNumFrom), and check they are both Even or both Odd.

If they don't match (one is Even, one is Odd) then I re-search the address using the relevant subset Locator (i.e. Even or Odd). If this gets a match, then I use this result instead.

I checked and this is helping to fix LOTS of records so I'm glad I identified the issue and came up with this workaround.

ToyotaT18

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

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