Cesium Polylines

[josephbirkner]

Fixes #37
Fixes #34

What changed? The FeatureLayerRenderer now outputs Cesium Primitive objects rather than GLTF blobs. This allows us to extensively use the existing Cesium styling options via Primitives and Appearances: https://cesium.com/learn/cesiumjs-learn/cesiumjs-geometry-appearances/

How to test? (KE): These changes are currently best tested with a GeoJSON datasource based on a directory of exported NDS.Classic tiles. Step-by-step:

• If you don't have a GeoJSON folder ready, download the tiles from here.
  • Use the "Routing JSON Export Password" from KE-Shared to unpack the archive.
• In Erdblick, check out this branch feature/polylines and run ./ci/20_linux_rebuild.bash.
• In your local clone of mapget-datasource-live, check out main.
• With your local build of mapget-datasource-live, run ./livesource-server -p 8999 geojson --source-dir path/to/routing-json-export --with-attr-layers false. This will launch the livesource in geojson mode on port 8999. The --with-attr-layers false makes the performance more akin to what can be expected with staged loading.
• With mapviewer or mapget project, run ./mapget serve -p 8089 -d 127.0.0.1:8999 -w "path/to/erdblick/build".

TODO:

• Read width from style
• Documentation
• Fix Picking
• Ensure that test works

[josephbirkner]

@MisterGC I implemented a basic parsing queue to not overload the browsers own microtask queue, so tiles now appear as they are loaded. I also made sure that the memory consumption for the 512-tile munich viewport is generally under 600MB.

[l-laura]

Tested on Firefox, some observations:

1. Shortly after startup, a few errors are logged from fetch.js:117:

There has been a problem with your fetch operation: undefined

2. Saw this one time, probably not a big issue, but just mentioning:

Uncaught (in promise) TypeError: inputData is null
    uint8ArrayToWasm http://localhost:8089/erdblick/wasm.js:27
    peek http://localhost:8089/erdblick/features.js:80
    render http://localhost:8089/erdblick/features.js:51
    renderTileLayer http://localhost:8089/erdblick/model.js:217
    addTileLayer http://localhost:8089/erdblick/model.js:209
    setTimeout handler*addTileLayer http://localhost:8089/erdblick/model.js:208
    ErdblickModel http://localhost:8089/erdblick/model.js:51
    __emval_call http://localhost:8089/libs/core/erdblick-core.js:4607
    TileLayerParser$parseFromStream http://localhost:8089/libs/core/erdblick-core.js line 3961 > Function:9
    processTileStream http://localhost:8089/erdblick/model.js:90
    processTileStream http://localhost:8089/erdblick/model.js:94

3. Some XHR requests to openstreetmap.org result in 418 I'm a teapot. Not a priority, but... what?

Main functionality worked as intended (line width, colors, filtering) and requested changes are cosmetic, so I approve 👍

[josephbirkner]

Thanks for pointing out the console logs/errors @l-laura 🙏

[MisterGC]

Summary: This review focused on stability and performance from user perspective. It is fine for now, to enable people to do tests and make later more scalability tests. But my feeling is that we need to further optimize performance, because of the addition of rule-based styling, even if we have staged loading (e.g. detailed attribute layers get loaded delayed).

What and how have a I tested?

• Tested with data fetched from a source as well as cached data
• view ports containing ~20 - ~500 lvl 13 tiles
• continuous viewport changes as well as
• chang viewport with selected elements
• used several sessions
• Firefox and Safari, on macOS and Linux
• interaction time was about 10min but I also kept the mapviewer open for multiple hours
• I haven't investigated the implementation in this review, as we have also a discussion about a former intermediate state

Results:

• Memory peaks were about ~1.8 GB
• With an intermediate version I got a crash, with this version not
• most of the times I get visual feedback quickly
• sometimes it takes a long time
• seldom seems to not update at all
• with a 500 tiles viewport I measured ~60ms/tile when using the (in memory) cache