Add in NetTolpologySuite experimental renderer

[memsom]

This code is semi working (it renders the tile at {0,0} at zoom level 0. However, it is absolutely not ready for anything and is just a POC.

I will leave it in a branch till it matures.

[memsom]

This now has an example that can render the map tile from {0,0} at zoom level 0 using Avalonia UI. I think my next steps are:

1. render another tile and inset it to see if it is rendered correctly
2. look at how easily I can get the tiles to render on to a raster image to recreate what the AliFlux version does.

Both approaches have merit. The latter will give something like the AliFlux implementation. The former might make for an interesting tech demo if we can get all the features to render relative to their actual position in space.

At the moment I haven't looked at whether all the Tiles end up rendering relative to a Tile or relative to their actual geographical position. Knowing which one will help shape the development I think.

[memsom]

Okay, it appears that the Y axis is inverted in the data. It also appears that the data that NTS produces is complete and will render the map exactly in space.

Next hurdle is working out how to handle the tiles at different zoom levels.

[memsom]

I just pushed more code. This has made the map render in the correct scale (though it is still only the 4 tiles from zoom level 1). There are definitely rendering issues as the boundaries are pretty jagged.

Top part is rendered from the vector data, bottom part is from the raster tiles. Weirdly, we seem to still get labels even though the tiles that they are contained in ar not rendered. I think that might be a quirk of the way the tiles are being generated by NTS, but not 100% sure.

[charlenni]

Ok, I now understand, that you are trying to read vector tiles. I didn't know, that NTS has a reader for such vector tiles.

Perhaps some informations about storage are helpfull. You often have not all tiles for a given region in the file. Normally they go from zoom level 0 to 14, but you could zoom in to zoom level 24 or higher. So you need in some cases only parts of the tiles to display. Also the other way around. You could zoom in in parts, that are not contained in the file and zoom level you want. In your zurich.mbtiles file there are tiles for Zürich in zoom level 14, but not for the whole Switzerland. So you have to use a part of the tile in a lower zoom level to display parts outside with zoom level 14. This is a little tricky.

One more problem for me was the word "Layer". This is used in different places. Your vector data contains layers with names like "park" or "landcover". Additionally the features inside of this layers contain tags, specifing the feature. Beside this, you have your style.json file, which contains style layers. Each of this style layers belong to a layer-tag-combination of the mbtiles file. There could be more than one style for each layer. E.g. MapBox create streets by drawing them with two styles: the first is a thicker line for the border, where the second style defines the style for the inner part, which is drawn abouve the first part.

When you draw the features, the style file is the leading one. From style file (normally around 100 different style layers) you take the first style, find the layer for this style and find all features with the right tags to which this style belongs (reason for filter). That is giving you a number of features, that should be drawn with this style. If you have done this, you take the next style, collect the right layer, find needed features and draw them. And so on.

What takes time in this process is the filter. There are features on a layer, that are only shown at zoom level 15 and above, but also features that are only shown at zoom level 16 and above. So best is to devide the process into two steps: rendering, where the features for each style layer are selected and a second one to draw this features.

What you get with the NTS package is the possibility to read different tiles. Around this you need now the possibility to get to a tile, that isn't in the database a part of a tile from a zoom level above. E.g. your file has the tiles (0,0,1), (0,1,1), (1,0,1) but no (1,1,1). For this, you have to extract the missing part from tile (0,0,0). I didn't find a possibility to connect the features from the (0,0,0) to e.g. (0,0,1). There must be one, because same streets should be connected (no steps and for street names).

[charlenni]

One more thing you should keep in mind: MapBox uses two different styling things: layout and paint. Layout is calculated for integer zoom levels. It is checked e.g. for zoom level 13, 14, 15. Paint could change in between zoom levels and the style could be different for 13.3 to 13.4. What AliFlux's renderer does is, to calculate layout and paint only for integer zoom levels. Advantage is, that you only have to create a tile for each integer zoom level (bitmap or picture), that could be drawn for all the different zoom levels between this and the next. That said, it is not possible to make a correct MapBox tile with an SKPicture. It is a vector format, but couldn't change while zooming.

[memsom]

@charlenni yes, this is all going to take some work. I managed to get Mapsui to render (very slowly) the layers by brute forcing it. The code now reads all the tiles and pushes them all to the MemoryLayer but sets visibility to the resolution of the zoom level. It "works". I think optimising it to only provide the tiles in view might work better. We certainly need a better renderer for this to work smoothly. Because this the tiles are being rendered with an artificial border at the moment, you can see the tiles changing as the zoom level changes. So - it all would work if the renderer could keep up with the requests. I wonder if a hybrid of the way the MbTiles layer works would be possible? As in how it requests the tiles, not the rendering. Not sure yet.

I'm absolutely not saying this is the approach that will yield a quick win, but it got quite far fairly quickly with minimal effort. If the renderer was faster, it would almost work. The rest of the rendering is a case of picking what to render from the style data and applying that to the next render of the tile.

I think I would create an AliFlux style renderer using what I have now. That would at least hopefully fix some of the rendering issues AliFlux has without having to wade through that code.

I still want to look at MapLibre Native and similar options to see if it is possible to pull them in and create a compatible drop in renderer. My aim is to get something that can actually do a decent enough job in production.

[memsom]

The "layers" is confusing, yes. I think this is the layers in the vector vs the layers in the map, and I don't have a good solution yet.

[charlenni]

I assume, that there are 3 different layers: One is the layer in the vector data, one is a style layer and both together give a layer in the map. You could add all the vector data and styles into one Mapsui layer. Or you could create for each style layer of the style file an extra layer in Mapsui. The later would have a tile source together.

So you have to decide, if you have one vector tile source for a Mapsui TileLayer and inside of this layer the different style layers or if you have one vector tile source with different TileLayers, one for each style layer.

And have in mind, that if you want to make it good, you should have one or more layers for the labels and symbols.

[memsom]

I will be parking this for now

[charlenni]

I found another problem in the NTS reader: If you have (against winding order) a CCW outer ring, then the inner rings (holes) are not handled correctly. I changed this and made a PR (see here). With this, the tile (0,0,0) wit osm-liberty style looks like

[charlenni]

Btw. if you don't use the NTS reader without this PR, you get this image