Ilya Zverev

Let's look away from familiar continents and comfortable symbolics. When you are making an entirely new world, how do you map it? When any choice can be made from scratch, why game makers sometimes use common carthographic paradigms, or circumvent them? And given we are at a GIS conference, what can we learn from imaginary maps, that can improve our real-world work? Let's connect a Nintendo Switch to a projector and dive into games!

None

This talk is exactly what it says on the tin: I want to extract restaurants or shops or train stations from OpenStreetMap. Or every POI there is. How do I do that and why extraction is so damn hard? This talk is not exactly a one-two-click instruction: we will see how data gets into OSM and why it is not easy to get it out.

None

OpenStreetMap is a collector's dream. While there is a finite set of stamps or coins, there are millions of shops and beauty salons, and new ones are opened every day. Yay, collect them all for the map! (And make the map better in the process, of course.) Alas, this task was made tedious, virtually impossible by our current tools. Not as much for adding — but for updating the data we've already collected, and finding what's missing. I've talked many times of this problem, and this year I think I've fixed it. This year changes everything for how POI are handled in OpenStreetMap.

Last year I presented the idea of making cartography apps without a map for the central UI element. And added a couple drawings of a better editor for POI. Well, it is finally out there, and hundreds of mappers have already surveyed... a lot. So one part of this talk is a typical OSM editor talk: I'll walk you through the design decisions, show some statistics, and elaborate on how writing a new OSM editor is akin to writing a new browser these days: an enormous task, but with a lot of open source code at hand. But what is different, is that this editor is not a toy and not a general-purpose tool. It is very focused (well, on three things at once, but still). Meaning, you don't play with the map in it, and don't get lost in menus. You survey. Lots and lots and lots of shops and amenities are going to get added or confirmed. This editor does not just "allow" anything. It changes the landscape of OpenStreetMap. Before it shops were an afterthought — now people would seriously consider using OSM for searching. Here's where my experience in working with commercial places data comes in handy. Let's see what can we get out of this, and why "fun" is still as important in OSM mapping as always.

In this talk I show the app that I've made in two months while learning the Flutter framework. It was built on open data and open source libraries. But what separates it from the rest is not code - but experience. Maps on mobile screens are hard to do properly, and there's always a temptation to add another screen, another button. Turns out you need a bit more than skills to make a perfect app: at least you need to use it daily.

Last year I moved to Tallinn, Estonia, which is known also by it's public transport system - free for city residents. It is so good, reliable and optimized, that I sold my car and use buses and trams exclusively for all my city travels.

While planning a transit route is pretty straightforward with an official website, usually I need some transit-related information on the go. On a phone. And that's where both the website and many big and small apps show their imperfections. Download sizes, ads, user interface. Instead of focusing on my problems, I have to learn and work around apps' issues.

As an open source developer, that seemed not an issue - but a challenge. I've made interactive maps for the past ten years, and I know one should not use these libraries with default settings. Nor one should ever rely on zooming. Could I made a map with apps that doesn't require more than a couple of taps to get all the needed information? How hard would it be to keep number of buttons and other interactive elements to minimum, while not sacrificing functions I need every day?

The common theme for OSM editors is presenting a map for moving things around. But for attribute editing, a map is too distracting. Let's see how getting rid of it improves the editing experience.

The future of OpenStreetMap editing is not another JOSM or another Potlatch. What we have is good enough, and there are options for everyone. But 15 years on, the same problems persist in OSM: while it's very easy to draw things, to add a road, a building, or an amenity, updating the map is so hard virtually nobody does that for free. That can only be fixed by tailoring editors to the task, because general-purpose editors cannot help. That is the future: thematic editors. In this talk we'll take a look at existing specialized OSM editors, like OSM Contributor, MapSwipe (I know), or StreetComplete. We will also note when an editor doesn't need a map to operate. And finally we'll imagine a few editors that could simplify maintaining the map, both on desktop and on mobile. The speaker, Ilya Zverev, has made the well-known Level0 editor which doesn't need a map to function, but also isn't strictly a thematic editor. Recently he's made a Telegram bot for a POI directory, which also featured an optimized POI editor. It enabled Ilya to collect ~500 shops and amenities in 10 days, and to keep the data recent. It didn't provide an interactive map, obviously.

After moving to Minsk, I pondered on making a local map for my neighbourhood, with all the shops and amenities. People would visit it on the web and see where are things. Two years passed, I didn't make it. And only in December I've got an idea that would work. A community does not need no maps. What it needs is conversation. So I made a map app 2.0: one that doesn't rely on 1) web, 2) maps. Of course inside it's all about geo.

