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

Paul Norman penorman at mac.com
Thu Feb 14 21:29:07 GMT 2013

> 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.

More information about the Talk-us mailing list