[Imports] Importing Arkansas data

[Michael Leibowitz]

On 04/04/2011 10:03 AM, Serge Wroclawski wrote:
> On Mon, Apr 4, 2011 at 5:11 PM, Michael Leibowitz
> <michael.leibowitz at intel.com>  wrote:
>> 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.
> When you say many maps include it, can you give me an example of a
> general purpose map that includes it?

At sufficient zoom levels of google maps, you see what is essentially 
parcel data.

>>   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.
> The point Ian is making is that the general purpose utility of parcel
> data is low, and I agree. If you think that that parcels are generally
> useful in ways other than for tax collection, and they don't change so
> often, maybe you can explain why you think that, and what benefit this
> would have to OSM to have such a huge new dataset dumped in it.

I think parcel data has uses other than tax collection, but I won't say 
that it doesn't change often.  It changes frequently, and a one-time 
import of parcel data will not be all that beneficial.  The import of 
such data needs to be more of a sync than a one-time import.

> - 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?
> That is correct.

Really?  People working to improve The Map are not community members?  
Their work is not valued?

> It's time to take off the kid gloves here. Imports have not been our
> friend, and even on a place like the imports list- I'll say it: If
> your first inclination is to do an import- you're going to cause the
> project harm.
>
> I spend a lot of my time cleaning up imported data, and I know I'm not
> the only one, especially in the US, which is a complete mess.
>
> Since I don't recognize your name from the lists other than on this
> thread, let me give you my humble view on imports.
I am interested in imports, and so I joined the import list.  I don't 
have active plans to do an import.  I just had a reaction to the 
negative view of imports and parcel imports.

> Only consider doing an import if:
>
> 1) You've been with the project over a year.
>
> 2) You've manually collected data using a GPS and Potlatch or Josm.
>
> 3) You know the data set you're considering importing very well.
>
> 4) You have a plan on how to handle updating the data.
>
> 5) There is general consensus on this list that the data is valuable.
>
> 6) You're prepared to document the import on the wiki.
> 7) You're intimately familiar with the arguments OSM has against
> imports, and you can argue against your own import successfully.
>
> 8) You have a concrete plan on integrating your imported data with the
> existing data in your area, and that plan does not include either
> duplicate data or removing existing user contributed data
> automatically.

Actually, I think the problems with imports have more to do with the way 
in which data is imported than imports themselves.  If the import is 
duplicating or removing other's contributions without rhyme or reason, 
there is something wrong with the import process in my opinion.  
Furthermore, as the nature of the data is dynamic, it shouldn't be the 
norm that imports are a one-time one-way system.  They should be more 
properly thought of as merges or synchronizations.  I know, for example, 
in my metropolitan area, the address database generated by the GIS 
department is updated weekly.  If one were to make a one-time import, 
not only would they probably stomp on a lot of entries already existing, 
the data would become wrong eventually.  However, a continual import has 
value.  Although survey is good, the GIS department's opinion of address 
is the canonical source.  Likewise for other data sources.

Cheers