folli

So the AI is trained from the previous frame and the input and tries to predict the next frame, correct?

How could you achieve object permanence this way? Will it 'automatically' appear given more training data or more hidden layers? How is this handled in other approaches?

All good, it's a valid question.

I'm actually using cesium.js for the replay mode (https://cubetrek.com/replay/6638) using Google Earth data.

For the 3D mode I was evaluating both Three.js and Babylon.js, and back when I started Babylon.js seemed a bit more exciting as I could set everything up a bit faster, so it was not an objective choice. But perhaps it was the wrong decision in hindsight...

For the GDB files, maybe https://gdal.org/en/stable/ can help?

For anyone Javascript-savvy, you can take a shot at https://github.com/r-follador/CubeTrek_Babylon and experiment with different ways to highlight the current see spot. Any help is appreciated!

Perhaps you can take a look at https://github.com/r-follador/CubeTrek_Babylon

I could use some help there...

Take a look at https://github.com/r-follador/TopoLibrary

I will need to document the code more clearly and extensively, but on the Readme there's an example on how to turn the HGT into a mesh (GLTF).

I can't see anything unusual, do you get an error message?

Edit: I cleared the cache of failed email signups, can you try again?

Nice! I can definitely see the resemblance ;)

Where do you get your height data from?

It's definitely not ready to be merged. But you're more than welcome to work on it!

There are some issues to be solved to self host the app:

- the global height (SRTM) data is approx. half a TB, so we need an option to provide only a subset of files for the relevant locations - same for OSM data where some extracted features are stored locally - remove some third party dependencies, such as captcha verification for sign-up etc. - remove hook to Garmin, Coros, Polar API (each user will need to go through each of the companies verification process themselves to get the keys)

Still some work to do...

Regarding your first point: this is already implemented! In the 3D view you see these little markers on the model with text displaying OSM features "peaks" and "saddles"

Second point: I'm a bit hesitant to store media on the server or on a cloud service, this seems rather costly as this is a free service. But I don't have much experience with this, maybe someone has a good idea on how to manage it?

Is it too nervous? What would you suggest?

Your hike looks cool, thanks for sharing!

Getting the data from Strava is something I really don't wanna touch with a ten foot pole. Talking to other devs, using their API is the stuff of nightmares because they keep changing their ToS very frequently and recently they have become extremely restrictive on what you can do with "their" (actually the user's) activity data.

I never heard of Peakery, need to look into that.

What you can do, however, is to directly link your Garmin, Coros and Polar account to automatically upload data.

Thanks for testing!

The requirement for timing data is in order to calculate all of the statistics. Also, from a perspective of CubeTrek being a kind of diary of your activities, route only files do not really fit into thw picture.

But perhaps it makes sense to allow them on the anonymous upload for the purpose you mention.

The replay mode (example: https://cubetrek.com/replay/6338) also uses Google Earth data. However, I'm a bit hesitant to further work on this, as I don't know if Google will suddenly pull the plug or charge extraorbitant amounts for usage. I consider it more of a proof of concept at this stage.

What did you mainly use Fatmap for? Planning, navigating during the trip or viewing after the trip?

The limit was set in place to prevent the browser from crashing in low-end devices, as the full model is loaded and displayed as a single entity in full detail (in contrast Google Earth etc. uses multiple level of details, depending on the viewing distance).

Server side there's no problem to increase the model size, maybe I can add this as an option.

Look for the Settings (the cogwheel button on the top right)

Wasn't there some kind of plan to integrate it in Strava?

Don't forget to share the link ;)

Where did you get the training data?

If anyone wants to tinker with the Babylon.js code for the 3D visualizations, I made a standalone, sandbox-like repo, which is much easier to set up:

https://github.com/r-follador/CubeTrek_Babylon

Swisstopo is great. Recently, I was playing around with their LIDAR dataset, really cool.

For CubeTrek, however, I needed some kind of dataset with global coverage, that's why I settled in SRTM data.

Thank you, much appreciated!

I've never heard of GPC files, so no ;)

What kind of format is it?

Edit: did you mean GPX files? Yes! And FIT files.

This might interest you: https://cesium.com/learn/unreal/unreal-photorealistic-3d-til...

In case anyone is interested in 3D Terrain simulation (specifically for GPS tracks, e.g. hiking, skiing): I'm working on https://cubetrek.com

Source is here: https://github.com/r-follador/cubetrek

Methanol is a biproduct of fermentation, and will be part of the destillate if not done carefully.

I doubt that ethanol used in car and torpedo fuel will go through the same quality control than drinking alcohol.

CubeTrek

An Open-Source Alternative to Strava (GPS Track Manager for Hiking, Running, Cycling, Mountaineering etc.)

https://cubetrek.com https://github.com/r-follador/CubeTrek/

Java, Spring Boot, PostGis, JavaScript, Babylon.js

Front end could use some help in design overhaul, new feature ideas etc. Also looking for some 3D designers helping to improve the Babylon.js parts. Other, new ideas and features are welcome!

Haha, do you know of any other such gems?

From the paper's method section, a bit more about which type of ML algo was used:

An RF machine-learning model was developed to predict lithium concentrations in Smackover Formation brines throughout southern Arkansas. The model was developed by (i) assigning explanatory variables to brine samples collected at wells, (ii) tuning the RF model to make predictions at wells and assess model performance, (iii) mapping spatially continuous predictions of lithium concentrations across the Reynolds oolite unit of the Smackover Formation in southern Arkansas, and (iv) inspecting the model for explanatory variable importance and influence. Initial model tuning used the tidymodels framework (52) in R (53) to test XGBoost, K-nearest neighbors, and RF algorithms; RF models consistently had higher accuracy and lower bias, so they were used to train the final model and predict lithium.

Explanatory variables used to tune the RF model included geologic, geochemical, and temperature information for Jurassic and Cretaceous units. The geologic framework of the model domain is expected to influence brine chemistry both spatially and with depth. Explanatory variables used to train the RF model must be mapped across the model domain to create spatially continuous predictions of lithium. Thus, spatially continuous subsurface geologic information is key, although these digital resources are often difficult to acquire.

Interesting to me that RF performed better the XGBoost, would have expected at least a similar outcome if tuned correctly.