SCOtopo - Modern Open Rails Cloud Terrain Builder (USGS 3DEP)

[scottb613]

Hi Folks,

Quick SCOtopo update:

Recent builds added a new intermediate fallback source, shown in the GUI as “5m~”. Normal terrain still tries USGS 1m data first, but if that is missing it can now fall back to USGS Original Product Resolution DEM before dropping to 10m / 1/3 arc-second data. This should improve coverage in areas where full 1m LIDAR is unavailable.

The status panel has also been reworked to show a clearer breakdown of Total, Processed, Skipped, 1m, 5m~, 10m, and Failed tiles for normal terrain, with separate Distant Mountain counts.

A new Scan button has been added before Run. Scan is read-only: it checks the selected route, tile names, raw height grids, tile positions, and USGS service availability before enabling Run. If Scan fails, SCOtopo reports the issue in the console/log so it can be fixed before any route files are written, so you're not wasting your time.

v0.68 Uploaded.

Regards,
Scott

[scottb613]

Hi Folks,

Quick SCO LIDEX update:

The program has been rebranded from SCOtopo to SCO LIDEX, more in line with the old DEMEX naming. The GUI has had several cleanup passes: clearer status labels, improved alignment, a larger title/logo area, a Help button, and a Scan Override option for advanced users who want to run without a fresh scan.

Distant Mountain generation has also had more work. SCO LIDEX now creates TSRE-style lo_tiles, rebuilds the required low-terrain index, and will purge older DEMEX-style distant mountain files when rebuilding so the two formats do not get mixed. Normal terrain and Distant Mountains both use the same geo bias settings so they stay aligned as closely as possible.

A new Advanced Geo Bias control lets you shift the DEM sampling north/south and east/west by meters. This is intended for small regional corrections where the terrain appears consistently offset from markers or map overlays.

Logging has been improved as well. The run log now records the GUI settings used at the start of the run, reports elapsed time, and writes to the user’s Desktop. Crash logging was also added to help diagnose startup issues, missing dependencies, or machine-specific failures.

The status panel now separates processed, skipped, failed, and source-resolution counts more clearly. The 1m, 5m~, and 10m rows are shown as sub-items under processed terrain.

NOTE: If you made a desktop shortcut to the last one - just delete it can create a new one.

v0.83 uploaded.

Capture.jpg

Regards,
Scott

[eric]

Still need to get the exact offset values worked out, but the shifting N/S/E/W worked like a charm.

[Zephyr06]

Scott, I'm really impressed by the tool you've created, thank you for making it easier to import DEM into new and existing routes. I wonder, would it be possible for SCO LIDEX to look for a "TsreGeoProjection" statement in the route's .trk file and adjust the tile mapping accordingly? I've been using this TSRE feature to "un-skew" the terrain tiles for my urban route so I can line up the road grid to 90 degree intersections. I like that TSRE is able to generate .hgt terrain that follows this route-specific GeoProjection. It would be amazing if your program could perform a similar function: calibrate the tile projection to the route's region so the map overlays not only match the terrain, but are more proportionally correct as well.

Keep having fun with it!
Matt

[scottb613]

Still need to get the exact offset values worked out, but the shifting N/S/E/W worked like a charm.

Hi Eric,

In the version I have uploaded, now - I think I have the Bias backwards.

I corrected this and ran it with a 15m E Bias (move all terrain 15m E). This is Paul's CT River - in this spot the terrain is too far East - the track should fall in the notch where the vegetation line falls now. Granted - we'll never get perfect for existing routes - and it will always require work. We never know how religiously the original author followed the track lines. It's amazing that you can visually see where the track should lie - almost everywhere with this resolution. You don't need the map (exaggeration for effect). When you can see the roadbed - everything is easier - track routing - realistic grades - true curve radius.

My intention - build a new function - where you can slide the entire route's geodata around - without having to do a new download every time.

I'll upload my small fix this AM - for the backwards Bias.


2026-07-14 07_04_10-Greenshot.jpg

Regards,
Scott

[scottb613]

Scott, I'm really impressed by the tool you've created, thank you for making it easier to import DEM into new and existing routes. I wonder, would it be possible for SCO LIDEX to look for a "TsreGeoProjection" statement in the route's .trk file and adjust the tile mapping accordingly? I've been using this TSRE feature to "un-skew" the terrain tiles for my urban route so I can line up the road grid to 90 degree intersections. I like that TSRE is able to generate .hgt terrain that follows this route-specific GeoProjection. It would be amazing if your program could perform a similar function: calibrate the tile projection to the route's region so the map overlays not only match the terrain, but are more proportionally correct as well.

Keep having fun with it!
Matt

Hi Matt,

"un-skew" and "TsreGeoProjection"?

Where is that?

So this is an option - not just something TSRE does all the time? I can look into it.

Thanks so much for your feedback.


Regards,
Scott

[scottb613]

Hi Folks,

v0.84 uploaded.

Hah - I should have been clearer from the outset that this was an open beta.


Regards,
Scott

[pwillard]

"Hah - I should have been clearer from the outset that this was an open beta."

I was very clear on that… Hopefully everyone else is on board with that as well. I expect to see updates and fixes over time.

PS:
The days of something being developed, locked down, abandoned, and then exceeding its "best by" date by many years should be a thing of the past.

[scottb613]

I was very clear on that… Hopefully everyone else is on board with that as well. I expect to see updates and fixes over time.

PS:
The days of something being developed, locked down, abandoned, and then exceeding its "best by" date by many years should be a thing of the past.

Hi Pete,

