Next Steps: TerrainLayer

[chrisgervang]

Continuation of #3984

To Do List

• Fix Martini (transpile published code to es5.. with rollup [their build tool]?) See: NPM package isn't published in es5 mapbox/martini#10
• Move TerrainLayer to geo-layers

Vital Extra Credit

• Fix tile border seam line
  • Skirting?: Stitching seams mapbox/martini#7
  • Additional scale for any XY seam (wouldn't solve Z)
• Improve performance (lots of CPU bound math going on. Can it be offloaded to workers or moved to GPU?) Done: Terrain loader loaders.gl#652
• Create a website demo that doesn't utilize mapbox API (serves as a good 2nd example)
  • Could use FAA Sectional surface texture.
  • Could use US grayscale height map from wind demo.
  • Could use AWS Open Data Terrain Tiles

Feature

• Support alternative terrain loaders e.g. quantized mesh

[kylebarron]

Create a website demo that doesn't utilize mapbox API (serves as a good 2nd example)

The main non-Mapbox source of terrain tiles that I know of is AWS Open Data Terrain Tiles. Note that these use a different encoding than Mapbox's tiles (source)

elevation = (red * 256 + green + blue / 256) - 32768

You can just use this tile endpoint with no access key currently required:
https://s3.amazonaws.com/elevation-tiles-prod/terrarium/{z}/{x}/{y}.png

[Pessimistress]

Looks like Martini 0.2.0 has fixed the tranpilation issue.

[chrisgervang]

Thanks @kylebarron, I think I got the AWS source working too :)

[kylebarron]

For now this still only works with a raster satellite image texture, right? It would be awesome for it to work eventually with other vector layers, but I get that that's probably a lot of work.

[chrisgervang]

For now this still only works with a raster satellite image texture, right? It would be awesome for it to work eventually with other vector layers, but I get that that's probably a lot of work.

Yeah, only raster surface paint right now. I've gathered its pretty involved to convert the vector data to a texture. I think #3935 is discussing approaches.

[kylebarron]

Would it be possible to allow the surfaceImage (and maybe also terrainImage) prop to be a function that accepts x, y, z coordinates, not just a templated string? For example, I'm thinking of serving different imagery at different zoom levels, and a templated string is too rigid. If I had to, it looks pretty straightforward to overwrite getTiledTerrainData, but other users might also be interested in flexibility of surface image.
Nevermind, this is also easy to do with state

[kylebarron]

What would you think about letting meshMaxError also optionally being a function of the current zoom level? I.e. at low zooms I don't care about having a very accurate mesh, while at high zooms the precision is nice.

Edit: I suppose as it is, it's possible to change meshMaxError as a function of state. Though it looks like tiles would be regenerated whenever meshMaxError changes, so it seems a good idea to only change at an integer zoom threshold when a new terrain tile will be requested anyways. Something like

meshMaxError: this.state.zoom < 10 ? 20 : 10

[kylebarron]

It also appears that when panning, a significant part of the slowness is that tiles outside the current viewport are still being computed.

It appears that parse-to-image.js is being run on all those tiles. That's easy to see in the gif because all the tiles panning back to the original location are already loaded.

I'm just bringing this up because perceived performance might be better if there were a way to cancel generating tiles for areas that are no longer in the viewport.

[chrisgervang]

Just getting around to your comments, Kyle.

It depends on the use case, but for lots of fine control over the tiles I would recommend (and plan to myself) to use the layer in non-TileLayer mode by rendering many layers with absolute URLs and maintaining my own state.

Alternatively using it in TileLayer mode has a lot of extensibility options too since there are TileLayer props you can override to control loading and cacheing.

[kylebarron]

Interesting; I've found that working with TileLayer has been really helpful, so I think personally I'm going to try to work within TileLayer but potentially make some PRs to help it work better with terrain. E.g. #4397, to help TileLayer request correct extruded tiles.

I'll probably create a separate issue about the general case of cancelling getTileData for a TileLayer.