Did you hear?

We plan to bring StreetComplete to iOS!

For all that have been eagerly awaiting this to happen, there is more good news, however!

Prototype Fund

I secured some funding from the Prototype Fund to work on it! 🎉

According to my estimation, this will bring us about halfway to a full port of StreetComplete to iOS, or a minimum viable product.

Now, of course, we all want the full package! Not just a prototype. Don’t we? 😀

It’s looking quite promising so far: Since I put forward this plan, numerous more contributions are being made (see project board), not to mention the many contributions towards this goal during the last years.

I hope by fully devoting myself to this endeavour for the next ~six months, we’ll gain even more momentum to finish it together!

Help Wanted!

To close the missing 50% of the way, any help is appreciated - be it code contributions, sponsoring through Patreon, Liberapay etc., (hints for) follow-up funding or even (just) help with regular issue triage and code reviews to help me focus on the iOS stuff!

If you have been considering to contribute as a software developer: Now is the time! The biggest part of this undertaking is to rewrite the UI of StreetComplete in Compose Multiplatform (a fork of Android’s Jetpack Compose). In case you know it - or would like to learn it - your help here would make the biggest difference. If you are interested to help, there are also many other small and big modular tasks that need doing. Ticket #5421 has in-depth information.

Other than the issue tracker and the OpenStreetMap forum, I linger on Slack in the channel #streetcomplete, drop by if you like.

I would like to tell you about another small project I will be working on for the next months. It is made possible by a NLNet NGI Zero Discovery grant:

Missing maxspeed

Inferring default speed limits for situations where concrete maxspeed information is missing. Last time I checked, only 12% of roads had this tagged at all and while the number of roads tagged with maxspeed of course is increasing, so is the number of roads.

Compared with highway=unclassified, it looks pretty much like a zero sum game. This means, that not only did OSM based router software always have to fill huge holes in data to produce reasonably precise ETAs (etc.), it is also not something that will get any better on a global scale in the foreseeable future.

Why so sketchy?

It’s also understandable why the data is so sketchy: Roads can simply be traced from satellite imagery. Finding speed limit signs on the other hand often requires to look for them on-site or via good Mapillary / KartaView coverage which is in itself already much more time-intensive. Not only that - it’s even more time-intensive to confirm that there is no signed speed limit for a given segment of road as the speed limit sign could be located all the way down the road. (One reason why the speed-limits quest is disabled in StreetComplete.)

Finally, if it turns out there is no sign, tagging the correct maxspeed requires knowing the traffic legislation in the country one is mapping in. (And sometimes one errs in what one thinks is correct. Did you know that the default no-speed-limits in Germany are technically are not limited to the Autobahn?)

Goal

So, the goal is to get the OSM based routing engines to use this data in order to improve the routing precision (by filling the holes in the data), but also for other modes of transportation than just cars. (Nobody maps maxspeed:hgv unless there is a sign.) Since I am not the maintainer of either of those, at least the goal is to lower the (implementation effort) bar for them a lot. We’ll see.

What I will be working on specifically in the frame of the NLNet grant is to

• review and try to complete this wiki page that (shall) contain all the legislative data regarding default speed limits I started years ago

• complete and debug this parser that was started by Ian Wagner from StadiaMaps for that wiki page that outputs an easy to parse JSON

• write a reference implementation that, given a set of tags and a country, determine the default max speeds (for the different vehicle types) using the data from that JSON. I’ll probably write

• write a small simple web tool on which to try it out

Since the reference implementation would be used by that web-based tool, I’ll probably write the reference implementation in Kotlin Multiplatform because it can be transpiled to JavaScript (for the web-tool), JVM (maybe useful for GraphHopper) and native (maybe useful for Valhalla).

State of the Map

Finally, I will also hold a talk at the State of the Map 2022 in Florence about this. I hope I have something to show until then 😅 🤞

StreetComplete v45.0 now has overlays! Finally!

You can load the alpha version from GitHub, the beta and release versions will be rolled out in a few weeks, when the bugs are ironed out. Please report any issues you find!

Overlays are a new way in which data is represented and editable on the map, additional to and orthogonal to quests: Display and edit just one aspect of OpenStreetMap, but allow it to be edited in an easy and efficient way.

