Select to view content in your preferred language

Any way to use Parity type info stored in a field in reference data?

712
3
05-22-2012 09:49 AM
HarryBowman
Deactivated User
I have reference data where some street segments have L\R odd\even parity, and others have mixed parity, with odd and even on the same segment. Which kind of parity is stored on a field. Is there any way to use that information in building or applying a locator? I can think of a terrible idea: splitting the reference data by parity type and using a composite locator to connect the normal and mixed parity streets. I hope there is a better idea.

Am I correct in thinking that if the street segment has 102-197 as an address range on the R side, for instance, that the geocoding engine will find 146 and 147 on the R side?

We have a lot of mixed parity cul-de-sacs that are getting missed because the address range is something like R (nothing) L 1-101, mixed parity.
Tags (2)
0 Kudos
3 Replies
JoeBorgione
MVP Emeritus
I have reference data where some street segments have L\R odd\even parity, and others have mixed parity, with odd and even on the same segment. Which kind of parity is stored on a field. Is there any way to use that information in building or applying a locator? I can think of a terrible idea: splitting the reference data by parity type and using a composite locator to connect the normal and mixed parity streets. I hope there is a better idea.

Am I correct in thinking that if the street segment has 102-197 as an address range on the R side, for instance, that the geocoding engine will find 146 and 147 on the R side?

We have a lot of mixed parity cul-de-sacs that are getting missed because the address range is something like R (nothing) L 1-101, mixed parity.


A search of my login will reveal a number of geocoding threads discussing accuracy and precision. I'll save you the search and mention the difference here; when you geocode against a linear feature, the resulting point has an interpolated location based on the range of addresses divided by the length of the line.  For example (and this I can type from muscle memory) if you have a street that has a range of 100-200 on the even side and 101-199 onthe even side, the address of 150 will interpolate at just about mid-point on the even side.  Accurate.  However, lets say the actual location of the house with 150 painted on the curb is the last house on block towards to 200 end, and is on odd side of the street.  If you need that kind of precision you'll want to collect point data somehow and geocode against them.

Many of the cul-de-sacs I deal with are mixed parity.  For my needs,  I just range the streets even and odd and go for it that way.  The way I see it, if a guy driving a fire truck can't tell which side of the street the smoke is coming from, he shouldn't be driving the truck....  I manage mixed parity on my regular street features that way; smooth them out so they have a level of accuracy.  Even if the point might land on the 'wrong' side of the street, that's a lot more accurate than no hit at all.

Linear street data is relatively affordable, generally available, and easy to work with (read: fudge).  But, there are always trade offs, and precision is one of them.  Points are precise, but getting that kind of precision takes time and effort.  And those equate to $$$; US or Canadian!

Ask yourself the question(s): Ultimately, how does my agency use this data?  What level of precision do we need to complete our stated mission?  If we need high precision data, do we have the time and budget to create them,or can we go with what we have, and develop the more precise data as we go?

Hope this helps-
That should just about do it....
0 Kudos
HarryBowman
Deactivated User
The cul-de-sacs come from a data vendor with no range on one side, and a range on the other side that is mixed parity. The address is not found if the range starts and ends odd (or even) and the address is the opposite.
Example:

MyCulDeSac
LFrom 2
LTo   100
Ltype M
RFrom -1
RTo -1
RType

If the input address is 35 MyCulDeSac, the locator will not find it. We could make the navigation system lie a little and say that it has the odd numbers on the R side of the street, but this would require adulterating the vendor data. I could do this, but I'd much rather get the locator to accept the truth.
0 Kudos
JoeBorgione
MVP Emeritus
require adulterating the vendor data.


I prefer massage.  Adulterating has such a ugly connotation.  I'm lucky, not only am I a data consumer, but I provide the data I consume.....
That should just about do it....
0 Kudos