Atomic Systems

Agree with Derek, if starting a new route then use it, although I still have my doubts about the chasm effect. I get the same effect, as Mike Simpson, just west of the station at Okehampton on my Withered arm route, both in RS and RW.

John

I get that chasm at each major longtitude lines, presumably because there is some data missing where the hgt tiles join.

Fortunately these chasms are quite easily repaired. I laid quadruple main line along the edge of the chasm using the snap to terrain tool to conform it with the terrain, dragged it sideways across the gap, then used the snap to track brush with a 50m radius to raise the terrain underneath it. A few wipes with the smoothing brush and all traces of the chasm are gone.

Much simpler than spending hours excavating valley floors which I had to do with the old data!

I've found the difference in the data can be several meters at any given point. Anybody re-dem'ing an existing route is going to find their track bed is at the wrong height, never mind the fact that all the objects will be floating or buried. I doubt it will be an option for most.
I would use it for new routes. I've only experienced one anomaly on a 50 mile route. I think it is better to repair that, as for the other 50 miles the embankments are cuttings are where they are supposed to be, and not where they should not be. It is going to reduce terrain manipulation for the rest of the route.

As others have found, it is not really practical for existing or half built routes, however I have found it does make a real difference for a route along a cliff top, the cliffs are much steeper and better defined.

Mike

I am having a bit of difficulty with the data on my Bluebell route in that it produces a Something Bad error when tying to raise terrain around Sheffield Park but in other areas a little way from this it is OK. There are some troughs in places, which are repairable, but I cannot get any new data to rise around this station.

It may be something to do with the fact that the 0 degrees longitude runs through the end of the station so there may be an unreconcilable join there, but other than that I have no explanation as to why the program crashes at certain locations when pressing T.

I might try mixing the old data and the new data so the old data files that work can substitute the new ones that do not work. Any differences at the joins between old and new may be easy to smooth out.

Acorncomputer wrote:I am having a bit of difficulty with the data on my Bluebell route in that it produces a Something Bad error when tying to raise terrain around Sheffield Park but in other areas a little way from this it is OK. There are some troughs in places, which are repairable, but I cannot get any new data to rise around this station.

It may be something to do with the fact that the 0 degrees longitude runs through the end of the station so there may be an unreconcilable join there, but other than that I have no explanation as to why the program crashes at certain locations when pressing T.

I've just looked on Google Earth, and Sheffield Park Station is around 50.99N - I think you are getting the same problem I described around 53N. It is the latitude degree boundaries that are causing this, rather than the longitude, and I don't know if this is caused by the converted data or a bug in Railworks itself. I always get a SBHH between around 53.98N and 54.02N

As I have said several times already, it would be much better if Railworks included native support for the raw OS data, instead of making us go through a convoluted conversion process to pretend we are using satellite (SRTM) data. Perhaps with your links to RS.com staff you could press for this.

He can press but he will have to get in line for sure, the whole team are pressing for things.


regards

Derek

RSderek wrote:He can press but he will have to get in line for sure, the whole team are pressing for things.


regards

Derek

I don't have any special links to RS.com staff unfortunately, just the same as everyone else, but I do believe that any constructive comments and suggestions are noted, and not just by Derek and Adam.

Yep, same SBHH occurs at Templecombe and it is also almost exacltly 51N. It seems to be only that row of tiles that contains the 51N line that have problems, the tiles north and south of it can be raised quite happily as edges of a 9 block set. A messy work around is to use the NASA data to raise any tiles that contain the 51N line , then copy the OS data over the top of it in the RW folder and raise the rest (making sure any of the 9 tiles to be raised does not include a dreaded 51N tile).

Still , the new OS data is great , big thank you to the people that put in the hard work to convert it for us

TBH while there are still issues with this data and the efforts of the creator(s) are appreciated, I have stuck with the 60m NASA SRTM for my South Coast project.

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

I suspect the crashes are happening at every east - west degree line where the files meet, as I discovered at 54N and Geoff at 51N. I can't see any of the other degree boundaries being any different, which is why I suspect the problem is with the way that Railworks is handling the boundaries between files.

At the gap between W2 and W1 near Stalybridge I get this


I don't think Thats meant to happen
Regards
Edward

I have found the spikes previously to be a byproduct of using BIL2SRTM after repairing holey data through Microdem, so presumably something similar.

Any Idea how to fix it? and what is BIL2SRTM?
Regards
Edward