Comment by closedcontour | Hacker News Reader

Comment by closedcontour | Hacker News Reader

Parent Full thread

Thanks! Happy to answer questions.

First, about the attribution: there's a small "Attribution" section in the About page, but it's all data I sourced directly from US gov sites. I actively wanted to avoid an attribution on the actual map page.

It is a bespoke rendering implementation, there are a few details in my original comment[1], but I'll add here that it does use three.js. I haven't used any three.js competitors but I love the level of abstraction it provides: high-level enough to get things done quickly and low-level enough that you can get right into the shaders if you need to.

Camera positioning turned out to be a little easier than I had feared. Up front, I'll say that I didn't do anything for avoiding the track being obscured by terrain. There are times, especially when descending a steep face, where the track does gets obscured.

The camera path itself is generated quite simply: I take a GPS sample every half mile (or as near as possible) and then create a 3D Catmull-Rom curve[2] from those points; that becomes the position track of the camera. Camera orientation is set to look at the current point. There are some offset tweaks here and there so that the camera leads the track (camera turns before the track does).

[1] - https://news.ycombinator.com/item?id=32001821 [2] - https://threejs.org/docs/index.html?q=cat#api/en/extras/curv...

Appreciate the response.

One thing I've struggled with in threejs is what coordinate system to use when pulling in data sources. Obviously UTM and lat/lon are inappropriate when you're dealing with a slice of terrain in 3d like this, and from my experience using the 1x1 unit tile dimensions of something like a web maps tile coordinate system does not play nice with ThreeJS at all.

Do you just project to Mercator/Web Mercator and then arbitrarily pick something like 1km = 1000 units to work with the data in ThreeJS space, or is there some kind of an established coordinate transform that is commonly used when bringing geospatial data into a non-projected xyz coordinate system?

I've done this two ways:

(1) Tile the world in lat/lng. For each tile, turn it into a NxN grid of lat/lngs within the bounds of the tile. Convert each lat/lng/height (where height comes from your DEM) into ECEF XYZ. Texture map imagery onto this mesh.

This works well for a true "globe" but there is plenty of complexity in which tiles and in what detail to load, how well they stitch together (seams), etc.

(2) For the SPS2022 case, I went way simpler. The tile scheme is web mercator (just a plane), where I precalculate which tiles are going into the scene (no loading/unloading logic necessary). Each tile still has a lattice of points, but I simply set the z-value to the height (corrected for Mercator distortion). Then I put part of a sphere over this plane for the atmosphere.

In either case, you will need to be careful about precision issues because ECEF and web mercator coordinates don't really fit in 32-bit floats, although it's close enough if you aren't zooming in too far. You can kind of work around this in three.js by careful usage of the position property of your meshes. Those matrixes get combined in three.js in javascript with doubles.

This is super impressive, especially the rendering. I hope you guys make a version for the Appalachian Trail! That would be wonderfully useful.

Reply on news.ycombinator.com