<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.<br><br>Steve<div><br></div><div><span style="font-family: Helvetica; font-size: medium; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-text-size-adjust: auto; ">PS check out my kickstarter project</span><span style="font-family: '.HelveticaNeueUI'; font-size: 15px; line-height: 19px; white-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><a href="http://www.kickstarter.com/projects/237731198/gps-art-poster">http://www.kickstarter.com/projects/237731198/gps-art-poster</a></span></div></div><div><br>On Feb 25, 2013, at 12:17 PM, Brian Cavagnolo <<a href="mailto:bcavagnolo@gmail.com">bcavagnolo@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On Thu, Feb 21, 2013 at 9:04 PM, Brian May <<a href="mailto:bmay@mapwise.com">bmay@mapwise.com</a>> wrote:</span><br><blockquote type="cite"><span>On 2/21/2013 7:27 PM, Brian Cavagnolo wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hey guys,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>In a previous thread on parcel data, some people expressed interest in</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>participating in creating some sort of open repository for parcel</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>data.  I was imagining a conference call or something to discuss next</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>steps, but I think we can advance with email.  I'm imagining that it</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>makes sense to separate the data gathering process from the data</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>standardization/import process.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Regarding the data gathering, the main objective is to gather recent</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>raw data, licensing terms, and meta data from jurisdictions in</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>whatever form they make it available, organize it in a dumb directory</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>structure.  I was just going to set up an FTP (read-write)  and HTTP</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>(read-only) server to get this going.  Are there any</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>recommendations/opinions on a longer-term approach here?  Custom</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>webapp?  Off-the-shelf webapp?  Somebody mentioned a git repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Regarding standardization/import, I was planning on setting up an</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>empty instance of the rails port as a test bed.  Then participating</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>users could point JOSM and other tools at this alternative rails port</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>to examine, edit, and import parcel data.  We could also provide</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>planet-style dumps and mapnik tiles.  The idea is that we would have a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>safe place to screw up and learn.  Does this sound like a reasonable</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>direction?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Oh, and I found this fantastic paper that some parcel data people (Abt</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Associates, Fairview Industries, Smart Data Strategies) recently put</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>together for HUD [1] that examines many of the issues that they faced</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>building a parcel database.  Timely.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Ciao,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Brian</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>[1]</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="http://nationalcad.org/download/the-feasibility-of-developing-a-national-parcel-database-county-data-records-project-final-report/">http://nationalcad.org/download/the-feasibility-of-developing-a-national-parcel-database-county-data-records-project-final-report/</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Talk-us mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:Talk-us@openstreetmap.org">Talk-us@openstreetmap.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="http://lists.openstreetmap.org/listinfo/talk-us">http://lists.openstreetmap.org/listinfo/talk-us</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span>Hi Brian,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I am interested in collaborating on this. So here's some thoughts:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>From my perspective (and I think others as mentioned in other email</span><br></blockquote><blockquote type="cite"><span>threads), the main thrust of utilizing parcels is a source of addresses</span><br></blockquote><blockquote type="cite"><span>based on parcel centroids where address points or buildings with addresses</span><br></blockquote><blockquote type="cite"><span>are not available. In addition, several people have mentioned they utilize</span><br></blockquote><blockquote type="cite"><span>parcels as an overlay to assist with digitizing. The current consensus is</span><br></blockquote><blockquote type="cite"><span>that parcels should not be imported as a whole.</span><br></blockquote><span></span><br><span>The current _majority_ is that parcels should not be imported ;-)</span><br><span></span><br><blockquote type="cite"><span>I also think we need a little bit more sophisticated Data Catalog than a</span><br></blockquote><blockquote type="cite"><span>google spreadsheet. We need to capture more information and a spreadsheet</span><br></blockquote><blockquote type="cite"><span>gets a bit unwieldy after so may columns. I've got a prototype that I am</span><br></blockquote><blockquote type="cite"><span>working on getting out in the wild soon, but basically its a web form that</span><br></blockquote><blockquote type="cite"><span>people register to use and the info sits in a database.</span><br></blockquote><span></span><br><span>I'm with you on this.  I think we can get going with Ian's existing</span><br><span>spreadsheet, but I think we're going to eventually want a longer form</span><br><span>capability.  There seems to be some open source open data portal</span><br><span>options out there (e.g.,</span><br><span><a href="https://github.com/azavea/Open-Data-Catalog/">https://github.com/azavea/Open-Data-Catalog/</a>).</span><br><span></span><br><span>Also, Nancy von Meyer, one of the authors of that paper I posted a</span><br><span>link to, (and as you mentioned, a long time advocate for a national</span><br><span>parcel database) advised me of this inventory of parcel data that she</span><br><span>and others have built up:</span><br><span></span><br><span><a href="http://www.bhgis.org/inventory/">http://www.bhgis.org/inventory/</a></span><br><span></span><br><span>...of course it's read-only.  But it's a good resource to browse</span><br><span>around.  And we could probably arrange more back-end access.</span><br><span></span><br><blockquote type="cite"><span>A by-product of the effort to identify, catalog, gather raw data, etc. would</span><br></blockquote><blockquote type="cite"><span>be having a central location for storing raw parcel data that is not readily</span><br></blockquote><blockquote type="cite"><span>downloadable. For example, someone happens to have a copy of X county parcel</span><br></blockquote><blockquote type="cite"><span>data that they had to send a check for $25 to acquire, they received it on</span><br></blockquote><blockquote type="cite"><span>CD, and they would like to donate it to a central repository. This is</span><br></blockquote><blockquote type="cite"><span>assuming there are no restrictions on the data. It sounds like you're</span><br></blockquote><blockquote type="cite"><span>willing and able to donate disk and bandwidth to support this effort. I</span><br></blockquote><blockquote type="cite"><span>don't see a need to make a copy of data that is already sitting on the web.</span><br></blockquote><span></span><br><span>Good point about not duplicating the data that is readily available on</span><br><span>the web.  But one thing I've run into in the few cases that I've</span><br><span>investigated is that explicit terms are often unavailable on those</span><br><span>websites.  So some outreach is required to confirm the terms before</span><br><span>redistributing the data.  And of course policies can change.  So</span><br><span>there's something to be said for saving off a copy of some data to a</span><br><span>place where it is clearly guaranteed to be OSM compatible.</span><br><span></span><br><blockquote type="cite"><span>As far as standardization/import and the rails server - I think this is not</span><br></blockquote><blockquote type="cite"><span>the right path to take. As mentioned above, we shouldn't be wholesale</span><br></blockquote><blockquote type="cite"><span>importing parcels. Now you could do some standardization of parcel data for</span><br></blockquote><blockquote type="cite"><span>example to render polygons by land use codes and show single family,</span><br></blockquote><blockquote type="cite"><span>multi-family, commercial, government, etc land use types as an overlay layer</span><br></blockquote><blockquote type="cite"><span>for reference, but that is a huge effort by itself. Users knowledgeable</span><br></blockquote><blockquote type="cite"><span>about parcels in their state or local area could serve up something like</span><br></blockquote><blockquote type="cite"><span>this as a reference, but the goal is not to standardize the parcels and</span><br></blockquote><blockquote type="cite"><span>import them.</span><br></blockquote><span></span><br><span>The immediate goal is not to standardize and import parcels into the</span><br><span>mainline OSM dataset.  As we've established in previous threads, there</span><br><span>are some technical issues with this goal, and a wider question of</span><br><span>whether parcel boundaries belong in OSM at all.  But there is great</span><br><span>value to having a standardized source of parcel data with open</span><br><span>licensing, and I'm working with some researchers that are eager to</span><br><span>have such a resource.  We're also interested in some of the parcel</span><br><span>attributes (e.g., sales data, zoning) that may be esoteric to OSM.  So</span><br><span>I'm eager to start playing around with this.  Also, I'm pretty new to</span><br><span>OSM and want to learn more about the challenges presented by imports.</span><br><span>I recognize that these goals may not be a widespread OSM priority.</span><br><span>But perhaps we can also grow it into the "goto parcel overlay" you</span><br><span>describe.</span><br><span></span><br><span>Ciao,</span><br><span>Brian</span><br><span></span><br><span>_______________________________________________</span><br><span>Talk-us mailing list</span><br><span><a href="mailto:Talk-us@openstreetmap.org">Talk-us@openstreetmap.org</a></span><br><span><a href="http://lists.openstreetmap.org/listinfo/talk-us">http://lists.openstreetmap.org/listinfo/talk-us</a></span><br></div></blockquote></body></html>