Question for Scottb613

[weichenpfleger]

Hello Scott,
Please find attached the requested names of the ‘w-files’.
I have also noticed that the first scan with SCOLIDEX produced a lot of unpopulated tiles.
Is it possible to incorporate a delete function into ‘GEN X’, similar to MSTS-Unpopulated?

Thank you and Have a good time

Franz

[scottb613]

Hello Scott,
Please find attached the requested names of the ‘w-files’.
I have also noticed that the first scan with SCOLIDEX produced a lot of unpopulated tiles.
Is it possible to incorporate a delete function into ‘GEN X’, similar to MSTS-Unpopulated?

Thank you and Have a good time

Franz

Hi Franz,

Thanks for the WORLD filename list—I believe I've found what is blocking OSM:

w+000000+000000.w

The other 1,653 WORLD files match terrain tiles covered by Geofabrik’s Europe download. This one produces invalid geographic coordinates in LIDEX, which causes the map coverage check to fail.

Please work only on your TEST COPY. Move w+000000+000000.w out of its WORLD folder into a separate backup folder, then try Scan again. Keep the file so it can be restored, and leave your working route unchanged.

This also highlights something I need to improve in LIDEX: the message should identify the problematic file instead of simply saying that no map download covers the route.

Regards,
Scott

[weichenpfleger]

Hi Scott,
LIDEX now seems to be able to process OSM. You can switch off DEM.
I’ll start the scan now.
Thanks for your efforts.

Franz

[scottb613]

Hi Scott,
LIDEX now seems to be able to process OSM. You can switch off DEM.
I’ll start the scan now.
Thanks for your efforts.

Franz

Hi Franz,

Cool - I would hold off until I release the next version - v1.500 - I found some bad error handling where it throws out everything for a single poly error - might be Shawn's issue too. I am working on this now - might take a day or two to fix it.

Thanks again.

Regards,
Scott

[scottb613]

Hi Folks,

SCO LIDEX v1.500 is now available. Thanks for your patience and for providing the logs and files—they helped uncover several problems on my side.

Eric—the memory handling has been substantially revised. LIDEX was retaining too much route data and then loading the entire exclusion file again for validation. It now processes geometry in smaller sections, stages intermediate data on disk, and validates one feature at a time. This addresses the processing path that exhausted memory on Packerland. Large routes will still take time, but they should put considerably less pressure on RAM.

Franz—the improved Scan is included. It now checks several locations across the route and preserves usable elevation sources when another sample has no coverage. It also warns about isolated terrain tiles and identifies their locations. Your reports helped expose how one outlying tile could block an otherwise usable route. Glad to hear the separate WORLD-file change has also allowed OSM to proceed.

I also fixed a polygon problem that could abort an entire run. Empty or negligibly small PolyVeg polygons are now skipped with a warning identifying the affected feature. This may explain some of the other failures reported here, although we need fresh logs to confirm. It does not mean every possible geometry error is ignored.

My latest large-route test completed 4,429 HD map tiles, retaining 78,869 valid PolyVeg features and successfully skipping the problematic polygon. That’s encouraging progress.

The logs now capture CPU and RAM details, application memory usage, and more complete failure information so we have better evidence if anything still goes wrong.

Please use a separate TEST COPY of your route. For planting-data tests, enable OSM / Map Tiles and let LIDEX finish successfully before testing PolyVeg in TSRE. Send the complete new log if it fails.

Download SCO LIDEX v1.500

Thanks again—we’re making progress!

Regards,
Scott

[weichenpfleger]

Hello Scott,
I tried re-adding the faulty tiles and the null-world file. As before, the LIDEX 5 test run was rejected.
I then deleted the faulty tile again and ran the test. It no longer took the null-world file into account.
Log attached.

Greetings

Franz

[scottb613]

Hello Scott,
I tried re-adding the faulty tiles and the null-world file. As before, the LIDEX 5 test run was rejected.
I then deleted the faulty tile again and ran the test. It no longer took the null-world file into account.
Log attached.

Greetings

Franz

Hi Franz,

The log is from the old version 1.401?

Thanks.

Regards,
Scott

[weichenpfleger]

Hi Scott, please excuse the mess on my desktop.
Here’s version 5 without the faulty tile but with the zero-world file.

Greetings

Franz

[scottb613]

Hi Franz,

LOL - you should see mine - I have too many projects going all at once.

Thank you...


Regards,
Scott

[weichenpfleger]

Hi Scott,
I’m at my wits’ end. I’ve now run LIDEX for the second time (24 hours) and, once again, it’s crashed at the end with a message saying that a tile is faulty. But I can’t see anything wrong either in the World file or in TSRE. The log is attached.
Is there a way to save the progress of the LIDEX process so that the computer doesn’t have to run it for 24 hours straight?

Greeting

Franz

[scottb613]

Hi Scott,
I’m at my wits’ end. I’ve now run LIDEX for the second time (24 hours) and, once again, it’s crashed at the end with a message saying that a tile is faulty. But I can’t see anything wrong either in the World file or in TSRE. The log is attached.
Is there a way to save the progress of the LIDEX process so that the computer doesn’t have to run it for 24 hours straight?

Greeting

Franz

Hi Franz,

I understand how frustrating it must be to wait nearly 24 hours and then have the run stop before finishing. Thank you for sticking with it and sending the files—the log identified the exact stopping point.

SCO LIDEX v1.502 is now available:

https://github.com/scottb613/SCO_LIDEX/releases/tag/v1.502

Your latest run stopped because a PolyVeg polygon on tile -5829,14910 still overlapped a permanent exclusion after processing. There was no indication of memory exhaustion or insufficient disk space. Please keep that world file in place.

This version changes how LIDEX handles that conflict:

• It logs the details, omits the affected polygon piece on that tile, and continues processing the remaining sources and tiles.

• It automatically maintains SCOLIDEXErrors.txt in the route folder. This records affected tiles, outstanding processing stages, error details and timestamps.

• Append reads the automatic error list alongside your SCOLIDEXTiles.txt file, if present. Enable the outputs you want to retry. Successfully resolved stages are removed from the error list; unresolved work remains listed.

The omitted polygon piece may leave a planting gap. This allows the remaining work to finish, but does not repair the underlying geometry conflict. Other errors can still stop processing when necessary.

I have also improved the information available for troubleshooting:

Your normal plain-text SCOLIDEX.log remains on the Desktop. If a Run encounters errors, LIDEX also creates SCOLIDEX-diagnostics.zip beside it, ready to send.

That ZIP contains the log, tile lists and a limited selection of exact conflict geometry samples, together with coordinate-system and processing details. It is capped at 100 MB and excludes the large OSM downloads and complete route caches. Any samples omitted because of the limits are identified. The original log is never trimmed.

Please try v1.502 on your separate TEST COPY. If it reports problems, send me the Desktop SCOLIDEX-diagnostics.zip. That should give us much better evidence without needing your entire route or enormous OSM cache.

Also, you can use current TSRE GenX PolyVeg independently of this LIDEX run: open F6 and turn OFF “Use OSM.” You can then plant a ruler corridor, a drawn Closed Area, or a Full Tile without LIDEX planting files. Terrain, slope, water, track and road clearances still apply, but OSM building and land-use masks are unavailable, so inspect the results around existing scenery.

The release passed the build and focused regression checks, including reproducing a detected overlap from saved diagnostic geometry. Your full route run will be the important next confirmation.

Regards,
Scott