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

[oper190]

This should fix your issue Geary.

Thanks, giving the new version a try. If all goes well my Hart Rail Lines Route will be where it belongs, with slightly different routing, and on the correct terrain - AWESOME!!!
Also added tiles for the extensions that wouldn't fit on the USA2 tile set.

Edit - Got it running so hopping all goes as it should. 888 tiles to do.
Edit2 - Forgot, needs at least one Tile written in the World Folder. So planted a piece of track and a building on my Start Tile.
Edit3 - Moving along, at the current rate about 11 hours all should be done ( 10:30 -11pm tonight ) well worth the wait.

[eric]

How? Pardon me if I'm wrong, but those routes must already have objects placed? How would this work on existing routes?

It'll work on any route new or finished.

If its an already finished route, some adjustments to building heights might be needed, and most likely some cleanup where it overspills track or road.

Well worth the effort for the higher resolution.

Sent from my SM-S911U using Tapatalk

[amtrak115]

Scott, Ran it against....Meridian Speedway. got logfile SCOtopo1.log (I added the 1 to it).. did as it instructed created a file called SCOtopoTiles.txt (also included here) then ran it again....got this SCOtopo.log did I do something wrong for the second run????

[scottb613]

Scott, Ran it against....Meridian Speedway. got logfile SCOtopo1.log (I added the 1 to it).. did as it instructed created a file called SCOtopoTiles.txt (also included here) then ran it again....got this SCOtopo.log did I do something wrong for the second run????

Hi...

You did the retry correctly. The problem is on my side: SCOtopo generated a retry list containing underscore-style tile names, but the current text-file retry parser does not understand those names yet. That is why the second run only processed one of the five listed tiles. Also, those underscore tiles did not have enough tile-to-world information for SCOtopo to place them geographically. I need to update the parser/decoder for that tile-name style. I'll post here when I update it. Thanks for the feedback.


Regards,
Scott

[oper190]

Moved along while out, looking to be done much sooner than anticipated - 888 tile with 886 done and 1 reduced res Tile - no Distant Mountains yet - figure the regular tiles need to be done first.
Well all 888 done and DMs going now. Started 10:35am and now 5pm, not bad at all.
Scott - AWESOME - great job on your program.

Edit - 5:10pm all is done, fantastic!!!

[scottb613]

Moved along while out, looking to be done much sooner than anticipated - 888 tile with 886 done and 1 reduced res Tile - no Distant Mountains yet - figure the regular tiles need to be done first.
Well all 888 done and DMs going now. Started 10:35am and now 5pm, not bad at all.
Scott - AWESOME - great job on your program.

Hi Geary,

Glad it’s working for you - thanks for the feedback.

Yeah - it’s much easier than DEMEX - you’ve got the right idea - just start it and walk away - let it do its thing. Yep - DM start after normal tiles are complete. It’s about time we get some better tools for route development. I’ve got some more ideas perking away.

To the best of my knowledge - these are the very first routes ever built with 1m LIDAR…

Regards,
Scott

[scottb613]

Scott, Ran it against....Meridian Speedway. got logfile SCOtopo1.log (I added the 1 to it).. did as it instructed created a file called SCOtopoTiles.txt (also included here) then ran it again....got this SCOtopo.log did I do something wrong for the second run????

Hi...

The normal terrain tiles look like this:

-071e3554

That is a full-depth ORTS terrain tile name. SCOtopo can decode that name into an ORTS world tile coordinate, calculate the tile’s latitude/longitude coverage, then request the correct elevation data.

The problem tiles looked like this:

_071f351
_071f352
_071f35d
_071f35e

I have no idea how you made these tiles.

Those are underscore-prefixed and shorter-depth tile names. SCOtopo could not convert those names into exact ORTS world tile coordinates. Your route also had far fewer world files than terrain files, so there was no matching world file available for SCOtopo to use as a backup reference.

Without an exact ORTS world tile coordinate, SCOtopo cannot know where on Earth that terrain tile belongs, so it cannot safely request elevation data for it.

This is not a USGS/elevation coverage failure. It is a tile-location/identity issue.

I fixed the logging for the next build. SCOtopo will now separate failures into two groups:

1. Retryable failed tiles:
These are printed in the paste-ready SCOtopoTiles.txt block.