Want a postcard? Looking for somebody to send a postcard to? Me too! Let's discuss how people in OpenStreetMap come together, which pleasant and otherwise experiences we had meeting other mappers, and how to express gratitude and make people feel a bit closer to each other — with postcards.

Each time I visit a SotM conference far from home, I'm collecting postal addresses from everyone who follows my news channel. And I send postcards: "Hello from Aizuwakamatsu!" We rely on digital too much: nothing we can touch, nothing we can put on a shelf. Virtual maps, virtual gratitude. With this project, OSM postcrossing, I plan to give every mapper a chance to have something tangible as an outcome of participating in our project. But to get there, we must think of what brings us here, and what experiences we have as members of the community. The premise is simple: ask somebody for their postal address. Except people are reluctant to give it: the address is a private information, and privacy is important. Have you tried to upload a gpx trace, to see how we value it? A lot. So what do you do? Do you send a postcard to a random mapper? Do you publish your address for everyone to see? Should you stay back from the official real-world services and back away to the comfort of virtuality?

Having seen a dozen of different OpenStreetMap-based geocoders, I did not expect to find myself writing another one. But here I am, tasked with making a reverse geocoder better than the industry-standard Nominatim. Turns out it is a fun and not so straightforward task. Let’s see what can go wrong.

Our data model is impractical. You know that. Even OGC Simple Features are better. Changesets and versions promised easier reverting — is it simple yet? We have added a lot of features to API 0.6 over the past ten years, but should we have? Let's see what went wrong and what we can improve.

People often come to me saying, changesets with huge bounding boxes are impossible to validate. Come on. You know changesets were not meant to group edits by any criteria. Developers look at the data model and derive user experience from it — and it obviously does not work. Every instance of OSM data needs to be preprocessed, converted, filtered, layered, postprocessed and thrown away. We need to stop looking at OSM as a database and start treating it like a map. In this talk I will highlight what's wrong with the current state of API, including both the actual REST API and the server side. Things like topology, notes, GPX traces and stuff: they were coded when the project was small, but the model starts to show its age — and few people know what to do, besides adding more mappers. How come Overpass API became the better API, and what can we learn from it? Changesets should be abandoned by user-facing tools: let's imagine how the mapping, the validation, the undoing of changes would work if we didn't rely on changesets or actually anything API provides. Can we do something to improve data quality right now? Or can we work towards API 0.7, that would help keep the map not only the most complete, but also the most recent? Let's take a step back and imagine how OpenStreetMap should have been working, to make it more fun to work with, while keeping its versatility and simplicity. I have been involved in a couple API 0.7 discussions, made a few tagging proposals and wrote an editor and a change rollback script. That doesn't make me an expert — there are no experts in OpenStreetMap — but it gave me some ideas on how things could be better. Maybe together we will have a clearer path towards the better OpenStreetMap.

Lightning Talks

## Human in the Loop: Verifying Machine-Generated Data for Better Maps Said Turksever

Machine-generated map data has the potential to considerably accelerate mapping at scale. Combining it with human review helps ensure high data quality. We’ll show how a simple game-based tool helps verify the map data generated by Mapillary’s AI, and how that data helps enhance OpenStreetMap.

## Share the word Ilya Zverev

WeeklyOSM is great, but is it the only channel for following news in OpenStreetMap? For most countries, yes. And that is sad. You can change it for the better: start a blog, record a podcast, tweet something. Here I will share my experience at keeping OSM community informed.

## Enhancing OSM with missing roads Beata Tautan-Jancso

ImproveOSM is a powerful tool that detects and highlights areas in OSM where roads, one-way attributes, and turn restrictions are missing from the map. The first version of the JOSM plugin was released in 2015. Since then, the community has improved almost 200.000 areas with missing roads.

## Community led mapping helping in policy changes Sibabrata Choudhury

Beginning of 2015 a process of community consultation and community led advocacy in the eastern state of India has resulted in several communities developing maps of their plots which has been a breakthrough experience.

## How to create a data annotation process used for navigation Alina Negreanu

In this talk, the Telenav OpenTerra team will present how they built their data annotation team and the processes they developed in order to assure high-quality annotations, on which their AI algorithms heavily rely on. They will talk about good practices to use when building manual datasets and the hurdles they had to overcome in order to reach their quality requirements, having so far reached more than 600 000 annotations.

Other people: Alina Negreanu Sibabrata Choudhury Beata Tautan-Jancso Said Turksever

