[Talk-us] parcel data next steps

SteveCoast steve at asklater.com
Mon Feb 25 20:39:41 UTC 2013


Majority of what exactly? I think it's tough to put much credence in a couple of people on this mailing list vs. anyone who added data this month as statistically valid.

Steve

PS check out my kickstarter projecthttp://www.kickstarter.com/projects/237731198/gps-art-poster

On Feb 25, 2013, at 12:17 PM, Brian Cavagnolo <bcavagnolo at gmail.com> wrote:

> On Thu, Feb 21, 2013 at 9:04 PM, Brian May <bmay at mapwise.com> wrote:
>> On 2/21/2013 7:27 PM, Brian Cavagnolo wrote:
>>> 
>>> Hey guys,
>>> 
>>> In a previous thread on parcel data, some people expressed interest in
>>> participating in creating some sort of open repository for parcel
>>> data.  I was imagining a conference call or something to discuss next
>>> steps, but I think we can advance with email.  I'm imagining that it
>>> makes sense to separate the data gathering process from the data
>>> standardization/import process.
>>> 
>>> Regarding the data gathering, the main objective is to gather recent
>>> raw data, licensing terms, and meta data from jurisdictions in
>>> whatever form they make it available, organize it in a dumb directory
>>> structure.  I was just going to set up an FTP (read-write)  and HTTP
>>> (read-only) server to get this going.  Are there any
>>> recommendations/opinions on a longer-term approach here?  Custom
>>> webapp?  Off-the-shelf webapp?  Somebody mentioned a git repository.
>>> 
>>> Regarding standardization/import, I was planning on setting up an
>>> empty instance of the rails port as a test bed.  Then participating
>>> users could point JOSM and other tools at this alternative rails port
>>> to examine, edit, and import parcel data.  We could also provide
>>> planet-style dumps and mapnik tiles.  The idea is that we would have a
>>> safe place to screw up and learn.  Does this sound like a reasonable
>>> direction?
>>> 
>>> Oh, and I found this fantastic paper that some parcel data people (Abt
>>> Associates, Fairview Industries, Smart Data Strategies) recently put
>>> together for HUD [1] that examines many of the issues that they faced
>>> building a parcel database.  Timely.
>>> 
>>> Ciao,
>>> Brian
>>> 
>>> [1]
>>> http://nationalcad.org/download/the-feasibility-of-developing-a-national-parcel-database-county-data-records-project-final-report/
>>> 
>>> _______________________________________________
>>> Talk-us mailing list
>>> Talk-us at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-us
>>> 
>> Hi Brian,
>> 
>> I am interested in collaborating on this. So here's some thoughts:
>> 
>> From my perspective (and I think others as mentioned in other email
>> threads), the main thrust of utilizing parcels is a source of addresses
>> based on parcel centroids where address points or buildings with addresses
>> are not available. In addition, several people have mentioned they utilize
>> parcels as an overlay to assist with digitizing. The current consensus is
>> that parcels should not be imported as a whole.
> 
> The current _majority_ is that parcels should not be imported ;-)
> 
>> I also think we need a little bit more sophisticated Data Catalog than a
>> google spreadsheet. We need to capture more information and a spreadsheet
>> gets a bit unwieldy after so may columns. I've got a prototype that I am
>> working on getting out in the wild soon, but basically its a web form that
>> people register to use and the info sits in a database.
> 
> I'm with you on this.  I think we can get going with Ian's existing
> spreadsheet, but I think we're going to eventually want a longer form
> capability.  There seems to be some open source open data portal
> options out there (e.g.,
> https://github.com/azavea/Open-Data-Catalog/).
> 
> Also, Nancy von Meyer, one of the authors of that paper I posted a
> link to, (and as you mentioned, a long time advocate for a national
> parcel database) advised me of this inventory of parcel data that she
> and others have built up:
> 
> http://www.bhgis.org/inventory/
> 
> ...of course it's read-only.  But it's a good resource to browse
> around.  And we could probably arrange more back-end access.
> 
>> A by-product of the effort to identify, catalog, gather raw data, etc. would
>> be having a central location for storing raw parcel data that is not readily
>> downloadable. For example, someone happens to have a copy of X county parcel
>> data that they had to send a check for $25 to acquire, they received it on
>> CD, and they would like to donate it to a central repository. This is
>> assuming there are no restrictions on the data. It sounds like you're
>> willing and able to donate disk and bandwidth to support this effort. I
>> don't see a need to make a copy of data that is already sitting on the web.
> 
> Good point about not duplicating the data that is readily available on
> the web.  But one thing I've run into in the few cases that I've
> investigated is that explicit terms are often unavailable on those
> websites.  So some outreach is required to confirm the terms before
> redistributing the data.  And of course policies can change.  So
> there's something to be said for saving off a copy of some data to a
> place where it is clearly guaranteed to be OSM compatible.
> 
>> As far as standardization/import and the rails server - I think this is not
>> the right path to take. As mentioned above, we shouldn't be wholesale
>> importing parcels. Now you could do some standardization of parcel data for
>> example to render polygons by land use codes and show single family,
>> multi-family, commercial, government, etc land use types as an overlay layer
>> for reference, but that is a huge effort by itself. Users knowledgeable
>> about parcels in their state or local area could serve up something like
>> this as a reference, but the goal is not to standardize the parcels and
>> import them.
> 
> The immediate goal is not to standardize and import parcels into the
> mainline OSM dataset.  As we've established in previous threads, there
> are some technical issues with this goal, and a wider question of
> whether parcel boundaries belong in OSM at all.  But there is great
> value to having a standardized source of parcel data with open
> licensing, and I'm working with some researchers that are eager to
> have such a resource.  We're also interested in some of the parcel
> attributes (e.g., sales data, zoning) that may be esoteric to OSM.  So
> I'm eager to start playing around with this.  Also, I'm pretty new to
> OSM and want to learn more about the challenges presented by imports.
> I recognize that these goals may not be a widespread OSM priority.
> But perhaps we can also grow it into the "goto parcel overlay" you
> describe.
> 
> Ciao,
> Brian
> 
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20130225/76895740/attachment-0001.html>


More information about the Talk-us mailing list