<div dir="ltr">Hey all,<div><br></div><div>I cannot allot the time to read through all of this at work. But, I'm going to want to do a similar project in my county, which has about 288395 address points. Perhaps I can join the import discussion later.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 3:39 PM, Serge Wroclawski <span dir="ltr"><<a href="mailto:emacsen@gmail.com" target="_blank">emacsen@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Jul 15, 2013 at 3:14 PM, Brian H Wilson <<a href="mailto:brian@wildsong.biz">brian@wildsong.biz</a>> wrote:<br>


> Pulling this off the NYC topic and onto my rural project -- ignore if you<br>
> are only interested in NYC!<br>
><br>
><br>
> On 07/15/2013 08:08 AM, Serge Wroclawski wrote:<br>
>><br>
>> 1. How to conflate the NYC Data for building and address data.<br>
>><br>
>> My understanding of the address data is that it should be in the form<br>
>> of point data, where the building data is polygons.<br>
><br>
><br>
> When I was working on this a few weeks ago the message I got was that<br>
> addresses should be always be attached to buildings as tags and that there<br>
> should not be separate address points. I am now confused. I spent a lot of<br>
> time trying to come up with a good way to attach addresses to individual<br>
> buildings. Maybe that was a waste of time?<br>
<br>
</div>You're missing the context of that quote. The "should be in the form<br>
of point data" is in what form NYC would release their data (should<br>
that actually happen), not a process for OSM.<br>
<br>
That's why I then discussed how to process this into OSM consumable data.<br>
<div class="im"><br>
> Rural areas frequently have many buildings per tax lot. They are all at the<br>
> same address yet having each barn and shed tagged with street number still<br>
> seems wrong to me. So does trying to find an algorithm to pick out which<br>
> building polygon is the house (123) and which is the granny unit out back<br>
> (123 1/2) and which is the barn.<br>
<br>
</div>We discussed this on the hangout several weeks ago, and barns and<br>
other secondary buildings probably shouldn't have addresses on them at<br>
all.<br>
<div class="im"><br>
> I am beginning to think that trying to pre-process ALL the data into perfect<br>
> shape before an import is a lofty goal but perhaps means no import will ever<br>
> happen because there not many people here and vanishingly few capable<br>
> volunteers. They are not up to being trained to use JOSM, their eyes glaze<br>
> over in 30 seconds.<br>
<br>
</div>I am not sure what you are saying, but if you are saying that import<br>
into OSM in a sustainable way- you're right, but what's far worse is<br>
bad import that has to be cleaned up later.<br>
<div class="im"><br>
> In the past (not OSM) I have dealt with addresses by using the tax lot<br>
> centroid to create a point layer and then (as time permits) adjusting the<br>
> point to the appropriate location (sometimes it's center of the primary<br>
> building, sometimes it's the driveway entrance to the property, depending on<br>
> the local fire department since that's who I am working for.)<br>
<br>
</div>If you have a small number of objects, this may be doable.<br>
<br>
The solution that we thought made more sense was for residences, to<br>
use the larger structure as the object with the address. We'll assume<br>
that most people choose to live in the larger structure, and those<br>
that don't (for example, that have a greenhouse that's larger than<br>
their home), we can fix later.<br>
<br>
Obviously for commercial property, this is not going to work as well.<br>
<div class="im"><br>
> It still seems better to me to keep the address numbers separated from the<br>
> buildings,  as per your example when you want to separate two entrances to<br>
> the same building or in my case when you want to have a large building with<br>
> 10 addresses. If you put them in as points, and they are not perfect on this<br>
> first pass, then searching on address will still get you close enough to<br>
> find the front door and later on anyone can edit them to push them into a<br>
> better position.<br>
<br>
</div>Naked address nodes have their own problems, and those problems are<br>
worse than the conflation issues, IMHO.<br>
<div class="im">><br>
>> I know our normal process is to check each building polygon and see if<br>
>> it contains one or more address points. If it's one address point, the<br>
>> tags will apply to the building. If it's two points, we'll treat each<br>
>> point as a entrance on the building and tag them separately.<br>
><br>
> What if there are 10 or more addresses for one building? This often happens<br>
> in my area when there are townhouses or apartments and each one has a<br>
> separate address. (Not just a unit number)<br>
<br>
</div>We can find that out and handle it:<br>
<a href="http://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers" target="_blank">http://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers</a><br>
<br>
In fact the examples given cover the exact situation you're envisioning.<br>
<div class="im"><br>
> Doesn't having a mix of points and polygons tagged in the same area make<br>
> things confusing? Maybe this is just because I am new at OSM, so I am not<br>
> used to having a single heterogeneous data set.<br>
<br>
</div>I think this is a three part question:<br>
<br>
1. Is it confusing to me<br>
2. Is it confusing to our tools?<br>
3. Is it confusing to other mappers?<br>
<br>
It's certainly not confusing to me. I'd rather all the buildings had<br>
addr:street and addr:housenumber on them, and then we'd be all set. In<br>
my mind, an address is an attribute of a building.<br>
<br>
It's not confusing to our tools. Potlatch and iD have preset fields<br>
for addresses.<br>
<br>
And for other mappers- I think naked nodes are confusing because they<br>
don't correspond to a physical, observable object. Maybe that's a<br>
difference between the way a GIS person thinks, and an OSM person.<br>
<div class="im"><br>
> In my region I have never seen data with buildings that already have<br>
> addresses attached.<br>
<br>
</div>Address data is scarce for the whole world in OSM, and that's why<br>
we're so focused on it.<br>
<div class="im"><br>
> Where I work (OR|CA|WA), buildings are on tax lots and<br>
> tax lots have addresses.<br>
<br>
</div>We expect anyone, with no external information, to be able to survey<br>
an area. Tax lots aren't really surveyable, which is why we're<br>
generally not in favor of including them on OSM.<br>
<div class="im"><br>
> Are there are 5 houses or 50<br>
> apartments there? It is often ambiguous. It's good enough to get a firetruck<br>
> to the front door of 1060 but would probably take someone who lives in the<br>
> building(s) to accurately place individual points.<br>
><br>
> Another good one that crops up is mobile home parks and vacation parks,<br>
> where there can be 50 slots in one tax lot, each with a separate phony<br>
> address. The tax assessor's official address is "123 Main St" but the PO<br>
> still delivers mail to "5 Sunset Village Homes". This can't be dealt with<br>
> algorithmically because it requires local knowledge.<br>
<br>
</div>I agree that local knowledge and manual survey are the best form of<br>
data and what we should ideally be collecting.<br>
<br>
But then I think "A million buildings sure is a lot of buildings" and<br>
would prefer to start with *something*<br>
<div class="im"><br>
> I probably won't attend the hangout this afternoon because it seemed like I<br>
> bumped someone else out last time who actually needed to be there, and I<br>
> have not actually had any time to work on the Benton county import lately.<br>
<br>
</div>I don't think this week will be as busy. If we continually bump up<br>
against the limit, I will look into alternatives.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Serge<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Imports-us mailing list<br>
<a href="mailto:Imports-us@openstreetmap.org">Imports-us@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/imports-us" target="_blank">http://lists.openstreetmap.org/listinfo/imports-us</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Elliott Plack</div><div dir="ltr"><a href="http://about.me/elliottp" target="_blank">http://about.me/elliottp</a></div>
</div>