Readit NewsDoes anyone have hands-on experience?
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<string, string>), 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?
[0] https://liberapay.com/westnordost
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.
And of course with edge cases, there are lots of them but mostly it's fine. One case that comes to mind is that of the border town of Baarle-Nassau On the border with the Netherlands and Belgium. This village has some of the weirdest borders in the world. There are Belgian exclaves inside Dutch enclaves. In some cases the border runs through houses and you can enter in one country and leave in another. Some of the exclaves are just a few meters. There are a few more examples like this around the world.
Another issue is the fractal nature of polygons. I once found a polygon for New Zealand that was around 200MB that broke my attempts to index it. This doesn't matter of course for resolving country codes because it is an island. But it's a reason I implemented the Douglas Peucker algorithm to simplify the polygon mentioned in the article at some point.
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.