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 wrote: > On Mon, Feb 25, 2013 at 12:39 PM, SteveCoast 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 wrote: >> >> On Thu, Feb 21, 2013 at 9:04 PM, Brian May 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 vo
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 wrote: > On Mon, Feb 25, 2013 at 3:39 PM, SteveCoast 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
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 wrote: > On Thu, Feb 21, 2013 at 9:04 PM, Brian May 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.
Re: [Talk-us] "paying a debt" and "making connections"
On Jan 17, 2013, at 11:04 AM, Mike N wrote: > On 1/17/2013 10:10 AM, Richard Weait wrote: >> I did ask, "what it would take to get you to hold a local Mappy Hour in >> your town?" That was never answered. So, I ask again, "What would it >> take?" > > More mappers. I've tried everything I could think of to get others > interested, but have given up recently - it's all an uphill swim. Don't give up, it took over two years to get the Seattle group going :-) > > But.one new mapper in my area was highly motivated to contribute by the > "US Shields Development Server". He seems to have lost interest in more > contributions while waiting for a possible real US Shields Server. > > > ___ > 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] Happy New Year from MapRoulette!
This is awesome. Steve On Jan 9, 2013, at 9:36 PM, Martijn van Exel wrote: > Hi all, > > We've seen some great progress from MapRoulette users fixing the > almost 70,000 connectivity errors in the US. Returning from my > Christmas break, they were all but eliminated! Great, but we did not > really have the next challenge ready yet. So for now, we expanded the > scope of the connectivity challenge to include Mexico and Canada, so > we have over 57,000 fresh connectivity errors for you to sink your > teeth into. So stop reading and start fixing, over at > http://maproulette.org/! > > PS the next challenge is almost done, we could also do a parallel > MapRoulette for that, what do you think? > -- > Martijn van Exel > http://oegeo.wordpress.com/ > http://openstreetmap.us/ > > ___ > 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
