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 <bcavagn...@gmail.com> wrote: > On Mon, Feb 25, 2013 at 12:39 PM, SteveCoast <st...@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 <bcavagn...@gmail.com> wrote: >> >> 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
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
