Roland Olbricht

What must be mapped to make routing for prams and wheelchairs practical? Three years ago, the local meet-up in Dortmund, Germany, started a campaign to make step-free routing available for the general public. The lessons learned mean that such routing is possible, but there is a lot missing to map - both in Dortmund and in all other parts of the world. Map the essential where fellow mappers are sparse. And codify the full ground truth where the passion allows it. I hope to encourage mappers for the quest to get their neighbourhood ready for wheelchairs, prams and all the other pedestrians!

Routing for pedestrians is a much broader challenge than the well-known car routing. Cars all over the world are mostly uniform, but pedestrians vary widely in their capabilities. This means that a lot of details that a sportive person might not even notice can be literally a roadblocker for people with prams, for wheelchair users or simply lesser-abled people with not enough strength for a complete stairway. Becoming a father has been a good opportunity to check in practice what is and what is not feasible for a pedestrian with a pushed vehicle. It turns out that the first step is to get aware of the various kinds of obstacles that get in the way. Beside the obvious steps and kerbs, there are impassable surfaces, too narrow or too steep sections. Or simply sidewalks missing completely on the ground. As of now, OpenStreetMap data does not even suffice to figure out where one or both sidewalks actually exist. This puts into perspective the discussions about how to map best details of both detached ways and sidewalks. A couple of tagging approaches are compared to allow educated guesses which level of detail will allow for good results rather in weeks and months than in years or decades. I even dare to give suggestions what tagging practices we should additionally adopt to be able to map faster. The background of this talk is an initiative from the Dortmund meet-up: For the large event Kirchentag 2019, we mapped at least the city center sufficiently well for wheelchair mapping. The whole city with its 1500 km streets has turned out to be simply too much. Given that a city with a local meet-up is in a relatively good position to be mapped, it was no surprise that also elsewhere the data is simply not yet good enough for wheelchair routing. The hope is that simple suggestions what helps is getting more traction than a sophisticated mapping hierarchy.

New processes to agree on tagging suggestions and their interaction with the editing software available on openstreetmap.org

I instead suggest to collect ideas with deadline 1st of September. I commit to present my ideas then and invite everyone to do so as well (on this list, the wiki, or the forum, other channels if known and openly available). This gives people not attending the conference better chances to get involved. That preparation ensures that we end up with one (or more) deliverables that can be worked on. This is also the reason to prefer the BoF over a panel discussion. I am unable to organize a panel discussion in a way such that it produces a deliverable. Some keywords to foster hope that there is a way forward: - Changeset discussions as a social feature have widespread acclaim - The "Any-Tag-You-Like" principle accompanies and serves OpenStreetMap since more than a decade - IETF's "Rough consensus" (RFC7282) has built the internet - many tools already facilitate to make evidence based decisions, e.g. Taginfo in general and Taginfo's [list of tag usage](https://taginfo.openstreetmap.org/keys/highway#projects)

OpenStreetMap's processes are carefully designed to minimize the privacy footprint of the mappers. Nonetheless, the principle that any edit shall be attributable means that some data is still recorded. An overview is given which data is recorded at all and which of it gets available to whom.

OpenStreetMap surveys data about places, not about persons. Thus privacy sensitive data in the geodata is very rare and always unwanted. Likewise, the principle of distributing the data allows data consumers of the geodata to stay as anonymous as they want. Mappers can contribute with pseudonyms, although not completely anonymous. However, for both the social features of OpenStreetMap and the purpose of attribution for the edited data it is necessary to collect some privacy related data. A useful starting point to see your own data footprint is the tool HDYC. All the edits you make are grouped into changesets, and the editing software will urge you to add a comment per changeset. As both the edits and the changesets carry dates it is possible to track your activity times. The nature of some edits may suggest local knowledge thus that you actually have been at the mapped places. The kind of edited objects and the mapping standards can be checked by every other contributor as well. Most often, this is simply a reason to be proud of the achievements, but you should know and check before it might get a matter of concern. Using separated accounts for different mapping tasks is often an appropriate solution and well-accepted in the community. OpenStreetMap offers additional ways to interact: you can leave comments on changesets and notes on the map, you can discuss on mailing lists or the forum, or you can answer questions on help. You can write documentation on the wiki. All of these channels have their own rules with regard to how long the data is stored, how it is searchable, and whether you can hide or delete your contributions. The talk presents the data traces of each channel and discusses strategies to get the desired degree of privacy.

Not every data item in OpenStreetMap can have an immediate impact on the rendered map. But you can make every data item visible on a map and share the links or share the data, no matter how much the item is special interest. This is the purpose of Overpass API and Overpass Turbo.

Our aim is to create special interest maps like this one for [historic street lamps](http://osmstreetlight.bplaced.net/#16/51.2339/6.7829), this one for [vehicle restrictions](http://maxheight.bplaced.net/overpass/map.html?zoom=14&lat=49.4&lon=8.68&layers=B0000000TFFTFFFFFFFF), or simply [all restaurants by cuisine](https://overpass-turbo.eu/s/I6z). An introduction to the Overpass API, to Overpass Turbo and the query language will be given. The aims are that the participants are afterwards able to filter for one for more tags, variants of tags, one or more keys, geographical regions, and combinations of such criteria. The Overpass API also supports to count objects, to dump them to GeoJSON, to retreive them in QGIS, in uMap, or a couple of [other downstream tools](https://dev.overpass-api.de/overpass-doc/en/targets/index.html). I will try my best to advance to these topics as well, but questions on the more basic issues have precedence. Thus the advanced topics are expected to rather go to an additional informal session if there are people interested in that. Please ensure that your are familar with the concepts of tags, nodes, ways, and relations, or read [an introduction here](https://dev.overpass-api.de/overpass-doc/en/preface/osm_data_model.html). You will benefit best from the workshop if you bring your own device with browser, internet access, and sufficiently large screen to view a map.

Using OpenStreetMap data almost always requires filtering for thematic extracts. Overpass API is a web service for this purpose, available at overpass-api.de. Its source code is licensed under AGPL.

The open data project OpenStreetMap aims at creating a geographic database of the entire world, i.e. collecting the data necessary to make any map of what is on the ground. Starting in 2004, it has now grown to more than a million registered mappers. In most places details are mapped including each footpath. In some places even streetlamps, trees, wastebaskets, and similar things are mapped.

Overpass API allows you to extract data by geographic search criteria, by subject, by structual properties or an arbitrary combination of them. In this way you can realize an always up-to-date data overlay on a slippy map, a desktop data browser, conveniently pull data from OpenStreetMap into QGIS, do quality assurance or a lot of other things.

In this talk I will present Overpass API by the above mentioned example use cases. Furthermore, I will give a short overview over the components and the query language. This gives you a starting point to integrate OpenStreetMap data into your application of choice.