Import/Vienna Dropped Kerbs
This page is under construction!
This page describes the intended import of dropped kerb data in the city of Vienna.
The objective of this import is to enable routing applications to take into account the special needs of disabled people such as e.g. wheelchair users. The existence of dropped kerbs and their heights will decide where they can safely traverse streets and crossings.
About
The data discussed here for integration into OSM is based on the original OGD data from the City of Vienna, as provided in the Vienna OGD portal under "Gehsteigabsenkung - Wien".
The data discussed here for integration into OSM has been promoted and generated within the European project CAP4Access.
This project has the objective of supporting mobility-impaired persons, such as wheelchair users or people with walking frames or rolling walkers, by providing crowdsourced information about the accessibility of places. It also develops routing and navigation aids that match available accessibility-relevant data regarding streets and sidewalks with capability profiles of mobility-impaired persons. This wiki is about making original point data of dropped kerbs available in OSM so that OSM-based routing and navigation algorithms developed within the CAP4Access project as well as possible successors can utilize these data adequately. The original dropped kerb data set is part of Open Government Data of the City of Vienna, which is one of the pilot sites of CAP4Access. This official open data set of some 30.000 points covers the whole City of Vienna, and as empirical tests have shown - it seems to be rather complete. Every record of the dropped kerb data set provides two pieces of information: the position of a dropped kerb defined by its geographic coordinates and the height of the kerb at that point, measured in one of three values: 0, 3, or 5 cm.
somewhere here a picture with the yellow pins on google Vienna map.
At a first glance, one might think that is would just be fine to import the dropped kerbs just as the points that are provided in the original OGD dataset. The complication that arose is based on the following consideration: OSM Routing algorithms must take into account the navigable set of streets, or ways in general, and their interconnections. A geographical point, representing a dropped kerb, as given by the OGD data set, must somehow be matched to the correct street that it makes passable. As streets or ways in OSM are just dimensionless lines, finding correct matches is not that easy, and may get complicated more for complex crossings.
somewhere here image with complex crossing from poster
An example shall illustrate this issue. On the aerial image below, several pins represent the dropped kerbs at a crossing. Looking at this photo, the locations of the pins seem to make sense in terms of which sidewalk they allow entry to. They usually come “in pairs” facing each other at opposite sides of a street. Now have a look at the overlaid graphic showing the situation in OSM where streets and ways are modelled only as thin lines in the map’s internal database, shown by the blue lines in the graphic. The green stars in the graphic represent the dropped kerb points with the same coordinates as those in the aerial image. Now, forget what you know from the aerial image and try to match the green stars to the “their” skinny blue lines, or streets. That is not easy anymore! You will probably find several points hard to assign to one single street.
Import Plan Outline
Goals
Identify the goals of the import.
Schedule
Be sure to list the general timeframe of your project.
Import Data
Background
Provide links to your sources.
Data source site: http://website.tld
Data license: https://website.tld/license
Type of license (if applicable): e.g. CC-BY-SA, Public Domain, Public Domain with Attribution, etc.
Link to permission (if required): e.g. link to mail list reference url - http://lists.openstreetmap.org/pipermail/imports/2012-December/001617.html
OSM attribution (if required): http://wiki.openstreetmap.org/wiki/Contributors#yourdataprovider
ODbL Compliance verified: yes/no
OSM Data Files
Link to your source data files that you have prepared for the import - e.g. the .osm files you have derived from the data sources.
Import Type
Identify if this is a one-time or recurring import and whether you'll be doing it with automated scripts, etc.
Identify what method will be used for entering the imported data into the OSM database - e.g. API, JOSM, upload.py, etc.
Data Preparation
Data Reduction & Simplification
Describe your plans, if any, to reduce the amount of data you'll need to import.
Examples of this include removing information that is already contained in OSM or simplifying shapefiles.
Tagging Plans
Describe your plan for mapping source attributes to OSM tags.
Changeset Tags
Describe how you'll use changeset tags in the import.
Data Transformation
Describe the transformations you'll need to conduct, the tools you're using, and any specific configurations or code that will be used in the transformation.
Data Transformation Results
Post a link to your OSM XML files.
Data Merge Workflow
Team Approach
Describe if you'll be doing this solo or as a team.
References
List all factors that will be evaluated in the import.
Workflow
Detail the steps you'll take during the actual import.
Information to include:
- Step by step instructions
- Changeset size policy
- Revert plans
Conflation
Identify your approach to conflation here.
QA
Add your QA plan here.