<div dir="ltr">I like keeping the address separate, since NYC GIS put in the work to give the spatial locations of the addresses a meaning other than just the centroid. <div><br></div><div>Here seems to be an example of where the imports have begun: <a href="http://www.openstreetmap.org/#map=18/40.64105/-73.96687">http://www.openstreetmap.org/#map=18/40.64105/-73.96687</a></div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 14, 2013 at 1:01 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">There's a bit of context missing from this conversation, so I want to<br>
fill people in on what happened, and then we can discuss the technical<br>
merits.<br>
<br>
Alex made his proposal (with my endorsement) before the import<br>
happened. Alex suggestebut then modified the data to this alternate<br>
way before the import event. So now we have both kinds of addresses in<br>
NYC. You can see some of the pre-import discussion at:<br>
<a href="https://github.com/osmlab/nycbuildings/issues/15" target="_blank">https://github.com/osmlab/nycbuildings/issues/15</a><br>
<br>
We also have an import event to show what happens with users and the data.<br>
<div class="im"><br>
On Mon, Oct 14, 2013 at 12:35 PM, Alex Barth <<a href="mailto:alex@mapbox.com">alex@mapbox.com</a>> wrote:<br>
<br>
> Now there's reason to revisit this decision: the data steward (Colin Reilly<br>
> from NYC GIS) told me that NYC GIS took great care to place addresses at<br>
> about where the entrance of the building sits.<br>
<br>
</div>We have a tag "entrance", but when I suggested tagging the entraces as<br>
entrances,  Alex suggested that many of the points were not entrances,<br>
but centroids.<br>
<br>
If they're addresses, I say tag them as addresses. Then we can<br>
encourage mappers on the ground to refine the entrances to match<br>
ground truth, and also to add service entrances, etc.<br>
<div class="im"><br>
> This makes me think that there's value in not tossing the address location<br>
> information but keep it in all cases, even if there is only one address per<br>
> building.<br>
><br>
> Here is a comparison of the two options. I'd like to discuss and decide at<br>
> tonight's imports hangout.<br>
><br>
> ## Option 1: Merge addresses into buildings where possible<br>
><br>
> In cases where there is one address point within a building polygon, we take<br>
> address attributes, assign it to the building polygon and toss the address<br>
> point.<br>
><br>
> Pros:<br>
><br>
> a) This is how a lot of buildings are done in OSM<br>
> b) Not regarding standing practice, merging addresses into buildings is an<br>
> exception from the generally applicable method of doing separate address<br>
> points.<br>
><br>
> Cons:<br>
><br>
> a) we lose data<br>
<br>
</div>If we tag the entrances as entrances, as suggested on the issue 15, we<br>
lose no data.<br>
<div class="im"><br>
> b) makes it harder for NYC GIS to leverage OSM<br>
<br>
> ## Option 2: Always keep address points separate<br>
><br>
> In this case we never merge addresses to building polygons, instead always<br>
> keep them as separate entities.<br>
><br>
> Pros:<br>
><br>
> a) this is the NYC GIS way, making it nicer for GIS folks to use OSM<br>
> b) this is the generally applicable method. No matter whether we have one or<br>
> multiple addresses you can expect to find a separate node carrying address<br>
> information.<br>
> c) retains useful information<br>
><br>
> Cons:<br>
><br>
> a) Diverges (but does not violate [1]) common OSM practice<br>
<br>
</div>b) We see users mistagging addresses<br>
<br>
In NYC, at the import, I've seen users tagging the address points with<br>
building information, such as the type of building it is<br>
(building=residence).<br>
<br>
This confusion is probably going to continue, leading to more problems<br>
in OSM where the attributes of the building are placed off the<br>
building.<br>
<br>
c) We see multiple addresses<br>
<br>
In the NYC import, I've found multiple addresses in/near a building.<br>
This is from previous data, and needs cleanup. Multiple address points<br>
aren't wrong when there's a POI and a building, but without a<br>
building, it's confusing<br>
<br>
d) It adds an extra step to data consumers<br>
<br>
If you tag the building with an address, you can get the address of it<br>
by looking at it. And if you have a POI within the geometry of the<br>
building, you can get it by looking at the building container, if the<br>
node doesn't have it.<br>
<br>
With nodes as points, you have to look at the poi node, then look at<br>
the building, see that the building has no address, then look for a<br>
node<br>
<br>
If you tag the node as is done here, you have to look at the building,<br>
see it has no address data, then look for nodes within it, and see if<br>
they do.<br>
<br>
e) It adds no explicit value without entrance tag<br>
<br>
Tagging entrances as values with an address is useful. Not only does<br>
it have value on its own, but you can even add a tag to indicate that<br>
the entrance is off a certain street (we don't have a tag for this<br>
now, but it wouldn't be hard to add).<br>
<br>
But right now, we don't have the entrance tag, so we lose the benefits of both.<br>
<br>
<br>
I think both ways are suboptimal, but they both bear consideration.<br>
<br>
- Serge<br>
<br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</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>