Show HN: 3D live tracking two climbers attempting a Sierra Nevada record(sps2022.com)
sps2022.com
Show HN: 3D live tracking two climbers attempting a Sierra Nevada record
https://www.sps2022.com/tracker/NathanL
11 comments
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...
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?
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.
(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.
Amazing! Things have changed since Mike Hoover made "Solo".
Back in the early 70's there were no Drones, iPhone cameras, GPS or internet. Instead, you gathered your pals, a 10 lbs Bolex and as much film as you could afford. Then you hauled everything back to the editing room where you worked for days to cut and splice all that raw footage into a coherent package. If you were very talented, the results looked like this:
https://archive.org/details/solo_20170221
Mike Hoover is still around, and I hope he is watching this
https://en.wikipedia.org/wiki/Mike_Hoover
Back in the early 70's there were no Drones, iPhone cameras, GPS or internet. Instead, you gathered your pals, a 10 lbs Bolex and as much film as you could afford. Then you hauled everything back to the editing room where you worked for days to cut and splice all that raw footage into a coherent package. If you were very talented, the results looked like this:
https://archive.org/details/solo_20170221
Mike Hoover is still around, and I hope he is watching this
https://en.wikipedia.org/wiki/Mike_Hoover
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.
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.
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/
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/
This is very impressive. This may actually be the only 3d web application of this type I can recall that has ever worked completely correctly on my phone.
They always have one or more of these problems: zooms the page when trying to zoom, can’t rotate, can’t move, moves extremely slowly or quickly, jumps around when trying to zoom, randomly freezes or goes black, takes up either a quarter of the page or has 3/4ths cropped out, has the wrong aspect ratio, unusably slow, or something else.
They always have one or more of these problems: zooms the page when trying to zoom, can’t rotate, can’t move, moves extremely slowly or quickly, jumps around when trying to zoom, randomly freezes or goes black, takes up either a quarter of the page or has 3/4ths cropped out, has the wrong aspect ratio, unusably slow, or something else.
You’ve done a great job - it’s super smooth! Congratulations
The terrain renderer is really impressive. Have you written anything that goes into detail on how you created it? I would find that fascinating.
Also, do you mean that you are _automatically_ rectifying photos against your 3D terrain model to determine the direction and angle they were taken from? Or do they come with additional information that is useful in simplifying that task?
Also, do you mean that you are _automatically_ rectifying photos against your 3D terrain model to determine the direction and angle they were taken from? Or do they come with additional information that is useful in simplifying that task?
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.
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.
I saw this when the Palisade Crest was the farthest point. Now there is a line almost straight down. It's been almost 15 minutes since an update, I hope that wasn't a tragic accident.
Can someone confirm if there is some type of speed descent down from the Palisade Crest?
Update: it rerendered, now it looks like a rendering artifact (I hope).
Can someone confirm if there is some type of speed descent down from the Palisade Crest?
Update: it rerendered, now it looks like a rendering artifact (I hope).
Probably just a GPS error. It's not uncommon to see large velocities and position shifts, particularly up in the mountains where multipath issues are common.
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:
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
I hadn't even considered the DEM error. I can totally see it now that you've pointed it out though. The data is impressive either way.
I've had luck in the past with simply averaging the positions from multiple receivers, since horizontal multipath error on its own is typically under a couple tens of meters and it's so hyperlocalized that multiple receivers can experience totally different conditions.
On an unrelated note, do you know if they plan to continue with the half palisade traverse after they complete the rest of the crest?
I've had luck in the past with simply averaging the positions from multiple receivers, since horizontal multipath error on its own is typically under a couple tens of meters and it's so hyperlocalized that multiple receivers can experience totally different conditions.
On an unrelated note, do you know if they plan to continue with the half palisade traverse after they complete the rest of the crest?
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
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
That's one hell of an itinerary.
The Garmin devices that they're using have built in GNSS receivers. There's no practical way to average the positions from multiple receivers for real-time tracking updates. Once the climb is finished, though, someone could download the recorded tracks from multiple devices and average them together.
Wow that's really neat. The pinch zoom spins it vs. zoom.
Would be curious underlying tech for the topography. Will look into it more. I'm looking for a way to find high rises of land across the world although small elevation (like 100ft) thinking some satellite data dump.
Edit: I see the info below posted by OP thanks.
Edit: I see the info below posted by OP thanks.
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/
If you get into more specific areas you can generally find higher resolution data.
Good luck.
[1] - https://www2.jpl.nasa.gov/srtm/
Thanks for the rec
Also consider ETOPO1 [1]. SRTM is kind of old and is treetop instead of groundlevel which may matter for your application.
1: https://www.ngdc.noaa.gov/mgg/global/
1: https://www.ngdc.noaa.gov/mgg/global/
Yeah I'm specifically looking for slopes/cliffs so a generally flat area then a sharp rise.
Hopefully 100 ft is not too small vs. thousands of feet.
I'll check that link out, thanks.
Hopefully 100 ft is not too small vs. thousands of feet.
I'll check that link out, thanks.
Cool site. I’m from NorCal and enjoyed hiking in the Sierra Nevada, but I wasn’t familiar with the SPS reference. And it takes some digging on the Sierra Club site to get any definite reference. SPS is so specific and obscure. Why not a link to Wikipedia?
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.
> “SPS Peaks List”
I’m looking at the site on a mobile phone (and I’m impressed it works so well in this format. Kudos) and I don’t see this link. I do see “Peaks” link. Is that the same?
But my point is not so much a comment on the rest of the site, but for the “About” page specifically. If don’t know SPS is about “peaks”, then I’m not orienting to the site’s ontology quickly enough. I’m lost. I need to get up to speed, so I go to About.
Obviously the site is for a specific audience. If i’m not part of that group, I have to do more work. Maybe that’s OK. But if you want to pull in people on the margins into this detailed world, then About is the place. And I’m looking for who, what, where, when , why. And if I have to go to another site and now learn their ontology, I’m losing patience. Sierra Club is awesome, but they‘re broad and deep. So we’re not going from complicated to simple but complicated to complex. My2c
I’m looking at the site on a mobile phone (and I’m impressed it works so well in this format. Kudos) and I don’t see this link. I do see “Peaks” link. Is that the same?
But my point is not so much a comment on the rest of the site, but for the “About” page specifically. If don’t know SPS is about “peaks”, then I’m not orienting to the site’s ontology quickly enough. I’m lost. I need to get up to speed, so I go to About.
Obviously the site is for a specific audience. If i’m not part of that group, I have to do more work. Maybe that’s OK. But if you want to pull in people on the margins into this detailed world, then About is the place. And I’m looking for who, what, where, when , why. And if I have to go to another site and now learn their ontology, I’m losing patience. Sierra Club is awesome, but they‘re broad and deep. So we’re not going from complicated to simple but complicated to complex. My2c
This would be incredible for multiple types of racing as well, bike, offroad etc.
Awesome, this is amazing and really presents the information in such an innovative way.
I know relive.cc tried something similar with just a video playback before being shutdown by Strava.
Would you consider opening this as a platform for others to post their Strava activities?
I know relive.cc tried something similar with just a video playback before being shutdown by Strava.
Would you consider opening this as a platform for others to post their Strava activities?
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.
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.
Excellent, look forward to it.
That means I’ll have to do all my cycling in the Sierra Nevada region ;-)
That means I’ll have to do all my cycling in the Sierra Nevada region ;-)
Dumb question. It looks like they’re traveling along the ridge. Is that gonna feel like more of a hike or a climb?
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
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
Hi, longtime long-distance hiker here. It depends on the slope. Sometimes, ridge elevation can be relatively flat for long sections. Such sections would fall into the "hike" category.
It depends on how much the ridge goes up and down, and if there are bits you can only ascend with technical climbing.
“No locations in the last three hours. Check back soon.”
:(
:(
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.
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.
Map nerd and FKTer here working in a very similar space, I have a ton of questions!
I'd love to hear a little bit about how the camera positioning works. It seems like there is some fairly clever stuff happening under the hood to (1) maximize the amount of trackline in view so that that it is not obscured by terrain and (2) smooth out the camera path so that it doesn't jitter around even when the gps track is irregular.
Is this a completely bespoke rendering implementation? From the look of things, you're definitely not using mapbox-gl-js or leaflet. Are you even using ThreeJS, or is it just all raw webGL under the hood?
Finally, where are you sourcing your DEMs? AWS Terrain?
(small nit: It seems like you may be missing imagery/data attribution on your map, or do you have a license that allows for un-attributed use?)