2. Unmappable failed tiles:
These are listed separately and are not paste-ready retries, because SCOtopo cannot locate them geographically - therefore they are impossible for me to process.

I also updated the text-file parser so underscore-prefixed normal-depth tile names can be accepted where possible. But the shorter underscore-depth tiles still cannot be processed until SCOtopo has a reliable way to map them to ORTS world tile coordinates.

I am uploading the fix now - v0.62.

Regards,
Scott

[amtrak115]

Meridian Speedway is a 2010 route located here on Trainsim. KCS and NS jointly ran on it Now CPKC, NS, and I believe UP. Runs from Meridian MS, to Shreveport, LA. The route here on Trainsim...goes from Meridian ms to basically the Missippi River. One of my back burner route idea is to revamp the original and extend it to Schreveport and possicbly to Wylie, TX...Anyway....

[scottb613]

Meridian Speedway is a 2010 route located here on Trainsim. KCS and NS jointly ran on it Now CPKC, NS, and I believe UP. Runs from Meridian MS, to Shreveport, LA. The route here on Trainsim...goes from Meridian ms to basically the Missippi River. One of my back burner route idea is to revamp the original and extend it to Schreveport and possicbly to Wylie, TX...Anyway....

Hi…

Yep - I understand the route you’re using - I just don’t think they are valid tiles - or at least I don’t know how they are valid tiles - see if you can find them in TSRE and investigate them up close. I suspect they won’t show in TSRE or Open Rails.If you didn’t make the route - perhaps they are leftover from some long forgotten project? I do stuff and leave artifacts all the time.

Regards,
Scott

[dougjones]

I think the tiles with names that start with _ are twice as large as normal tiles, so 4096 meters square instead of 2048. The - and _ seem to indicate how many bits in the last hex digit of the name are valid. I think OR handles these correctly. Don't know about TSRE. You'll probably have to look at the OR code if you want to handle them.

Doug

[eric]

Splitting and merging tiles in the MSTS RGE would result in those 4096 tiles but with lower terrain resolution.

I suspect TSRE might not handle those larger merged 4096 tiles consistently. I see 1024 and 2048 hard coded in many places for handling logic on determining which W file and tile objects live on. When it creates tiles on the fly, they are always 2048.

Sent from my SM-S911U using Tapatalk

[scottb613]

I think the tiles with names that start with _ are twice as large as normal tiles, so 4096 meters square instead of 2048. The - and _ seem to indicate how many bits in the last hex digit of the name are valid. I think OR handles these correctly. Don't know about TSRE. You'll probably have to look at the OR code if you want to handle them.

Doug

Hi Doug,

Oh - gotcha - this is when you didn’t subdivide the tiles in MSTS quad tree editor - to their smallest available - or more familiar - tile sizes. Yeah - I don’t know - I’m not sure how often these are used or if it’s just a left over legacy - I’d have to build a whole new decoder to process these file types. I’ll think on it - but - at least I understand what they are now.

I guess DEMEX handles these large tiles?

Gracias Amigo…


Thanks Eric - just noted your response.

Regards,
Scott

[scottb613]

Hi Folks,

I investigated the larger tile situation - unfortunately - I am going to have to pass on them. Large tiles have half the data point density than normal tiles. Data point spacing of 4km tiles are16m apart vs a normal 2km tiles are 8m apart. The whole point of my work - is to provide the best terrain resolution ORTS has ever seen. I'm not really happy with 8m - 5m would be better but 8m is forced by ORTS - I can't see wasting time on 16m terrain. It's too much work for too little gain. Sorry.

Is TSRE capable of making 4km tiles?

As for the route in question - if you're working on the route - just purge the (4) 4km tiles and build (16) new 2km tiles.

Regards,
Scott

[mnowosad]

Alaska, Seward - Anchorage test

tsre5 alaska1.jpg
orm alaska1.jpg

[scottb613]

Hi Folks,

Nice - I noted Alaska has a 5m source of data - I’ll add that as an intermediate source. Prefers 1m - fallback 5m - fallback 10m. I did run my same test last night and I couldn’t pull 10m - same area I pulled data from many times - had to be a USGS issue. I’ll have to add a status check to poll USGS before working on tiles. All resources not up - abort.

USGS clearly has a problem - the USGS LIDAR Coverage Map - I included in the first post - no longer shows any data.

As always - I’ll post here when I upload a new version.

Regards,
Scott