samlearner

Had to over-simplify things a bit on cURL to keep this legible to a general audience, particularly in the first few paragraphs. The idea is that at some point down the stack from your request, libcurl is almost certainly involved (as a dependency, or maybe installed on your internet router, for example), not that your browser is necessarily running libcurl code directly in making the request. But yes, it's slightly hand-wavy in service of the larger point ("this is a thing you use all of the time without realizing it")

We're not scrubbing over a pre-rendered animation here. We're using a library called threejs (a WebGL wrapper) in the background figure and adjusting the camera/models in response to scroll position (within a react environment)

Hey, I'm one of the graphics journalists/authors on the piece

This is not very helpful, but the answers to most of your questions is "it depends"

Our team is made up of reporters, designers, and graphics journalists, but the specific makeup of the team on a given project or who else gets drawn into it varies a lot depending on the topic/scope of the story

For our stories, always lot of React and headache-inducing CSS transition stuff, but the tools/libraries beyond that depend a lot on the needs of the project

- On some stories, there's a lot of blender/threejs work, like this one on quantum computing: https://ig.ft.com/quantum-computing/

- For others, like this one, there's a lot of mapping/data work: https://ig.ft.com/ukraine-war-food-insecurity/

Some stories take a couple of weeks, some take a couple of months and feature fairly large codebases with 500+ commits

Just implemented suggestion (b), sorry for the delay on that. I'm not sure about (a) yet, but will definitely at least add an option to disable autoplay and will consider that.

Designing for mobile is hard! I'm sorry! Really limited space to work in controls without covering for too much of the map

Ha, I don't want to tell you you're wrong, but having heard from a lot of people on this, I'm not sure this is right. The vast majority of people I hear from seem as or more interested in the flyover than the routing itself. And that's why I have to strike a balance here.

Generally, I've found that if it's active at all (requires a click, reading something, opting-in etc) the vast majority of people will miss it.

Working on adding some ability to view upstream paths, but there are a lot of complications with that and it would probably be limited to the US for now. That's the next major item on the to-do list, though.

Yeah the tool struggles a lot with engineered features (dams, canals, etc.) and Chicago is really our quintessential example of this (issue documented a little here: https://ksonda.github.io/global-river-runner/). The US-only version of this tool (https://river-runner.samlearner.com/) is a lot better with the Chicago routes and is generally a little better with routes in the US.

Hey everyone, glad you all are enjoying the project!

To address some of the points I'm seeing, it's not perfect right now, which is why we've considered this a beta release. In particular, there are some issues around name coverage abroad and around engineered features (dams, canals, etc.). A lot of known issues are documented at the top of this page: https://ksonda.github.io/global-river-runner/. Ultimately, we made as much progress as we could, including a lot of manual name suggestions before launching, and decided to publish the tool in beta, with an understanding that we'd take suggestions and otherwise work to improve the tool/data over time.

To the points about the distance the paths are starting from a click, it does round coordinates to some extent. As much as I'd like to be more exact, we're stuck with a limited number of "flowlines" in our dataset and it will look for the closest one, which isn't always as close as we'd like. It's most useful for understanding watersheds in broad strokes, but often falls a little short when it comes to the novelty of literally tracing from your address.

For both specificity and some of the canal issues, the US-only version of this tool is better than this one (https://river-runner.samlearner.com/) with the obvious limitation that the paths are only within the US.

If you have any issues/feedback/suggestions regarding the UI and have a minute, would really appreciate if you're able to submit them as issues in the project repo on Github: https://github.com/sdl60660/river-runner If you're experiencing routing/naming issues, you can submit issues in this repo: https://github.com/ksonda/global-river-runner

Again, thanks for giving the project a look! You can check out some of my other work here: https://www.samlearner.com/ or on my Github (https://github.com/sdl60660).

I'd also like to shout out other other people who worked to make this happen: Dave Blodgett (https://github.com/dblodgett-usgs), Kyle Onda (https://github.com/ksonda), and Ben Webb (https://github.com/webb-ben).

Hey! So the solution I've got in place was actually kind of a compromise solution originally. I had it jump right in at first and people asked to disable autoplay, so I tried completely shutting it off and a lot of people missed that you could run the path altogether. Settled on this 5 second timer, but I think some kind of option to disable it is a good idea. I'll work on adding that in. If you'd like, you can submit it that or other suggestions as an issue here: https://github.com/sdl60660/river-runner

This should be fixed now!

This has been added a stopping feature as of the last update.

Hmm ok, there's a fix here and it's probably something to do with a timer and a way to opt out, I'll work on this.

That's the form the data came in and when it came time to convert it, I figured it might be better not to.

You're the second person to mention this now! The stopping feature stuff is very tricky and not in the original USGS data, but I can block out Chesapeake Bay the same way that I blocked or the Gulf of Mexico

Ha I appreciate you sharing the repo, but if someone is interested in finding a longest route, they should probably just go straight to the data source (USGS NHDPlus data/NLDI API)

I struggled with this a lot. Originally set that ending overview at the beginning, but was worried that practically a lot of users might miss the main feature. I've heard from a lot of people that they were surprised it went into the 3D view, and I think some people might see the plot and just assume that's it.

Hey, thanks for the feedback. I actually struggled on what to do with the cursor, since the map is draggable (when not at min zoom level) prior to a click and the default mapbox cursor is denoting that. On balance, I think you're right that a default cursor might be better.

Re: interaction during the run, I thought about allowing you to interact and just pausing the run while you do, but thought that too many people would interact accidentally, pause the run and then not understand that they had to click somewhere to resume. It's a feature that would technically be ideal, but practically would throw a lot of people off-track with incidental interaction I think (I had this same issue with the decision to start the run right away instead of giving the user and overview at the beginning. Technically, I think it would be ideal, practically, I think a lot of people could miss the main feature of the site altogether).

Speed-wise, I've already slowed it down a good amount from the original iteration, if you can believe that, but I could take it down a little more. There's a weird kind of balance in perceptual speed between camera height and true speed, so I've tried to not give a user full control over speed/zoom, because most options are very bad. I can, at least, take the base speed down a little, and maybe give more precise speed control than what's there. Fundamentally, though, I don't want the default setting to take ten minutes for a run, and I also want you to really be able to see the mountains and canyons.