On Thu, Feb 21, 2013 at 9:04 PM, Brian May <b...@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@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
