Re: [Talk-us] parcel data next steps
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
Re: [Talk-us] parcel data next steps
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 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
Re: [Talk-us] parcel data next steps
On Mon, Feb 25, 2013 at 3: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. If you haven't done so already, please try editing an area that has had parcel data added. It is a nightmare. I know tools can be improved, but still parcels have very little relation to any other feature, even landuses, fences, etc. often don't line up. The only way I'd like to see parcel data added to OSM is if the concept of layers is added to the API. Then we'd have a landuse layer, a parcel layer, a ??? layer, and an everything else layer. -Josh ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
I'm not arguing that life is easy with parcels. I'm questioning the majority statement. If anything parcels will be hard. That's a good thing. If we want to take the easy route we should give up now. Steve PS check out my kickstarter projecthttp://www.kickstarter.com/projects/237731198/gps-art-poster On Feb 25, 2013, at 12:50 PM, Josh Doe j...@joshdoe.com wrote: On Mon, Feb 25, 2013 at 3: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. If you haven't done so already, please try editing an area that has had parcel data added. It is a nightmare. I know tools can be improved, but still parcels have very little relation to any other feature, even landuses, fences, etc. often don't line up. The only way I'd like to see parcel data added to OSM is if the concept of layers is added to the API. Then we'd have a landuse layer, a parcel layer, a ??? layer, and an everything else layer. -Josh ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
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
Re: [Talk-us] parcel data next steps
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
Re: [Talk-us] parcel data next steps
SteveCoast writes: If anything parcels will be hard. That's a good thing. If we want to take the easy route we should give up now. Well, as Josh points out, parcels are not necessarily related to anything on the ground. They could be, e.g. my property lines are co-incident with stone walls, barbed wire, and split-rail fences except where they don't. And the source of parcel data is going to be external to OSM -- almost certainly the county clerks's real property office. And it's not a physical description of the property anyway -- it's a legal description of it. Having the physical features perfectlty mapped wouldn't help. So the chief value, I think, of getting this into OSM is more, rather, getting it into OSM format, and aggregating it on a single server. That is an fton of value, and is a worthy goal. I don't believe that there's any sensible or valuable way to get it into OSM itself. I only say this because I tried it. Bought a copy of Oneida County's parcel data, put it into OSM format. Loaded it into JOSM, and ... It didn't really make any sense when merged in with OSM data. As a separate layer, it makes sense. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
+1 on this, one step at a time. Lets just get the data first. I don't think we should worry about importing or standardizing into anything yet. That step should happen once we have a pretty good size sample of the data so we can figure out what's available. Thanks Jason. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Sat, Feb 23, 2013 at 11:07 AM, Jason Remillard remillard.ja...@gmail.com wrote: +1 on this, one step at a time. Lets just get the data first. I don't think we should worry about importing or standardizing into anything yet. That step should happen once we have a pretty good size sample of the data so we can figure out what's available. Do do we have a place to put the data set up? Also what would be a good way to track which areas of the country we've already acquired data for? -- Jeff Ollie ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
We can put them on the OSM US server. So far the best suggestion to keep track of which data we've collected is the Google Doc spreadsheet I have set up. I'm happy to transfer this information to somewhere else if a better option comes up. On Sat, Feb 23, 2013 at 9:24 PM, Jeffrey Ollie j...@ocjtech.us wrote: On Sat, Feb 23, 2013 at 11:07 AM, Jason Remillard remillard.ja...@gmail.com wrote: +1 on this, one step at a time. Lets just get the data first. I don't think we should worry about importing or standardizing into anything yet. That step should happen once we have a pretty good size sample of the data so we can figure out what's available. Do do we have a place to put the data set up? Also what would be a good way to track which areas of the country we've already acquired data for? -- Jeff Ollie ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
Brian May b...@mapwise.com writes: I also think we need a little bit more sophisticated Data Catalog than a google spreadsheet. Email and a wiki page sounds good to me for coordination. Maybe we can bring it up in a Mappy Hour as well. And if there's enough of a need, we could do a separate parcels / address oriented Google Hangout. I always find it boggling that open data projects are willing to use google docs and google hangouts. It would be really nice to at least have the data in a free software/free culture compatible place like an OSM foundation server. pgpJOBPk0pX4E.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
Interesting. How does parcel data work? What does it cover and what's the data interesting for OSM in it? Is this about sourcing address data? On Thu, Feb 21, 2013 at 7:27 PM, Brian Cavagnolo bcavagn...@gmail.comwrote: 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Fri, Feb 22, 2013 at 8:55 AM, Greg Troxel g...@ir.bbn.com wrote: Brian May b...@mapwise.com writes: I also think we need a little bit more sophisticated Data Catalog than a google spreadsheet. Email and a wiki page sounds good to me for coordination. Maybe we can bring it up in a Mappy Hour as well. And if there's enough of a need, we could do a separate parcels / address oriented Google Hangout. I always find it boggling that open data projects are willing to use google docs and google hangouts. It would be really nice to at least have the data in a free software/free culture compatible place like an OSM foundation server. I'm sure if someone puts a Google Docs or Google Hangout clone on an OSM foundation server that people would be happy to do this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Fri, Feb 22, 2013 at 8:01 AM, Alex Barth a...@mapbox.com wrote: Interesting. How does parcel data work? What does it cover and what's the data interesting for OSM in it? Is this about sourcing address data? Parcel data is interesting to OSM because it usually has addressing information. It's interesting to the rest of the world for many other reasons. Sometimes it includes landuse information (commercial, residential, etc.), tax and ownership information, building age or other historical information, etc. Since a large chunk of municipalities have this stuff digitized and their state's have open records laws it's just a matter of spending time to collect it all. In some cases it's free and online, sometimes they will burn a CD for you and charge you for their time, other times it's not online and you have to go to the county's GIS office to pick it up. Google started doing this a while back. When you zoom all the way in to a city and see land ownership lines alone streets chances are the parcel information is available in a digital format somehow -- we just have to get it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Thu, Feb 21, 2013 at 6:27 PM, Brian Cavagnolo bcavagn...@gmail.comwrote: 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. I think the easiest thing to do right now is to collect a list of URLs and contact information for where this data might be. When it's easily obtainable we should download it and collate it. I've got a directory on the OSM US server with a few large chunks of data. I'm happy to give you an account if you want to continue filling that up. As far as metadata about this stuff I think a spreadsheet will have to do for now until we figure out commonalities between the available metadata. I suppose knowing the vintage, license, contact information, and location of the file(s) containing parcel data is the most important part. 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? I don't think we should worry about importing or standardizing into anything yet. That step should happen once we have a pretty good size sample of the data so we can figure out what's available. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Fri, Feb 22, 2013 at 7:55 AM, Greg Troxel g...@ir.bbn.com wrote: I always find it boggling that open data projects are willing to use google docs and google hangouts. It would be really nice to at least have the data in a free software/free culture compatible place like an OSM foundation server. While there may be open alternatives to Google Docs (I don't know, I've never looked - and wikis don't count as far as I'm concerned), I've never seen any open alternative to Google Hangouts. I'd love to be corrected on that point though. -- Jeff Ollie ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On 2/22/13 12:35 PM, Jeffrey Ollie wrote: On Fri, Feb 22, 2013 at 7:55 AM, Greg Troxel g...@ir.bbn.com wrote: I always find it boggling that open data projects are willing to use google docs and google hangouts. It would be really nice to at least have the data in a free software/free culture compatible place like an OSM foundation server. While there may be open alternatives to Google Docs (I don't know, I've never looked - and wikis don't count as far as I'm concerned), I've never seen any open alternative to Google Hangouts. I'd love to be corrected on that point though. i think that if an open alternative were available, the US chapter would certainly switch away from google hangouts. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
Hello all, I mentioned a few months back that there are several places, particularly fere in the midwest, that don't own their own parcel data. Here in the St Louis area many of the counties have actually leased their parcel data from a private company for decades. The yearly lease includes an exhorbitant fee and licensing restrictions that are very specific on who they can share the parcel data with. What a crazy business model! The St Louis are might be a parcel map Black Hole for your project. I have to imagine there are other areas in the same situation. Rick Marshall Rick Marshall, PhD, GISP President VerticalGeo 130 Sawgrass Ln O'Fallon, IL 62269 (618) 670-4259 rick.marsh...@verticalgeo.com www.verticalgeo.com Read Our Blog at: http://verticalgeo.wordpress.com On Feb 22, 2013 12:00 PM, Richard Welty rwe...@averillpark.net wrote: On 2/22/13 12:35 PM, Jeffrey Ollie wrote: On Fri, Feb 22, 2013 at 7:55 AM, Greg Troxel g...@ir.bbn.com wrote: I always find it boggling that open data projects are willing to use google docs and google hangouts. It would be really nice to at least have the data in a free software/free culture compatible place like an OSM foundation server. While there may be open alternatives to Google Docs (I don't know, I've never looked - and wikis don't count as far as I'm concerned), I've never seen any open alternative to Google Hangouts. I'd love to be corrected on that point though. i think that if an open alternative were available, the US chapter would certainly switch away from google hangouts. richard __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Thu, Feb 21, 2013 at 6:27 PM, Brian Cavagnolo bcavagn...@gmail.com wrote: 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? Rather than an open rails port that anyone can point JOSM at and edit, I'd suggest something different. The rails port would be read-only, so that end-users could use it as a read-only layer in JOSM, or used to render tiles, etc. The only way for data to get into the rails port would to be imported from the original source files provided by the respective jurisdictions. We'd need to develop software that could handle the imports, hopefully in an incremental fashion so that as updates are made available you wouldn't have to rebuild the entire database. -- Jeff Ollie ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
On Fri, Feb 22, 2013 at 7:55 AM, Greg Troxel g...@ir.bbn.com wrote: I always find it boggling that open data projects are willing to use google docs and google hangouts. It would be really nice to at least have the data in a free software/free culture compatible place like an OSM foundation server. I find it boggling that someone complains about this every time a link to a google product is posted but the complaint is never accompanied by a helpful alternative suggestion. I'm fine with people not liking/using google products and even agree to some degree. But let's at least operate on lunch planning rules. If you veto a suggestion, you must suggest a workable alternative. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel data next steps
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. I think this project needs to dovetail / build upon the work that Ian Dees started with finding sources of address data. Parcel polygons are one potential source. However, parcel polygons are valuable by themselves, so we should be documenting all available sources of parcel data as we pursue addresses. 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. 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. 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. So, continuing on from the raw data gathering, taking it one step further, some organization could gather up the freely downloadable data plus the data sitting in this repository and serve up a WMS layer or tiles of parcel polygons. And this could be the goto source for a parcel overlay for the OSM community members interested in utilizing a parcel overlay layer for editing. Email and a wiki page sounds good to me for coordination. Maybe we can bring it up in a Mappy Hour as well. And if there's enough of a need, we could do a separate parcels / address oriented Google Hangout. Sounds like Serge is already organizing something similar, and maybe we just particpiate in that to start, since there's a lot of overlap. Thanks for sharing the link
