[Talk-us] parcel boundaries and associated data in OSM

[Dale Puch]

+1 for a GIS clearinghouse with sources and possibly also used to
facilitate attributing source data.

My personal opinion is OSM REALLY needs some sort of layer support.  There
are probably several ways to do it.

I think the best would be multiple databases (and organizations?) for
housing the other GIS data that is only fringe stuff for OSM's main
concerns.  Especially stuff that did not need a direct tie to other OSM
point/line/relation features.

Buildings, nautical markings, parcel data, airplane markings, power and
other utilities are all candidates to be housed separately.

This requires modifications to the existing tools, possibly large ones.
Editors and renderers could then select what data to work with, and show
with each other.  Downside is managing the data goes to the right
layer/database and preventing duplicates.


On Thu, Feb 14, 2013 at 4:29 PM, Paul Norman <penorman at mac.com> wrote:

> > From: Brian Cavagnolo [mailto:bcavagnolo at gmail.com]
> > Sent: Thursday, February 14, 2013 12:29 PM
> > To: talk-us at 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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>



-- 
Dale Puch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20130214/429317d1/attachment.html>