Los Angeles County Land Use Import

From OpenStreetMap Wiki
Jump to navigation Jump to search

Goals

To contribute useful land use data (polygons) to OSM for Los Angeles County. Most significant is park and school data but there is also available data for retail land use, hospitals, town halls, golf courses, colleges, and cemeteries.

Schedule

  • Start sometime October 2013
  • Finish by January 2014

Import Data

Background

Source site: http://egis3.lacounty.gov/dataportal/2011/02/22/la-county-land-types/
Data license: Public Domain, it's listed on the link above and I've emailed with Mark Greninger, LA County Geographic Information Officer, and he specified everything on the site under the Free category is Public Domain.

Derived Data Files

The derived files are broken up into each land use type and each will be imported separately.

These are already conflated, useless attributes have been removed, and they're ready to be converted to a database for OSMLY.

Import Type

  • One time import, no plans for updates.
  • Tools:
    • OSMLY - majority of editing, planning, reporting problems, QA-ing
    • JOSM - as needed

Data Preparation

Data Reduction & Simplification

  1. geometry is simplified as it goes into the OSMLY database via Shapely to a tolerance of 0.0001
  2. useless attributes were removed, for the most part they are internal categorizations and sporatic ids, lots of NULL

Tagging Plans

  • name="NAME"
  • tags to be appended:
    • for schools: amenity=school
    • for parks: leisure=park
    • for retail land: landuse=retail
    • for hospitals: amenity=hospital
    • for golf courses: leisure=golf_course
    • for colleges: amenity=college
    • for cemeteries: amenity=cemetery

Changeset Tags

Data Transformation

  1. from the source data each land use type (parks, schools, etc..) was separated into its own file based on categorizations found in the CAT1, CAT2, and CAT3 columns
  2. each land use type was then conflated (see Conflation section below for details)
  3. geometry converted from Shapefile to GeoJSON in EPSG:4326/WGS84 projection
  4. GeoJSON gets processed through an OSMLY preparation script, build.py
    • simplifies geometry, marks anything too complex for OSMLY (multipolygons) and builds the OSMLY database
  5. in OSMLY, data is transformed from GeoJSON to OSM and OSMChange formats as needed with osm-and-geojson
    • if opening in JOSM, converts to OSM
    • if submitting to OSM API, converts to OSMChange
    • this is done after the user clicks 'submit' to reflect any modifications they may have made on the map, hence can not be done beforehand

Data Transformation Results

  • TODO: post sqlite databases

Data Merge Workflow

Team Approach

OSMLY was made to involve more users who don't necessarily need the technical expertise the same way previous imports have required. As such I'd like to invite some less-technical yet experienced local OSM users to help out with the import. I've created a list of users among the top contributors in Southern California by going over stats and heatmaps, and just users whose names I've noticed come up again and again while editing in the area myself. I've specifically included users who, have lots of experience in time and # of edits, seem local to or knowledgeable of Southern California, are active on a regular basis, and have some variety in editing (not just highways or buildings, etc..). Even if we only get a couple of these users to help it would be nice to get others involved. I'd like to contact them through OSM.org with a message and a link when the import is ready to go but if preferred I can try message them beforehand.

List of users: nmixter, jerjozwik, AM909, techlady, StellanL, Chris Bell in California, California Bear, Rockear, ctr112280, widesays, Brian@Brea, ponzu, dima, vvvexp97, Al Pascual, evil saltine, Sat, SimMoonXP, happy5214, DMaximus, msebast, DamienRoz, mattmaxon, RexTCA, palewire

Anything that needs to be handled more manually (QA, fix reported problems, take on more difficult objects) will be handled by Aaron Lidman. User nmixter has also offered to help as needed.

References

  • Local knowledge
  • Bing aerial imagery
  • Nearby existing OSM data

Workflow

  1. Log in to OSMLY
  2. Get a random geometry
  3. Review the surrounding area for conflicting OSM data or necessary adjustments relative to Bing aerial imagery
  4. As appropriate: edit geometry, edit tags, report a problem for follow up, open in JOSM or submit directly to OSM.
  5. Once the item has been submitted it is available for other users to confirm in QA mode.

Conflation

When preparing the data:

  1. Retrieved a custom extract of Southern California using http://extract.bbbike.org/ dated 9/26/2013
  2. Extracted each respective type (amenity=school, leisure=park) ways only, using osmfilter
    • /osmfilter la-extract.osm --keep= --keep-ways="leisure=park" > parks.osm
  3. load OSM data and import data into QGIS
  4. do a spatial query to remove overlapping data
    • GUI: "Select source features from import-parks where the feature Overlaps osm-parks"
    • Delete all items from resulting selection

At least once more, manually, by a user importing through OSMLY:

  1. When an item loads in, the surrounding data is displayed alongside the data
  2. Depending on the user's judgement they may report a problem, adjust the geometry, or upload to OSM.
  3. If a user reported a problem or skipped the item, it will have to be checked again by another user.

QA

OSMLY has a QA mode which displays data that has been imported by another user. The surrounding OSM data is downloaded and displayed on a separate layer, allowing a different user to confirm differences between the original data and uploaded data that currently exists on the OSM server. This is a quick and simple means of seeing any immediate problems.

In addition all changesets created with OSMLY create a tag unique to that import, if needed we always have the ability to go back and find anything created for this import.