Lightning Talks

## OpenStreetMap intrinsic quality assessment using “Is OSM up-to-date?” web application Marco Minghini and Francesco Frassinelli

Approaches to analyze OpenStreetMap (OSM) intrinsically, i.e. based on the history of data, have become an established way to achieve a wide range of final goals, most importantly to study its quality. Started in 2017, “Is OSM up-to-date?” is an open source web application licensed under AGPL and mainly written in Python. It can be also run in the command line or inside a Docker container. The target beneficiaries of the software are OSM users and communities, who need to assess the quality of data in a given area to decide whether to use it or not as well as where mapping efforts should be best directed, and OSM researchers and scholars, who can use it as a tool to help in their OSM quality studies. The project has a dedicated wiki page (https://wiki.openstreetmap.org/wiki/Is_OSM_up-to-date), source code is hosted on GitHub (https://github.com/frafra/is-osm-uptodate) and a demo is available at https://is-osm-uptodate.frafra.eu. Using the OSM API, the web application generates history-based, quality-oriented visualizations of OSM nodes and ways having at least one tag for any rectangular user-selected region. Such visualizations (on top of a grayscale OSM basemap) are available for the following criteria: date of creation, date of last edit, number of versions, number of different contributors who edited that node or way, and frequency of update. When an OSM node or way is clicked, a popup shows its values for the previously mentioned criteria as well as the list of currently available tags and the links to the OSM iD editor (in edit mode on that node or way), history and details of that node or way (both linked to the OSM website). A number of additional features to further improve the analysis of quality is currently planned (see https://github.com/frafra/is-osm-uptodate/labels/enhancement).

## Deriviste - Click and Go Photo Mapping Christopher Beddow

There are many OSM editing tools, but only one that allows the user to click inside a Mapillary image to add new data to the map. Richard Fairhurst's Deriviste tool was a quick experiment that proved this was possible, but it's important to ask more questions. How useful is the tool? How accurate and precise is it? How can it be improved?

## Fifty states in 12 years and five minutes Minh Nguyễn

A whirlwind historical tour of the OpenStreetMap project in the United States.

## "MAPAbabae": Using OSM as a Tool for Mapping with Women and For Women Andi Tabinas, Arnalie Vicario

We would like to share how we, as part of the Social Welfare and Development agency of the Philippines (DSWD), have utilized OSM to have a collaborative and gender-inclusive approach of mapping points of interests catering to women.

## Reverse Geocoding Is Not Simple Ilya Zverev

Having seen a dozen of different geocoders, I did not expect to find myself writing another one. But here I am, tasked with making a reverse geocoder better than the industry-standard Nominatim. Turns out it is a fun and not so straightforward task. Let’s see what can go wrong.

Other people: Arnalie Vicario Andi Tabinas Minh Nguyễn Christopher Beddow Marco Minghini

We at Juno track a massive fleet of taxi cars in a relatively small area of New York. For all the internal mapping we use OpenStreetMap — and we are naturally interested in it having zero road errors. One way to ensure that is to validate it against tens of thousands GPS traces we get every day. In this talk we'll look at the relation of traces and map data in OSM, find a few ways to improve OSM using these traces, and see the validation system we made.

The first subway station was mapped in OpenStreetMap eleven years ago. Since then, people have been adding station and routes in each of 170 cities with subway or light rail systems. But only a few months ago the mapped routes were first used for routing. Unsurprisingly, the quality of data was bad. In this talk Ilya will explain the subway mapping principles, show common errors, talk about the community's reaction to tidying up metro systems, and present the tool to extract metro routes from OSM into easy-to-use data structures, which is used for the MAPS.ME application.

Last April OpenStreetMap got a new open-source editor: MAPS.ME. It was a first popular editing application both for iOS and Android phones, with millions of users. Suddenly a quarter of daily editors were maps.me users, who behaved quite differently from regular, hardcore mappers. This talk explains how we made editing OpenStreetMap possible offline, without an access to the constantly updating database, how we and our users repeatedly broke OSM data, and which tools and algorithms there are for fixing the map.

OpenStreetMap project has a lot of editing applications for every system. Experienced mappers edit in JOSM and Vespucci, amateurs use iD and Go Map, novices... A sad thing is, there are no simple editors, because OSM data model is not simple. And on mobile devices, the situation worsens, because the quality of a user interface becomes crucial. In this talk, Ilya Zverev would present the state of OSM editing on mobile devices, and how MAPS.ME set off to build a perfect and open map editor for non-mappers, attracting thousands to improve OpenStreetMap.