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
