[Talk-us] parcel data next steps

Brian Cavagnolo bcavagnolo at gmail.com
Tue Feb 26 04:41:59 UTC 2013


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



More information about the Talk-us mailing list