[Imports] Importing Arkansas data

[Michael Leibowitz]

On 03/28/2011 01:16 PM, Ian Dees wrote:
> On Mon, Mar 28, 2011 at 3:01 PM, Michael Leibowitz 
> <michael.leibowitz at intel.com <mailto:michael.leibowitz at intel.com>> wrote:
>
>         Here is a popular perspective from the OSM community, "If
>         parcel data
>         can't be measured, confirmed or improved by OSM editors, why
>         import
>         it?"  Use it as an overlay somewhere, somehow.
>
>
>     What makes postal codes different?
>
>
> In my mind only a few (major) things:
>
> - 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.

That's true of the UK.  Postal code (zip code) data is also in the US 
map.  It's generally free in the US.

> - 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.

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.

> - 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.

Are importers not OSM participants?

Cheers