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.
Steve PS check out my kickstarter projecthttp://www.kickstarter.com/projects/237731198/gps-art-poster On Feb 25, 2013, at 12:17 PM, Brian Cavagnolo <[email protected]> wrote: > On Thu, Feb 21, 2013 at 9:04 PM, Brian May <[email protected]> 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 >>> [email protected] >>> 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 > [email protected] > http://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
