I had asked if it was considered an error when a street table
(StreetInfo, DynaMap 2000, etc.) had a street digitized in one
direction with the address range increasing in the other, and
whether it would matter if I just reversed the direction of the
street line (and also altering the FromLeft with ToRight, ToLeft
with FromRight fields so that the address locations themselves
would remain correct).
I received several responses, and apparently there are all kinds
of oddities in street files and geocoding algorithms that cause
mis-addressing. There are some bona-fide erroneous address range
inputting problems here and there, and a "WAD" (Works As
Designed) problem with MapInfo incorrectly locating addresses
that should be near the end of a long street. Also most people
who responded have seen this "backwards address range condition"
in a lot of street files. However, this condition itself won't
affect the accuracy of MapInfo's geocoding from street files. The
errors mentioned above are due to other reasons.
One person thought that the street directions may seem random but
that the address ranges always appear to increase in the
direction of the line and that:
"In other words, odd address numbers will always be on the
east
side of Main Street, and will increase from south to north,
but
they are relative to the 'digitized' direction of the line."
Well, don't bet on that either, or you may one day find yourself
sweating a deadline because the scope of the job suddenly got
bigger than you expected. My Hartford, CT data confirms this.
John Cassidy from GDT pointed out that the scheme I was hoping
for was an old DIME standard, but that now the TIGER files are
often digitized before the address ranges are assigned, and so
anything is possible. The only error condition is if the address
is wrong, or if it is on the wrong physical side of the street
(whichever way it "flows"), but odd or even ranges can occur on
either side of the street and the direction of the range has
nothing to do with the direction of the street line. In fact the
direction of the street line seems to have no intrinsic value
other than to serve as a reference to addresses to tell a user
which side of a street is considered "left" and which is "right"
in any particular case.
However, the 911 Computer Aided Dispatch (CAD) people were
unanimous in the opinion that this should be considered an error,
and they all make the correction to the street data before using
it. I think I'd agree that if you need to solve routing problems
the difficulty doubles if you don't clean up these data first.
Since no one cited any reason for streets to be digitized in any
particular direction, I think it's a safe assumption to just
switch a street line direction (while also updating the
addresses) to simplify routing problems. For example if you see
something like this:
1 99 101 199 201 299
o------------><-----------o---------->
2 98 100 198 200 298
you can alter that middle segment to:
1 99 101 199 201 299
o------------>o----------->o---------->
2 98 100 198 200 298
and there will be no problems with that. Note that the FromLeft
field in the middle segment gets swapped with the ToRight field
and that the ToLeft gets swapped with the FromRight. If you don't
also do this you'll be effectively putting the addresses on the
wrong side of the street.
So if it doesn't matter which way streets are digitized for
address geocoding, but makes a big difference for street routing
applications, why don't the street data vendors just perform this
QC on all their data anyway?
- Bill Thoen
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
