<div class="gmail_quote">On Mon, Apr 4, 2011 at 11:11 AM, Michael Leibowitz <span dir="ltr"><<a href="mailto:michael.leibowitz@intel.com">michael.leibowitz@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On 03/28/2011 01:16 PM, Ian Dees wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Mar 28, 2011 at 3:01 PM, Michael Leibowitz <<a href="mailto:michael.leibowitz@intel.com" target="_blank">michael.leibowitz@intel.com</a> <mailto:<a href="mailto:michael.leibowitz@intel.com" target="_blank">michael.leibowitz@intel.com</a>>> wrote:<br>

<br>
        Here is a popular perspective from the OSM community, "If<br>
        parcel data<br>
        can't be measured, confirmed or improved by OSM editors, why<br>
        import<br>
        it?"  Use it as an overlay somewhere, somehow.<br>
<br>
<br>
    What makes postal codes different?<br>
<br>
<br>
In my mind only a few (major) things:<br>
<br>
- If I remember correctly, in the UK postcode data were (are?) not free (in any sense of the word), so someone decided to start trying to collect that data. I think it was one of OSM's first "project of the unit-of-time"? Either way, it was a good thing to get the community together and give an example of what free and open data mean.<br>

</blockquote>
<br>
That's true of the UK.  Postal code (zip code) data is also in the US map.  It's generally free in the US.<br></blockquote><div><br></div><div>This is not true. The Zipcode Tabulation Areas (the things currently imported into OSM) are generated by the Census for record keeping and have very little to do with the actual boundaries of zipcodes. The real zipcodes are controlled by the USPS and sold to businesses with a restrictive license.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Post codes are vastly different in size than parcel data. Parcel data is (usually) property boundaries on the order of <2 acres. These are small, 4-node polygons that have little use other than a county's tax collection and property owner's dispute resolution. The tons of nodes and ways make editing difficult, don't necessarily line up with building boundaries (buildings frequently cross a parcel boundary), and don't necessarily contain addressing information.<br>

</blockquote>
<br>
I disagree with your assessment of utility.  It is helpful to know the bounds of an address, which a parcel often gives.  That's why many maps include it.  You do raise a valid point of buildings often not being exactly within a tax lot.  I'm curious how other mapping providers solve this problem or if it is effectively a non-problem.<br>
</blockquote><div><br></div><div>Can you give some examples of why you might want to know the bounds of an address? In every case I can think of you want to know the point (for routing). I can think of some cases where you might want to know the extent of a building (e.g. a shopping mall) to know what POI are contained therein, but I can't think of a use for parcels.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Most importantly, OSM mappers can not make the data any better. By their very definition, any changes to the imported parcel data make them invalid and useless. If OSM participants can't improve the data then it should not be in the OSM database.<br>

</blockquote>
<br>
Are importers not OSM participants?<br></blockquote><div><br></div><div>They are, but I don't see that relating to any of my questions. Once an importer brings the data in to OSM it is immediately stale. In the best case someone will keep the parcel data up to date with future data dumps from the municipality. In the worst case it grows stale, people move the nodes around, remove tag data required for future updates, delete pieces of it because it's annoying, etc.</div>
</div>