Overlays help contributors to comprehensively record the kind of data that has the most value if it is mapped area-wide - for example addresses, POIs, sidewalks, cycle lanes, smoothness and other properties that are used as part of a network (e.g. for routing). In particular, overlays make it easy to identify where the information is missing and see at one glance if the information is (still) correct.

The initial version just includes two overlays to select from, “sidewalks” and “street lighting”. More will follow in the future but can also be contributed by others, just like quests, see the overlay guidelines.

street lighting overlay

sidewalk lighting overlay

Journey

You won’t believe how long of a journey it has been to reach this point. In fact, I already came up with this idea early 2020. It was actually part of my pitch for the Prototypefund project, a grant program by the German ministry of Education and Research for FOSS.

I think the first time I described it was in this ticket in January 2021, because I was seeking feedback on the idea from the community.

one of the mockups from the ticket above

Prototypefund

During the funding, I was only able to work on some technical groundwork for it, most importantly what had been released with StreetComplete v26 (Nov 2020) and v32 (May 2021). The funding through Prototypefund was over, so this topic lay bare for a while.

The changes made however, had some significant advantages on their own:

v26 changed how the OSM data was downloaded and how quests were generated. Before, each quest would do an own query to the Overpass API and place a quest pin on the map for every element that was returned. With v26 onwards, the app would download all the data directly from the OpenStreetMap API first and analyze it for quests locally on the device. Intended as one step towards the technical groundwork for overlays, it turned out as THE biggest but entirely accidental performance improvement for downloading quests…

This comparison shows something else too: The more quests exists, the slower the download, because the more is there to analyze

… and made usage of the app so much more effective that edits made per user more than doubled…

StreetComplete users and edits 2017-2021

v32 replaced the previously very quest-focussed architecture of the data flow completely. The side-effects of this were that it was now more effective to use the app when offline and the app also got a very powerful undo function. I talked about these changes on the State of the Map 2021:

Click the thumbnail to watch to the video

NLNet Fund

But I didn’t forget the original purpose why I made these huge changes to the app’s architecture. Thanks to the NLNet fund, I have been able to work on this once more. Now, also towards the end of this grant, I finally came around to finish this endeavour.

The outcome of it is now this first version of overlays. Are you curious how the overlay is defined in code? This is how it looks like. As with quests, I try to make the interface as straightforward as possible:

• street lighting source code
• sidewalks source code

MapComplete

If you don’t know MapComplete, check it out: https://mapcomplete.osm.be

So ehh, what’s the difference to MapComplete, then? In fact, the conceptual approach of overlays is very similar to MapComplete themes. From my point of view, there are the following differences:

• MapComplete doubles as a data viewer. This is a big selling point for MapComplete because it sees itself as a platform for community contributed special interest maps with an editing function. By making it easy to setup own themes, it strives to get all those “special interest” maps like the hydrant map, vegan restaurants map, beer map, table tennis map and whatever else is out there under one roof with something that is easier to set up than an own website. Plus of course, it includes an (easy) editing function, living the notion of OSM as a true wiki map

• StreetComplete overlays are more strictly curated to be most quick and efficient to use on the go, as both the overlay and quest guidelines apply. This however makes the scope of for which data overlays are suitable in StreetComplete narrower. In particular StreetComplete overlays (will) only exist for data that makes sense to update on-site, as this the app is meant to be used while on a survey only.

• MapComplete is a web-based app that necessitates being online, while StreetComplete is an Android app that works well offline and this applies to its overlays, too, of course

The End

I have now effectively dedicated more than two years of my life to more or less full-time development on StreetComplete, some time of it financed by a grant, some time of it out on my own account.

Since I have now reached my long-term goal and because the NLNet grant is soon coming to an end, I will soon need to open a new chapter in my life and end my intensive involvement in StreetComplete development in order to get a proper job.

Don’t worry, thanks to the crowd funding through liberapay, Github Sponsors and Patreon I will be able to continue to maintain the app on the side, but development will somewhat slow down of course. It is truly difficult for me to disengage from this project after such a long time to the point where it will actually be a challenge for me.

Also, not to forget the other regular and irregular contributors that continuously work on further improving the app whose names you have certainly read many times in the changelog. Certainly, and I am very happy about that, StreetComplete is one of the most active community driven OSM projects right now.