[Talk-us] parcel data next steps
SteveCoast
steve at asklater.com
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>
More information about the Talk-us
mailing list