https://www.openstreetmap.org/?mlat=27.10983&mlon=57.08475&z...

After first looking at the map, I was quite surprised as it wasn't mentioned in the news.

Why is a school basically located on a military area, and not in a residential area?

So, any measure that aims at keeping users engaged (as the duolingo icon for example) should be viewed cautiosly.

Also, specifically with apps with which people provide real data, the more they see it as a game, the more the system will be gamed. When users start to guess, without really confirming it on-site, this leads to outright incorrect data.

What's fine, in my book, is to make the experience more gratifying, more "fun". That's probably what you meant, with firework animation etc.. The progress bars however already fall somewhat in the former category.

By the way, edits are accepted immediately. There is no verification step by the community (just like in wikipedia), all the more important it is that people don't start seeing it as a game first and as a way to contribute to a libre map second.

Anyway, a Kotlin library I wrote uses a similar technique to make requests for the majority of locations immediate, while also handling the edge cases - i.e. when querying a location near a border.

https://github.com/westnordost/countryboundaries (also available in Rust)

What it does is to slice up the input geometry (e.g. a GeoJson) into many small cells in a raster. So, when querying for a location, one doesn't need to do point-in-polygon checks for potentially huge polygons, but just for those little slices that are in the cell one is querying for. And of course, if a country completely covers a cell, we don't even need to do any point-in-polygon check anymore. All this slicing is done in a preprocessing step, so the actual library consumes a serialized data structure that is already in this sliced-up format.

I needed it to be fast because in my app I display a lot of POIs on the map for which there is logic that is dependent on in which country/state the POI is located.

That is a fork, or rather, extension to Jetpack Compose, Google's declarative UI framework for Android. It uses Skia for rendering but has an the identical API to Jetpack Compose, hence from the point of view of a framework user, there is nothing new about it (other than that it works on Android, iOS, desktop OSs and web).

QLever: https://qlever.cs.uni-freiburg.de/osm-planet

Actually, there are two. Sophox is around for longer:

Sophox: https://sophox.org/

Both map renderers Tangram-ES and Maplibre-GL - https://github.com/tangrams/tangram-es and - https://github.com/maplibre/maplibre-gl-native are also written in C/C++.

Finally, most routing software, such as OSRM or Valhalla are written in C/C++.

There are three data types - nodes, ways and relations. All of the three can have any number of "tags" (i.e. a map), which define their semantic meaning. For example, a way with `barrier=fence` is a fence. This stuff is documented in the openstreetmap wiki.

A node is a point with a longitude and a latitude.

A way is a sequence of nodes.

A relation is a collections of any number of nodes, ways or other relations. Each member of this collection can be assigned a "role" (string). Again, the semantics of what each role means is documented in the openstreetmap wiki.

To modify data, simply new versions of the edited data are uploaded via the API.

---

The most prominent point that stands out here is that only nodes have actual geometry.

This means that...

1. to get the geometry of a way (e.g a building, a road, a landuse, ...), data users first need to get the locations of all the nodes the way references. For relations, it is even one more step.

2. in order to edit the course of a way, editors actually edit the location of the nodes of which the way consists of, not the way itself. This means (amongst other things) that the VCS history of that way does not contain such changes

The SDK is just a library, used to render vector map tiles, usually in the MVT-format: https://docs.mapbox.com/vector-tiles/specification/

Most maps rendered with such an SDK are based on OpenStreetMap data.

Will the SDK also work on iOS and Mac then, i.e. has Metal support?

Thank you for posting this and thank you all for your support! This helps me a lot to find the time to maintain the app, in general a kind of work that I think is often underestimated, also in terms of time invested.

For example, Google recently kicked the app out of their app store for spurious reasons so I had to act quickly to get it back ASAP. I kept track of the issue (and am still updating it, it's not over yet) here:

https://github.com/streetcomplete/StreetComplete/issues/2909

This may be an interesting read and shed some light on how the Google Play Store team works and handles policy violations and appeals.

See here for more information, especially for iOS programmers this might be interesting: https://github.com/streetcomplete/StreetComplete/issues/1892