Hiya,<br><br><div class="gmail_quote">On Fri, May 4, 2012 at 2:17 PM, Toby Murray <span dir="ltr"><<a href="mailto:toby.murray@gmail.com" target="_blank">toby.murray@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

[..] </blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Though the address belongs to an area, so it would make sense to keep<br>
> the corresponding boundary.<br>
<br>
Does it? Certainly for official records such as taxes it does. But<br>
this is outside of OSM's domain.<br></blockquote><div><br>Certainly. An address in OSM is a node. If you must, add it to a building so a user can derive a centroid, but a building centroid can still be wildly inaccurate for address level geocoding. <br>

</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In OSM, the use case for address data is geocoding and I would argue<br>
that general use geocoding users would rather get a building outline<br>
or even a node at the main entrance of a location, not the centroid of<br>
the property. In Fresno this may be pretty much the same thing but in<br>
less populated areas, the plot might be rather large and you would<br>
definitely want the address data to be where the actual residence is.<br></blockquote><div><br>Agreed. What you want is the main entrance to the building. Second best is building centroid, worst is parcel centroid. The thing is, when you offer address level geocoding, you suggest a level of accuracy that you can't offer when you resort to centroids.  <br>

<br></div></div><br>-- <br>martijn van exel<br>geospatial omnivore<br>1109 1st ave #2<br>salt lake city, ut 84103<br>801-550-5815<br><a href="http://oegeo.wordpress.com" target="_blank">http://oegeo.wordpress.com</a><br>