Re: [Talk-us] Turn restriction dispute FHP
Dave Hansen wrote: I know the current turn restriction relations aren't suited for it. But, instead of tagging left turn restriction from X to Y shouldn't we be tagging the pavement has an arrow that says left turn only? See http://wiki.openstreetmap.org/wiki/Key:turn Alexander ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Whole-US Garmin Map update - 2013-02-12
These are based off of Lambertus's work here: http://garmin.openstreetmap.nl If you have questions or comments about these maps, please feel free to ask. However, please do not send me private mail. The odds are, someone else will have the same questions, and by asking on the talk-us@ list, others can benefit. Downloads: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2013-02-12 Map to visualize what each file contains: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2013-02-12/kml/kml.html FAQ Why did you do this? I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/2013-02-12 Can or should I seed the torrents? Yes!! If you use the .torrent files, please seed. That web server is in the UK, and it helps to have some peers on this side of the Atlantic. Why is my map missing small rectangular areas? There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. Why can I not copy the large files to my new SD card? If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. Does your map cover Mexico/Canada? Yes!! I have, for the purposes of this map, annexed Ontario in to the USA. Some areas of North America that are close to the US also just happen to get pulled in to these maps. This might not happen forever, and if you would like your non-US area to get included, let me know. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] parcel boundaries and associated data in OSM
Hey guys,
In my research group (the Urban Analytics Lab at Berkeley's Department
of City and Regional Planning), we use parcel data for land-use
projection, accessibility, and visualization. For example, over the
past couple of years we worked with regional government agencies here
in the Bay Area to put together a parcel-level urbansim
(http://www.urbansim.org) land-use model for regional planning
purposes. We've also developed a prototype 3D visualization tool
(http://www.urbansim.org/Documentation/UrbanVision) to visualize
parcel data, and published on using OSM data for accessibility
calculations [0]. If you poke around the Internet for references to
our director Prof. Paul Waddell you'll get the idea.
We really want a nationwide consolidated, standard parcel database to
build upon. Such products are available from numerous proprietary
data vendors who make it their business to routinely gather and
consolidate data from local government agencies around the country.
Of course these are often expensive and have restrictions on
redistribution. Our federal government has been trying for sometime
to create a nationwide public domain parcel database [1][2][3], but
this has not happened. Many states have managed to consolidate parcel
data (e.g., Massachusetts, Montana, New Jersey). This is very
helpful, but notable work is required to adapt tools or research from
one state to another. And our state along with many others has no
such offering. As a result, parcel data users for whom proprietary
sources are too restrictive or expensive go about manually gathering
the data from county agencies. If the application doesn't span county
lines, and if the county is open with their data, this may not be a
problem. But these two conditions are often not both met, driving a
more intensive data gathering effort. Such efforts are often
duplicated for different projects. We believe that this landscape of
use and parcel data availability represents an opportunity to form a
parcel data community concerned with building and maintaining an open
nationwide (global?) consolidated parcel database.
This idea is [obviously] inspired by OSM. And my immediate thought
was, Fun! Let's add parcel data to OSM! How do we do that? This
inquiry has of course led to numerous more detailed questions, the
most fundamental one, of course, being: Is parcel data welcome in OSM?
I've spent some time reading through the mailing list history. In
addition to gaining an appreciation for some of the issues regarding
the management of parcel data, I promptly learned that this is a
controversial question. For each claim that a consensus exists
against parcel data in OSM, a parcel data advocate seems to emerge.
This leads to debate, which seems to focus on a specific set of issues
that I have posed as specific questions below. I've also dusted off
and enriched the wiki page and associated talk page on the matter
(http://wiki.openstreetmap.org/wiki/Parcel). My hope is that people
can respond to these questions and we can reach a clear consensus on
{whether,what sort of,conditions under which} parcel data is welcome.
And of course feel free to bring up any issues that are not
represented in this list. Finally, even if you believe that parcel
data does not belong in OSM, but that a nationwide open consolidated
parcel database would be useful (and possible:) I'm super interested
in this perspective.
Is parcel data useful to OSM?
Can parcel data possibly be kept up to date?
Does parcel data meet the on the ground verifiability criteria?
Can tools be adapted to accommodate parcel data density?
Ciao,
Brian
[0]
http://onlinepubs.trb.org/onlinepubs/conferences/2012/4thITM/Papers-A/0117-62.pdf
[1] http://books.nap.edu/openbook.php?isbn=NI000560
[2] http://www.nap.edu/catalog.php?record_id=11978
[3] http://www.fas.org/sgp/crs/misc/R40717.pdf
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
Ha. Totally missed this very recent discussion on the matter:
http://lists.openstreetmap.org/pipermail/talk-us/2012-December/010017.html
Nonetheless, feel free to respond. I'm going to go do some more homework ;-)
Ciao,
Brian
On Thu, Feb 14, 2013 at 12:29 PM, Brian Cavagnolo bcavagn...@gmail.com wrote:
Hey guys,
In my research group (the Urban Analytics Lab at Berkeley's Department
of City and Regional Planning), we use parcel data for land-use
projection, accessibility, and visualization. For example, over the
past couple of years we worked with regional government agencies here
in the Bay Area to put together a parcel-level urbansim
(http://www.urbansim.org) land-use model for regional planning
purposes. We've also developed a prototype 3D visualization tool
(http://www.urbansim.org/Documentation/UrbanVision) to visualize
parcel data, and published on using OSM data for accessibility
calculations [0]. If you poke around the Internet for references to
our director Prof. Paul Waddell you'll get the idea.
We really want a nationwide consolidated, standard parcel database to
build upon. Such products are available from numerous proprietary
data vendors who make it their business to routinely gather and
consolidate data from local government agencies around the country.
Of course these are often expensive and have restrictions on
redistribution. Our federal government has been trying for sometime
to create a nationwide public domain parcel database [1][2][3], but
this has not happened. Many states have managed to consolidate parcel
data (e.g., Massachusetts, Montana, New Jersey). This is very
helpful, but notable work is required to adapt tools or research from
one state to another. And our state along with many others has no
such offering. As a result, parcel data users for whom proprietary
sources are too restrictive or expensive go about manually gathering
the data from county agencies. If the application doesn't span county
lines, and if the county is open with their data, this may not be a
problem. But these two conditions are often not both met, driving a
more intensive data gathering effort. Such efforts are often
duplicated for different projects. We believe that this landscape of
use and parcel data availability represents an opportunity to form a
parcel data community concerned with building and maintaining an open
nationwide (global?) consolidated parcel database.
This idea is [obviously] inspired by OSM. And my immediate thought
was, Fun! Let's add parcel data to OSM! How do we do that? This
inquiry has of course led to numerous more detailed questions, the
most fundamental one, of course, being: Is parcel data welcome in OSM?
I've spent some time reading through the mailing list history. In
addition to gaining an appreciation for some of the issues regarding
the management of parcel data, I promptly learned that this is a
controversial question. For each claim that a consensus exists
against parcel data in OSM, a parcel data advocate seems to emerge.
This leads to debate, which seems to focus on a specific set of issues
that I have posed as specific questions below. I've also dusted off
and enriched the wiki page and associated talk page on the matter
(http://wiki.openstreetmap.org/wiki/Parcel). My hope is that people
can respond to these questions and we can reach a clear consensus on
{whether,what sort of,conditions under which} parcel data is welcome.
And of course feel free to bring up any issues that are not
represented in this list. Finally, even if you believe that parcel
data does not belong in OSM, but that a nationwide open consolidated
parcel database would be useful (and possible:) I'm super interested
in this perspective.
Is parcel data useful to OSM?
Can parcel data possibly be kept up to date?
Does parcel data meet the on the ground verifiability criteria?
Can tools be adapted to accommodate parcel data density?
Ciao,
Brian
[0]
http://onlinepubs.trb.org/onlinepubs/conferences/2012/4thITM/Papers-A/0117-62.pdf
[1] http://books.nap.edu/openbook.php?isbn=NI000560
[2] http://www.nap.edu/catalog.php?record_id=11978
[3] http://www.fas.org/sgp/crs/misc/R40717.pdf
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
Brian
Personally I think it's brilliant you're working on this, and I'd love OSM to
work hand in hand to make it happen. Ideally I'd love OSM to be the repository
for this, it helps everybody.
There is speculation (but no actual statistically valid causation data) to
suggest that imports somehow harm the community and, either way, it'd be
great to find a way to help local communities help massage things as we pull it
in.
At the end of the project, say in 2030 or something, it's going to have this
level of detail anyway so, I say why not start now?
Best
Steve
On Feb 14, 2013, at 12:29 PM, Brian Cavagnolo bcavagn...@gmail.com wrote:
Hey guys,
In my research group (the Urban Analytics Lab at Berkeley's Department
of City and Regional Planning), we use parcel data for land-use
projection, accessibility, and visualization. For example, over the
past couple of years we worked with regional government agencies here
in the Bay Area to put together a parcel-level urbansim
(http://www.urbansim.org) land-use model for regional planning
purposes. We've also developed a prototype 3D visualization tool
(http://www.urbansim.org/Documentation/UrbanVision) to visualize
parcel data, and published on using OSM data for accessibility
calculations [0]. If you poke around the Internet for references to
our director Prof. Paul Waddell you'll get the idea.
We really want a nationwide consolidated, standard parcel database to
build upon. Such products are available from numerous proprietary
data vendors who make it their business to routinely gather and
consolidate data from local government agencies around the country.
Of course these are often expensive and have restrictions on
redistribution. Our federal government has been trying for sometime
to create a nationwide public domain parcel database [1][2][3], but
this has not happened. Many states have managed to consolidate parcel
data (e.g., Massachusetts, Montana, New Jersey). This is very
helpful, but notable work is required to adapt tools or research from
one state to another. And our state along with many others has no
such offering. As a result, parcel data users for whom proprietary
sources are too restrictive or expensive go about manually gathering
the data from county agencies. If the application doesn't span county
lines, and if the county is open with their data, this may not be a
problem. But these two conditions are often not both met, driving a
more intensive data gathering effort. Such efforts are often
duplicated for different projects. We believe that this landscape of
use and parcel data availability represents an opportunity to form a
parcel data community concerned with building and maintaining an open
nationwide (global?) consolidated parcel database.
This idea is [obviously] inspired by OSM. And my immediate thought
was, Fun! Let's add parcel data to OSM! How do we do that? This
inquiry has of course led to numerous more detailed questions, the
most fundamental one, of course, being: Is parcel data welcome in OSM?
I've spent some time reading through the mailing list history. In
addition to gaining an appreciation for some of the issues regarding
the management of parcel data, I promptly learned that this is a
controversial question. For each claim that a consensus exists
against parcel data in OSM, a parcel data advocate seems to emerge.
This leads to debate, which seems to focus on a specific set of issues
that I have posed as specific questions below. I've also dusted off
and enriched the wiki page and associated talk page on the matter
(http://wiki.openstreetmap.org/wiki/Parcel). My hope is that people
can respond to these questions and we can reach a clear consensus on
{whether,what sort of,conditions under which} parcel data is welcome.
And of course feel free to bring up any issues that are not
represented in this list. Finally, even if you believe that parcel
data does not belong in OSM, but that a nationwide open consolidated
parcel database would be useful (and possible:) I'm super interested
in this perspective.
Is parcel data useful to OSM?
Can parcel data possibly be kept up to date?
Does parcel data meet the on the ground verifiability criteria?
Can tools be adapted to accommodate parcel data density?
Ciao,
Brian
[0]
http://onlinepubs.trb.org/onlinepubs/conferences/2012/4thITM/Papers-A/0117-62.pdf
[1] http://books.nap.edu/openbook.php?isbn=NI000560
[2] http://www.nap.edu/catalog.php?record_id=11978
[3] http://www.fas.org/sgp/crs/misc/R40717.pdf
___
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 boundaries and associated data in OSM
Before this discussion moves forward we should define what parcel data is. In my mind it's mostly-abutting polygons representing land ownership. Usually it comes with metadata about tax information and ownership information, and sometimes it has address information for buildings built on that parcel. On Thu, Feb 14, 2013 at 2:29 PM, Brian Cavagnolo bcavagn...@gmail.comwrote: Is parcel data useful to OSM? Yes! Parcel data can be useful to help find parks, schools, and other public areas. If it includes addressing information we can extract that to make it easier to map addresses and/or building footprints. However, it's my opinion that the parcel polygons themselves should NOT be imported into OSM. There's simply too much data, it can not be improved by other OSM mappers, and abutting polygons are one of the trickiest types of data to get right in the OSM data format. Can parcel data possibly be kept up to date? It's possible, but very very difficult. I don't think anyone in OSM has created a reliable two-way sync between external and OSM data. Such a thing has been on lots of people's wishlists for several years. Does parcel data meet the on the ground verifiability criteria? No. I'm sure there will be at least a couple people that argue against me, but I have yet to be convinced. Parcel data is surveyed by professionals, maintained by the government, and there is very rarely a physical manifestation of the actual parcel boundary. Can tools be adapted to accommodate parcel data density? Yes, and OSM will have to get there eventually as our data density increases, but we're not ready for it now. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
PS:
On Thu, Feb 14, 2013 at 2:41 PM, Steve Coast st...@asklater.com wrote:
Brian
Personally I think it's brilliant you're working on this, and I'd love OSM
to work hand in hand to make it happen. Ideally I'd love OSM to be the
repository for this, it helps everybody.
+1 to you working on this. Collecting parcels is a great idea! I started
doing this late last year and got this far:
https://docs.google.com/spreadsheet/ccc?key=0AsVnlPsfrhUIdEVZTzVFalFYYnlvTkc0R05wcUpsWVE#gid=0
I don't agree that OSM is the place it should go at this point. At the very
least we need to solve the data density problems in our editors/viewers and
the area data type problem.
In my mind this would be better in a GitHub repo with {Geo|Topo}JSON files
for each county.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
Hi Brian,
I'd like to ask for some of your time to meet in person to talk more about
this, as I'm the SF Bay Area, and am very interested in discussing this
sort of work.
Please contact me off-list if you're amenable.
Best
On Thu, Feb 14, 2013 at 12:49 PM, Ian Dees ian.d...@gmail.com wrote:
PS:
On Thu, Feb 14, 2013 at 2:41 PM, Steve Coast st...@asklater.com wrote:
Brian
Personally I think it's brilliant you're working on this, and I'd love
OSM to work hand in hand to make it happen. Ideally I'd love OSM to be the
repository for this, it helps everybody.
+1 to you working on this. Collecting parcels is a great idea! I started
doing this late last year and got this far:
https://docs.google.com/spreadsheet/ccc?key=0AsVnlPsfrhUIdEVZTzVFalFYYnlvTkc0R05wcUpsWVE#gid=0
I don't agree that OSM is the place it should go at this point. At the
very least we need to solve the data density problems in our
editors/viewers and the area data type problem.
In my mind this would be better in a GitHub repo with {Geo|Topo}JSON files
for each county.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
--
John Novak
585-OLD-TOPOS (585-653-8676)
http://www.linkedin.com/in/johnanovak/
OSM ID:oldtopos
OSM Heat Map: http://yosmhm.neis-one.org/?oldtopos
OSM Edit Stats:http://hdyc.neis-one.org/?oldtopos
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
We can solve the problem by sitting around waiting for it to happen, or forcing
the issue by going and doing this. I suggest the latter is better :-)
Steve
On Feb 14, 2013, at 12:49 PM, Ian Dees ian.d...@gmail.com wrote:
PS:
On Thu, Feb 14, 2013 at 2:41 PM, Steve Coast st...@asklater.com wrote:
Brian
Personally I think it's brilliant you're working on this, and I'd love OSM to
work hand in hand to make it happen. Ideally I'd love OSM to be the
repository for this, it helps everybody.
+1 to you working on this. Collecting parcels is a great idea! I started
doing this late last year and got this far:
https://docs.google.com/spreadsheet/ccc?key=0AsVnlPsfrhUIdEVZTzVFalFYYnlvTkc0R05wcUpsWVE#gid=0
I don't agree that OSM is the place it should go at this point. At the very
least we need to solve the data density problems in our editors/viewers and
the area data type problem.
In my mind this would be better in a GitHub repo with {Geo|Topo}JSON files
for each county.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
On 2/14/2013 3:43 PM, Ian Dees wrote: Before this discussion moves forward we should define what parcel data is. In my mind it's mostly-abutting polygons representing land ownership. Usually it comes with metadata about tax information and ownership information, and sometimes it has address information for buildings built on that parcel. On Thu, Feb 14, 2013 at 2:29 PM, Brian Cavagnolo bcavagn...@gmail.com mailto:bcavagn...@gmail.com wrote: Is parcel data useful to OSM? Yes! Parcel data can be useful to help find parks, schools, and other public areas. If it includes addressing information we can extract that to make it easier to map addresses and/or building footprints. However, it's my opinion that the parcel polygons themselves should NOT be imported into OSM. There's simply too much data, it can not be improved by other OSM mappers, and abutting polygons are one of the trickiest types of data to get right in the OSM data format. Can parcel data possibly be kept up to date? It's possible, but very very difficult. I don't think anyone in OSM has created a reliable two-way sync between external and OSM data. Such a thing has been on lots of people's wishlists for several years. Does parcel data meet the on the ground verifiability criteria? No. I'm sure there will be at least a couple people that argue against me, but I have yet to be convinced. Parcel data is surveyed by professionals, maintained by the government, and there is very rarely a physical manifestation of the actual parcel boundary. Can tools be adapted to accommodate parcel data density? Yes, and OSM will have to get there eventually as our data density increases, but we're not ready for it now. +1 on all of Ian's comments. I think we should start with some sort of nationwide parcel data clearinghouse. Ian made a good start with the Google Doc to document parcel data sources that could be used for obtaining site address data. My thought is we should have some kind of data catalog web app for this info, where people can register, create/update metadata records as needed, and have a bit more functionality than a google spreadsheet. There's a good bit of parcel data from govmts out there that doesn't have licensing restrictions, its cheap/free, but you have to order it and its shipped on DVD or ftp. The next step would be to obtain copies of this data and put it on the web for anyone to grab. We just need someone to host some space/bandwidth. Is that something the US Chapter can do? In addition, updates could be made whenever people get the itch. Or strive for an annual update. Updates would just be replacing the raw data. Going the next step into standardization to a common format, etc. is a huge can of worms. However, just knowing where to grab the data easily and having a central spot to grab data that isn't already sitting on the web would be a major step forward. Brian ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
From: Brian Cavagnolo [mailto:bcavagn...@gmail.com] Sent: Thursday, February 14, 2013 12:29 PM To: talk-us@openstreetmap.org Subject: [Talk-us] parcel boundaries and associated data in OSM Is parcel data useful to OSM? Parcel data in of itself has not found a use in OSM. Parcel data bounds sometimes coincide with other features which are useful for OSM but the data itself has not been useful. Remember, OSM isn't just a dumping ground for all the geodata you find. Can parcel data possibly be kept up to date? I haven't seen any evidence of it. The couple of parcel data imports that have taken place haven't updated. I would want to see a solid plan (with code) for keeping such an import up to date. How to handle preserving edits done in OSM when updating is tricky too. Again, I take a show me the code view on this. No one has managed an automated way to do this yet, and it needs to be automated for the volume of data we're talking about. Does parcel data meet the on the ground verifiability criteria? Marginal. While this doesn't *always* mean that something shouldn't be mapped, we're a crowd-sourced map, and including something the crowd can't improve on seems questionable. Can tools be adapted to accommodate parcel data density? I maintain a shapefile (or other ogr-readable file) to .osm converter so I'm familiar with the differences, and the .osm data model is not designed for parcel data with almost every single edge overlapping another parcel. Parcel data is far more computationally expensive to convert from .shp to .osm than a road network of the same file size. The .osm file format and API is designed for crowd-sourced editing and this involves design choices which aren't ideal for storing data like this. It would get marginally better with an area datatype, but there are still conflicting design decisions. To use parcel data this way the flow of the data to get from the county/city shapefile (or other source) to your tool would be... 1. Download shapefile 2. Convert shapefile to .osm (NOT trivial, and involves writing a new conversion for each county) 3. Conflate shapefile with existing data (Lots of work by hand or writing a completely new tool) 4. Upload .osm to API, resolving conflicts and merging nodes (Slow) 5. Extract area from planet.osm or xapi 6. Convert from .osm to shapefile (or other format or load into a DB) and use the data I would suggest some kind of interface that can store geojson files, shapefiles or the like. You're still going to have to convert them to a common tagging which is going to be a pain. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
On Thu, Feb 14, 2013 at 2:41 PM, Steve Coast st...@asklater.com wrote: Brian Personally I think it's brilliant you're working on this, and I'd love OSM to work hand in hand to make it happen. Ideally I'd love OSM to be the repository for this, it helps everybody. I'm with Steve on this. Cadastre data's eventually going to happen mostly because folks find it too useful. At the end of the project, say in 2030 or something, it's going to have this level of detail anyway so, I say why not start now? I do believe we just had our it won't be anything big or professional like Minix moment. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
On Thu, Feb 14, 2013 at 3:29 PM, Paul Norman penor...@mac.com wrote: Marginal. While this doesn't *always* mean that something shouldn't be mapped, we're a crowd-sourced map, and including something the crowd can't improve on seems questionable. Or it means someone in the crowd nailed it down to a point nobody else has been able to add anything to it. Not every object needs continuous maintenance. Someone saying, Hey, this changed and I don't think the map has yet is what MapDust is for. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
Hi Brian, All of your questions are good, and like you mentioned, we had a debate about this in late December. I don't think we (community and our software) are ready right now to import all of the parcel data in the US. However, it does not mean we should sit around and do nothing either! One of the projects that I was hoping to tackle this year is to setup an imaging layer in JOSM/potlatch for the MA parcel data. My current plan is to import the MA parcel shape files directly into postgis and render them. However, instead, we could first convert the shape file to an OSM file. Making one big OSM file (perhaps one per state) would force a bunch of problems to be solved. The data would need to be collected and scripts would need to written to do the conversion. It would also force the issue of getting the tags figured out. Getting that done this year would be real progress!! Rendering this parcel OSM file into an image layer for JOSM/potlatch would let everybody in OSM see/work with the data, paving the way for eventual integration. If you want to work together let me know. It seems like doing an image layer for just MA is a bit wasteful in the larger context of OSM. However, doing more than MA, will be too much work for just 1 person. Unless somebody else wants to help, I don't plan on doing more than MA. Thanks Jason. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] parcel boundaries and associated data in OSM
Brian Cavagnolo writes: We really want a nationwide consolidated, standard parcel database to build upon. Indeed. Is parcel data useful to OSM? Yes. Can parcel data possibly be kept up to date? No. Does parcel data meet the on the ground verifiability criteria? No. Not really. Part of my property has stone fencelines as property lines. The back part of my property is forested wetland, and there is no practical way to discern property lines on the ground. Can tools be adapted to accommodate parcel data density? Some will work now. Here's the problem: This data is maintained by someone else. As they change it, OSM will need to be updated. And any updates made by *any* editor will be non-authoritative. BUT! There is a solution: put them into a parallel database to OSM, say, http://closedstreetmap.com. This has three pleasant effects: o You're not tied to ODbL licensing, so you can have a more free license. o When you get a new data dump, you can completely nuke the old one and replace it with the new. o You don't have users making changes that nobody visiting the county real property office will fine. On the downside: o When a property line is tied to a feature, there's no way to associate them with each other. o Users of the data need to download from two locations. o You're not using the ODbL, so that people making collective works have to comply with all the licenses. These characteristics are shared by the unsolved 'OSM Layers' concept. -- --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
