New DEM data for the UK

[bigvern]

The only way to fix it is to manually adjust or smooth the height in the editor, as we did when similar spikes used to appear when using DEM in MSTS.

BIL2SRTM is a freeware utility that converts DEM data saved as BIL back into SRTM, the only known programme to do so.

[leafy9]

Hi

for those who get crashes with this new data, could you also say roughly what the longitude is.

At the moment it appears that crashes happen to at N51, N52, N53 and N54.

For me it is in centre of the northern border of N51W002.

I will try and see if there is anything in common within the data.

Many thanks

Colin

Hi Colin,

The "51N tile" at Templecombe is from about lat. 50.99545 to 51.00465 N , long. is around 2.42W. If I move to that same latitude tile but at long. around 2.6W the same crash happens, again at 3.5W and 4.5W , so I suspect this crash will happen anywhere along the "51N tile" row, irrespective of longditude.

As a next test , I populated the SRTM folder with the 51Nxxx OS files and the 50Nxxx NASA files - result, the same crash. However, using the 51Nxxx NASA files and the 50Nxxx OS files - success ! This points to the problem being associated with the 51Nxxx OS files (i.e. start data in the 51N files , not end data in the 50N files).

This suggests it could be either bad data (at the start of the 51N) files , or RW itself cannot cope with the new files. Does anyone know how RW reads in and uses this DEM data or the expected format ? - I guess there was less data in the equivalent NASA files. Do we know how much data RW is expecting per file and must they be 1x1 degree and on degree boundaries ? (smaller files would test a possible RW overflow/wrap around problem, different boundaries would confirm if the data is good or not and if the format is correct as it should then crash at the new boundary)

Is there any way to reduce the tile size in RW as hitting T anywhere in the "51N tile" or one of the 8 surrounding tiles causes the crash ? That would narrow it down a bit more.

[balloonist2009]

The only way to fix it is to manually adjust or smooth the height in the editor, as we did when similar spikes used to appear when using DEM in MSTS.

BIL2SRTM is a freeware utility that converts DEM data saved as BIL back into SRTM, the only known programme to do so.

Hi is there a link to downlading this.

[alanch]

Colin is working on his new conversion of the Ordnance Survey data, not using BILxSRTM - we are both convinced that BILxSRTM has introduced some of the trenches and spikes that are not present in OS data.

If you still want to go ahead with my version, the download links are in this thread http://forums.uktrainsim.com/viewtopic. ... 7&start=75 .

[mikesimpson]

There should be no problems with RW handling the more detailed terrain, the U.S. modellers have access to much more detailed DEM than anything the OS is providing at this time.

I suspect the conversion of the OS data is where the problem arises.

Mike

[cwgaskell]

There should be no problems with RW handling the more detailed terrain, the U.S. modellers have access to much more detailed DEM than anything the OS is providing at this time.

I suspect the conversion of the OS data is where the problem arises.

Mike

Mike,

The only current problem, is that RW crashes when "T" is pressed near the northern border of a 1x1 degree HGT file.
The data values show no anomalies, and the interfaces between adjacent files match exactly.
I have looked, and looked, for anything that could be wrong and found nothing.
So at this moment, I see no problem with the new converted data that will be uploaded in a few days (I hope), other than these crashes.
You will be able to examine them yourself soon.

All the best

Colin

[longbow]

Colin - thanks for the new upload. To be clear, are you saying this has cured all known issues except the T crashes? Specifically, have you been able to cure the chasms along the major LON lines noted previously?

[cwgaskell]

Colin - thanks for the new upload. To be clear, are you saying this has cured all known issues except the T crashes? Specifically, have you been able to cure the chasms along the major LON lines noted previously?

Hi longbow,

The N/S chasms on the major Longitude lines appear to be caused by BILxSRTM failing to output the final column of elevations correctly.
In fact what you get is a column of values of 32768, which in 16-bit numbers has the sign-bit set and so can be interpreted as a very large negative number. Hence the massive trench or chasm.

BILxSRTM was not used to generate my version of the data, and I also did not use any existing software. I wrote my own to convert from
the 50mx50m grid of OS data to the 1x1 arcsecond Lat/Long data. All the checks that I have done on the results show no abnormal features, i.e.
boundaries between adjacent files match exactly, no spikes, no holes, no chasms, no cliffs or anything odd, EXCEPT for this problem on the N/S boundary where pressing "T" results in RW crashing.

Later today I intend to acquire some 1-SRTM NASA data covering parts of the USA just to see if RW crashes in the same way or not.

So after yet more checks, I should be in a situation were I can load the new version of these HGT files.

I hope this helps

Colin

[longbow]

It does help. Thanks again for your persistence with this.

[bigvern]

Bear in mind although RW can handle the higher detail 2.1 US SRTM data, this also has problems crashing the sim at latitude boundaries.

[cwgaskell]

Hi - For Info -

For those who may be interested. I decided to pass a few hours looking at the NASA 1-SRTM V2.1 data.
I downloaded sets of files, a central one and the 8 files that surround it.
I then created Test Routes centered at those places, i.e.
N30W092
N31W092
N32W092
N32W112
N33W112
N35W112
N40W118
N47W104

The only thing I did after creating each route was to press "T".
All but N31W092 caused RW to crash.

I will continue checking for a while, but I need to get my files organised soon in order to upload them.

if anyone can get any of the failues to work I will be very interested

All the best

Colin

[miglietto]

Mike,

The only current problem, is that RW crashes when "T" is pressed near the northern border of a 1x1 degree HGT file.
The data values show no anomalies, and the interfaces between adjacent files match exactly.
I have looked, and looked, for anything that could be wrong and found nothing.
So at this moment, I see no problem with the new converted data that will be uploaded in a few days (I hope), other than these crashes.
You will be able to examine them yourself soon.

All the best

Colin

I really don't understand. RS team clearly stated to have fixed this bug. See http://forums.uktrainsim.com/viewtopic. ... &sk=t&sd=a
It's looks like the cat thrown out the door coming back in through the windows

[bigvern]

It doesn't necessarily happen at every latitude line but it did at 36N and also 41N. The latter was relatively recent so I don't think anything has been fixed.

[RSderek]

If you find a bug or an issue that can be reppro'd then email support and it can be looked into.

best regards

Derek

[cwgaskell]

If you find a bug or an issue that can be reppro'd then email support and it can be looked into.

best regards

Derek

Hi Derek,

I have been e-mailing your support people the since 2010/9/9 related to problems with this new DEM data and the "T" RW crashes, ever since I became aware of this new DEM data. I have sent them a fair number of crash dumps, and informing them of any discoveries I have made. Including those of today.

all the best

Colin