[Imports-us] Address and Building Data Conflatation
Brian H Wilson
brian at wildsong.biz
Mon Jul 15 19:14:53 UTC 2013
Pulling this off the NYC topic and onto my rural project -- ignore if
you are only interested in NYC!
On 07/15/2013 08:08 AM, Serge Wroclawski wrote:
> 1. How to conflate the NYC Data for building and address data.
>
> My understanding of the address data is that it should be in the form
> of point data, where the building data is polygons.
When I was working on this a few weeks ago the message I got was that
addresses should be always be attached to buildings as tags and that
there should not be separate address points. I am now confused. I spent
a lot of time trying to come up with a good way to attach addresses to
individual buildings. Maybe that was a waste of time?
Rural areas frequently have many buildings per tax lot. They are all at
the same address yet having each barn and shed tagged with street number
still seems wrong to me. So does trying to find an algorithm to pick out
which building polygon is the house (123) and which is the granny unit
out back (123 1/2) and which is the barn.
I am beginning to think that trying to pre-process ALL the data into
perfect shape before an import is a lofty goal but perhaps means no
import will ever happen because there not many people here and
vanishingly few capable volunteers. They are not up to being trained to
use JOSM, their eyes glaze over in 30 seconds.
In the past (not OSM) I have dealt with addresses by using the tax lot
centroid to create a point layer and then (as time permits) adjusting
the point to the appropriate location (sometimes it's center of the
primary building, sometimes it's the driveway entrance to the property,
depending on the local fire department since that's who I am working for.)
It still seems better to me to keep the address numbers separated from
the buildings, as per your example when you want to separate two
entrances to the same building or in my case when you want to have a
large building with 10 addresses. If you put them in as points, and they
are not perfect on this first pass, then searching on address will still
get you close enough to find the front door and later on anyone can edit
them to push them into a better position.
> I know our normal process is to check each building polygon and see if
> it contains one or more address points. If it's one address point, the
> tags will apply to the building. If it's two points, we'll treat each
> point as a entrance on the building and tag them separately.
What if there are 10 or more addresses for one building? This often
happens in my area when there are townhouses or apartments and each one
has a separate address. (Not just a unit number)
Doesn't having a mix of points and polygons tagged in the same area make
things confusing? Maybe this is just because I am new at OSM, so I am
not used to having a single heterogeneous data set.
In my region I have never seen data with buildings that already have
addresses attached. Where I work (OR|CA|WA), buildings are on tax lots
and tax lots have addresses. Buildings sometimes have a tax lot id,
square feet, and maybe a count of floors. When a tax lot has many
addresses it is usually shown as a range. 1050-1100 Main Street. Are
there are 5 houses or 50 apartments there? It is often ambiguous. It's
good enough to get a firetruck to the front door of 1060 but would
probably take someone who lives in the building(s) to accurately place
individual points.
Another good one that crops up is mobile home parks and vacation parks,
where there can be 50 slots in one tax lot, each with a separate phony
address. The tax assessor's official address is "123 Main St" but the PO
still delivers mail to "5 Sunset Village Homes". This can't be dealt
with algorithmically because it requires local knowledge.
I probably won't attend the hangout this afternoon because it seemed
like I bumped someone else out last time who actually needed to be
there, and I have not actually had any time to work on the Benton county
import lately.
Brian Wilson
Corvallis Oregon
More information about the Imports-us
mailing list