Hah - thanks.

Yeah - my intention is to upload to GitHub when stable and I'm happy with it. So, anyone can pick up the torch afterwards.

Regards,
Scott

[Zephyr06]

"un-skew" and "TsreGeoProjection"?

Where is that?

The TSRE map projection feature is discussed in length over at Elvas:
https://www.elvastower.com/forums/in...ap-projection/

From what I gather, this feature should only be setup at the conception of a new route so that all the imported DEM, map images, and world object placements reference the same coordinate system.

There's a diamond crossing in my route that I chose as the center point for my route's projection. I don't know anything about how it works, but I've been happy with the results so far!

[scottb613]

The TSRE map projection feature is discussed in length over at Elvas:
https://www.elvastower.com/forums/in...ap-projection/

From what I gather, this feature should only be setup at the conception of a new route so that all the imported DEM, map images, and world object placements reference the same coordinate system.

There's a diamond crossing in my route that I chose as the center point for my route's projection. I don't know anything about how it works, but I've been happy with the results so far!

Hi Matt,

Thanks - I'll poke around.

Regards,
Scott

[eric]

The TSRE geo projection setting essentially moves the center of the GH projection to a new point so the skew is essentially eliminated.

Sent from my SM-S911U using Tapatalk

[scottb613]

The TSRE geo projection setting essentially moves the center of the GH projection to a new point so the skew is essentially eliminated.

Sent from my SM-S911U using Tapatalk

Hi Eric,

Thanks, I'll look at it and see if I can figure the projection out.

I redid the Advanced Bias controls and moved them to "Post Process Bias" function, they no longer move data while downloading, they will move the mesh around, at will, after download. Instead of having to download a whole new data set, it just slides what you have, as much as you want. CT River took 3 sec to move all the mesh, just have Create Tile and Create DM Tile selected, if you want both moved at the same time.

v0.88 uploaded.

Regards,
Scott

[scottb613]

Hi Folks,

DONE...

SCO LIDEX v1.000 is now available - Official Production Release.

SCO LIDEX is a terrain-building utility for Open Rails / MSTS routes. It reads your existing route tiles, reaches out to the USGS cloud elevation services, and builds terrain directly into the route without needing to manually download DEM files.

Main features:

- Builds normal 8m route terrain tiles from USGS 1m LIDAR where available.
- Falls back to USGS Original Product Resolution DEM, shown as 5m~, when 1m data is not available.
- Falls back again to 10m / 1/3 arc-second elevation when needed.
- Builds optional TSRE-style Distant Mountain tiles.
- Replaces incompatible DEMEX-style distant mountain tiles with TSRE-style lo_tiles.
- Supports Append and Overwrite modes.
- Can select coverage from existing route tiles, a text tile list, marker file, KML file, or track database.
- Includes a read-only Scan step before Run to catch route/tile/service problems before writing files.
- Writes a desktop log with settings, progress, failures, and elapsed time.
- Failed normal tiles are marked so a later Append run can retry them, which helps when USGS has a temporary service hiccup.
- Includes a simple GUI, in-app help, contact button, and desktop shortcut helper.

A major focus of recent work was projection accuracy.

Earlier builds were close, but not quite right. The problem was that normal terrain was being sampled as if the full nominal ORTS tile width was covered evenly by the 256 raw height posts. In practice, the ORTS raw grid is 256 posts at 8m spacing, which means the stored height grid spans 2040m between the first and last post, inside a nominal 2048m tile. That small difference can show up as terrain/map overlay drift, especially over a longer route.

That has now been corrected. SCO LIDEX samples the terrain using the actual ORTS 256-post, 8m grid spacing instead of stretching the grid across the full tile footprint. The result is better terrain placement while preserving seamless tile edges.

SCO LIDEX also now detects TSRE’s optional TsreGeoProjection entry in the route .trk file. If present, SCO LIDEX uses that route-specific projection when sampling DEM data. If it is not present, it uses the standard MSTS/Open Rails world tile projection.

The v1.000 release also includes a fairly substantial GUI and documentation cleanup. The interface has been reworked to be clearer and easier to read, with live status counters, Scan/Run/Abort controls, contact/help buttons, and cleaner visual grouping of the major options. The Help button now opens a formatted, read-only instruction document directly inside SCO LIDEX, so users do not have to hunt through the folder or risk editing the instructions by accident.

As always, back up your route before using any terrain tool, especially before Overwrite or Clean Tile Wipe.

Read the [HELP] instructions.

v1.00 uploaded.


Capture.jpg


Regards,
Scott

[pschlik]

Neat stuff! As much as OR is only set up to handle the tile sizes from MSTS, I don't see anything that suggests you couldn't use an arbitrary number of samples; it looks to me like terrain files are set up to define the number of samples (not OR itself, the only thing that seems to be hardcoded into OR is the physical size of a tile) used and that might mean you can throw higher resolution terrain in? I guess nobody's tried since 1 meter data is a lot newer than MSTS is. Though, for all I know the tile compression algorithm just explodes if you try to cram that much more data into it. Maybe give it a try anyway?

I suspect the actual problem would likely be that the current system of near and distant mountain terrain tiles is inadequate for such high levels of detail, we'd likely need a third type of tile (super near?) or a clever algorithm to procedurally reduce the terrain mesh detail below what's specified in the file as distance increases. I'm interested in the idea of using the nearby terrain tiles as a substitute for distant mountain tiles on routes without distant mountains (inspired by the Utah Belt route, which could benefit from distant mountains), so perhaps that will reveal more about how the terrain system can be manipulated.