[Talk-us] parcel data next steps

Tue Feb 26 04:47:45 UTC 2013

Thanks Brian. I hear the point of view, I just don't want it to be (too) overstated.

Steve

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

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

> On Mon, Feb 25, 2013 at 12:39 PM, SteveCoast <steve at asklater.com> wrote:
>> 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.
> 
> Fair enough.  I'll downgrade my statement from "majority" to "concerns
> have been expressed."
> 
> Ciao,
> Brian
> 
>> 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/38a68b3d/attachment-0001.html>