127 karma · joined July 6, 2022
Now that Nathan is done with his effort, he'll be loaning his inReach to Ashly Winchester during her FKT attempt on the John Muir Trail starting tomorrow and the submitted link will show that.
After she is done with her effort, I'll redirect to Travis' tracker.
And after that, I'll leave a note on the page.
One way of looking at is that these guys have been moving 12 +/- hours a day in the mountains for a few months now and they've covered just over 2 miles of the ridge in 10 hours today so it better be pretty hard!
[1] - https://www.pullharder.org/trip-reports/2012/07/02/full-pali... is a good account of this climb with some nice photos. [2] - https://en.wikipedia.org/wiki/Yosemite_Decimal_System
(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.
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...
If you get into more specific areas you can generally find higher resolution data.
Good luck.
Today, Wed, July 6: A five-peak, north-to-south traverse of the southern Palisades: Palisade Crest, Norman Clyde, Middle Palisade, Disappointment, and Thumb.
Tomorrow, Thurs, July 7: A seven-peak south-to-north traverse of the northern Palisades: Temple Crag, Gayley, Sill, North Palisade, Thunderbolt, Winchell, and Agassiz.
While the project is ongoing (probably another month or so), it'll just be for the climbers. But, yes, when they are done I intend to release something that will allow anyone to put their own Strava activities on it. One huge caveat, and one of the main down sides of rolling my own mapping tech, is that I've only processed imagery and elevation data for the Sierra Nevada region.
They are now on a narrow, somewhat technical ridgeline, so a few things will accumulate into some annoying errors:
- the quality of the digital elevation model (DEM) isn't great in the Sierra Nevada (new data is slated to be captured this year, though!)
- the overheard imagery is okay (0.6m), but not amazing
- they will likely be hopping from side to side on the ridge, blocking sky view and making GPS quality decrease and frequency of updates decrease
We have captured a ton of video of the project and they've done a bunch of amazing lines. Hopefully we can put together a few good videos coming out of this.
Oh, how I wish it was automatic! I have a script that pulls EXIF data out of the photos and initially places them in the scene but then I manually rectify it. In fact, all the keyboard shortcuts are still there if you want to see the process. Select a photo then play with these keys:
B (toggle white background), 1-5 (image opacity), QEWSAD (camera orientation), HNIKJL (camera position), [] (camera FOV), and / (console.log the variables). Shift does smaller increments.
In theory, the iPhone has enough metadata to make a decent first guess (GPS, phone orientation, and compass direction). In practice, that wouldn't be enough to do it automatically, you'd have to do some sort of additional fitting. Video and photo georegistration is an important problem in many domains with active research -- perhaps some day this will trickle down into a library I could use.
While I hope you'll find the whole site interesting[1], the part most likely of interest to this community is the interactive 3D live tracking (the main link) and activity playback[2]. Here's a post describing its capabilities/controls[3].
I rolled my own 3D terrain renderer based on open aerial data (USDA NAIP), elevation data (USGS NED), and named locations (USGS BGN). A few points of difference from what you might see from Google, Mapbox, or Cesium:
- Fixed scene size. The scene is only big enough to capture the area of interest (the track) plus some contextual buffer.
- No incremental loading. This was the motivation behind the fixed scene size… once the imagery and elevation model are loaded, the scene runs at 60fps on just about any device. I want it to feel _fast_ and terrain, imagery, or feature data loading and unloading breaks that feeling.
- Compressed textures for imagery. In order to successfully load some of the larger scenes and to reduce imagery file sizes, I use basis_universal[4] texture compression. It's perfect for this sort of imagery: the reduced quality isn't too discernable and you get 8:1 reduction in on-GPU memory usage against standard RGBA images.
- Hand coded DEM compression. I hand rolled a DEM compression algorithm based on the ideas behind QOI[5]. It turned out to hardly be necessary because the poor quality of DEMs available in the Sierra Nevada make their size immaterial compared to imagery. That said, it was a successful effort insofar as it achieved better than bzip2 compression with O(n) encode/decode times.
- 3D-scene rectified photos. For the first third of the project I was manually hand rectifying photos into the 3D activity view[2], but, in the end, this was taking too much time day-to-day.
This has been my passion project for the last six months or so and, as someone who has climbed 89 of these peaks over 20+ years, it has been a real joy chronicling these guys' amazing efforts.
I hope you enjoy it. Any and all feedback welcome… thanks.
[1] - https://www.sps2022.com [2] - https://www.sps2022.com/activity/7016024405, let it load then hit the play button! [3] - https://www.sps2022.com/post/3d [4] - https://github.com/BinomialLLC/basis_universal [5] - https://qoiformat.org/