closedcontour

Yeah, I was on the fence about using an ephemeral link as the HN submission but in the end figured it was the most appealing to this audience.

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.

I put links to the official SPS site on the About page but your point is well taken. The link at the top of the site that says "SPS Peak List" really ought to take you somewhere that you can find out more substantive information than just the raw list of peaks.

Like others have said, it all depends on the ridge. In this case it is the southern half of the Full Palisade Traverse[1] which is a very technical ridge with long sections of 5th class climbing[2].

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

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.

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...

If you're looking for something worldwide, your best starting point is likely SRTM[1].

If you get into more specific areas you can generally find higher resolution data.

Good luck.

[1] - https://www2.jpl.nasa.gov/srtm/

Assuming everything goes to plan[1] for Nathan's list finish:

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.

[1] - https://www.sps2022.com/post/nathan-finish-plans

Thank you.

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.

Thank you!

Yeah, unfortunately this comes with the territory, especially with this Garmin inReach data. We are running in "expedition mode" which gives us updates about every five minutes but still, you will occasionally get badly spurious points. This is in contrast to the GPS track data you see in the activity viewer. That is collected from their watches which tend to not be quite as bad (although they have their issues too).

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

All of this combines into what you see now: jumpiness, not registering with the ridgeline, and the summit points (where they are manually indicating they are on top) not lining up with the labeled points.

I wasn't aware of this -- very cool. Thanks.

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.

Thank you. Unfortunately I have not yet written anything detailed about the renderer. As is typical with this sort of project, I had grand ambitions about many features and articles to write but have really only been able to focus on the daily updates.

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.

Hi HN, I built a website for tracking an attempt by two climbers to set the fastest known time (FKT) on a well-known list of 247 peaks in the Sierra Nevada.

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/