Replace soundscape-backend with parsing of the vector tiles from the UI map server

[davecraig]

Vector tiles contain much of the same information as the GeoJSON tiles from the soundscape-backend server. This issue is to investigate what would be required to use the vector tiles instead of the soundscape-backend server. I think that although not totally straightforward, it's not impossible. It may require custom changes to tile generation tools to add intersections (and entrances?) to the max zoom tiles which by default don't always exist in vector mapping tiles.

The reason to do this would be to reduce the amount of infrastructure required to support the app which would reduce the monthly cost. This is discussed here https://scottish-tech-army.github.io/Soundscape-Android/mapping.html, and the cost of running a protomaps server which would provide both UI and tiles for audio has a cost calculator here. If we could make this work, then the ongoing server cost would be very small indeed.

[davecraig]

Some work has been done here in unit tests to demonstrate whether or not it is actually possible. See VectorTileTest in the code.

[davecraig]

This has progressed significantly. The server has been updated with new maps which have OSM ids for every road in the transportation layer. This means that de-duplication is now being accurately done. Remaining work:

• [ ] Join up lines in GeoJSON at tile boundaries. We currently have an overlap in lines at tile boundaries. This is probably okay for the audio callouts but may interfere with street preview behaviour. Matching lines and then joining their last 'on tile' nodes together shouldn't be too hard from an algorithm perspective. However, the current behaviour is that the tiles are converted and then written to the database. If the data changes as adjacent tiles are downloaded how do we not update the database? Perhaps the solution is simply to truncate all of the lines at the tile boundary. When new tiles are downloaded the result would be two unlinked nodes very close together for lines that cross the tile boundary. It may be easier to deal with that in the algorithms that look at the data, especially if we mark the node as being a tile boundary generated node. Lines which wiggle around a tile boundary make doing this trickier as every other point on a road could be on a different tile, but still within the buffer region. The algorithm should still work though.
• [ ] Check what's required for roundabouts
• [ ] Improve the mapping of MVT to soundscape-backend to ensure that the GeoJSON is interchangable.

[davecraig]

The changes I've made to adjust the map that we use are now here: https://github.com/davecraig/planetiler-openmaptiles. I'll move this to be an STA owned repo at some point. It's built by running scripts/build.sh and then the result can be used to build a protomaps file e.g.

java -Xmx30g -jar ../target/planetiler-openmaptiles-3.15.1-SNAPSHOT-with-deps.jar --force --area=europe --downl
oad --fetch-wikidata --output=map-to-serve/europe.pmtiles --nodemap-type=array --storage=mmap --maxzoom=15 --re
nder_maxzoom=15 --simplify-tolerance-at-max-zoom=0