Surface levels and bench marks

[AntonyVW]

Ive been looking at old maps and I've been wondering if there is an easy way to translate bench marks and surface levels into something that can be used in Trainz to improve the accuracy of the ground levels at those points. For example I'm looking at a road on a hill on a landscape created using transdem. The road follows the hill quite nicely as one would expect. Except that at certain parts the bench marks or surface levels suggest that at those points the road should be higher or lower. For example:

1) A-----------B--------c

2) A //B // C

3) A // B \\ -- C

in 1) we see the road in plan form going from point a to C. 2) is the slope of the hill going from A - C rising continually and 3) shows the bench marks/surface levels going first up then down (or even levelling off) even if the hill itself is continuing to increase in altitude.

What Im looking for is where do we decide what is accurate and will give us a good ground level so that we can make adjustments along the route? My aim of course is to be able to define the actual ground level of where the track is when it is at the same height as the surrounding land, thus enabling me to work out its rise or fall through cuttings or on embankments.

Anyone any thoughts?

 

[PortlandBill]

The problem is twofold. Firstly, the DEM data is a widely spaced grid of heights that transDEM "connects" with smooth lines so any local changes in height are are not recorded. On the large scale hills tend to look right until you try to add detail. Secondly, older OS maps were drawn from a top-down view so the information presented has no height related information (except for the occasional benchmark). When you combine an old OS map with the DEM data weird things happen like rivers flowing uphill or roads not quite sitting where you expect them to be. This were you need to use your artistry to determine where to make landscape changes using the surveyor tools available. For things like railway gradients, I have tried to find a point on the DEM that both the DEM and map agree and call this "My Datum Point" from here I will measure the distance and height from the route at about 50m intervals. I note these down in a spreadsheet and then produce an XY chart so I can seen how the gradient varies from the published railway gradient. I can then produce a "compromise" profile that sits well in the terrain. I note those heights down and transfer them to the Trainz map using the set height tool. If all goes well it is a simple matter to then level the track to produce a decent looking track and gradient. Others with a more artistic talent than me will just use the tools available and produce a great result . I think what I am really saying after this is there is no simple answer and you just have to do what looks best for you. I hope this helps and doesn't cloud the issue for you too much.
Regards

PS the latest version 2.4 of transDEM includes 3-D map tiles which work well in "lumpy" terrain and helps with the visualisation aspects.

 

[AntonyVW]

Yea. Im using transdem 2.5 with the map laid using 3d which is what prompted my questions in the first place. As far as gradients are concerned Ive not been able to obtain a copy of the track gradient through the area I'm mapping so thee is a lot of guess work involved anyway. Our local station sits in a cutting which is not deep (but deep enough to hide the height of the buildings from the road). As it exits the station going north the land drops away so that within a few hundred meters it is then onto an embankment before becoming a junction running along the side of a hill one one side and at the base of a hill on the other. Heading south the track leaves the cutting on fairly flat ground rising slightly on an embankment to pass over the top of a couple of roads.
There is one benchmark where the track is level with the ground to the south which is what I wanted to use as the basis for my track gradients unfortunately this appears where the track passes over a sunken road. So Im not sure of the height of the track even at this point. But I was kind hoping that I could make more use of them than one spot.

 

[JCitron]

While working on the West Portal to Williamstown portion of the Hoosac Tunnel route, I have run into this issue as well. In part as Steve has mentioned here this is due to the DEM accuracy and the Trainz grid. Remember we have either 10m or 5m grid while there are steps of light and dark in a greyscale image to produce the height map. Also take into account that in the real world, the analog world, there are infinite height values so even with the greyscale steps, these are still steps in height.

To get around this we need to compromise, again as Steve has mentioned. What I've done is to take Google Earth and measure the height in meters at specific points along the ROW. I use landmarks on the topo map and find the same on the aerial image. At those points, or as close as possible, I adjust the track to match the same height. I repeated this along the line until I reached the end and went back and smoothed everything out. Where I erred and created a grade that as too steep, I verified and adjusted my heights accordingly. These, by the way, were quite obvious errors like a 4.6% grade between two points, and 3.5 at another. I even deleted points and moved them if I had to in order to smooth out the grade. When done I now have a track that follows a very convincing and quite realistically graded ROW.

This same technique can be applied to rivers, roads, and other things that have height requirements. Where the image is off from the DEM, as Steve mentioned so well here, I fudged it and used best guess logic to put the river in its place. It helps that I visited the site and saw where the river is versus where it is on the map. The other situation I ran into is there is no height data at that location for some reason with the river sitting at the zero-level with the terrain which of course is incorrect.

John

 

[AntonyVW]

Hi John. Thanks for the suggestions. It's given me an idea. To map the heights of the benchmarks as close as possible on google earth and compare data. I'm hoping that that will then give me some crossing points with the track and use that to get gradients. Only problem I have with this is that last time I tried to get height data it could not tell if I was standing on a bridge or was on the track. So there has to be some trade offs.

 

[JCitron]

Hi John. Thanks for the suggestions. It's given me an idea. To map the heights of the benchmarks as close as possible on google earth and compare data. I'm hoping that that will then give me some crossing points with the track and use that to get gradients. Only problem I have with this is that last time I tried to get height data it could not tell if I was standing on a bridge or was on the track. So there has to be some trade offs.

I hope this will be helpful. Yeah, I had some issues with that too. For overpasses, you'll have to compromise and add some height as these things tend to fill in a bit due to the smoothing effects of TransDEM and the Trainz terrain. You'll also find that the usual difference between what Google Earth indicates versus what the DEM indicates maybe only a 5-10 meter difference in many places.

John

 

[geophil]

1) A-----------B--------c

2) A //B // C

3) A // B \\ -- C

What the others have already said: DEM horizontal resolution plays a roll. The free O/S DEMs are 50m, they simply cannot resolve cuttings/embankments. Other than that, should not not see rivers flowing uphill, not if map and DEM are georeferenced correctly.

You should check that your DEM matches your topographic map. Load DEM and map in TransDEM and switch on DEM contour lines [F11]. TransDEM-generated DEM contour lines should match those on the map, more or less.

While working on the West Portal to Williamstown portion of the Hoosac Tunnel route, I have run into this issue as well. In part as Steve has mentioned here this is due to the DEM accuracy and the Trainz grid. Remember we have either 10m or 5m grid while there are steps of light and dark in a greyscale image to produce the height map. Also take into account that in the real world, the analog world, there are infinite height values so even with the greyscale steps, these are still steps in height.

It all depends on the DEM. TransDEM does not use greyscale mapping or any other intermediate format. It directly sets the elevation for each Trainz ground vertex. If the DEM has floating point resolution - USGS NED DEMs have, most others have not - TransDEM will set the elevation to the last decimal place. Smoothing will always occur if the DEM has less horizontal resolution than the Trainz baseboard. Intermediate ground vertices will receive interpolated elevations. For the optimum result, 10 m baseboards will require 10m DEM (1/3 arc sec for USGS DEMs). 5m grid will require a 5m DEM (or 1/9 arc sec). See my South Tyrol/Brenner Pass screenshots for an example with an Italian 2.5m DEM, resampled to 5m.

 

[JCitron]

Hello Roland,

Thank you so much for explaining this. I didn't know there was no 'tween work between the DEM information and TransDEM. We are using the 10m, 1/3 arc sec resolution on our project due to its size and complexity. If we were to use the 1/9 and 5m, our PCs would glow in the dark by themselves.

I have actually had very good results with the TransDEM translation into Trainz. The height is a mere 5-10 meters difference in worst case which I figured out and compensated for, and in others it's close to 3 meters which is really nothing. The biggest issue though, and this isn't any fault of yours nor could this be solved even with 1/9 resolution, is really tight locations with height differences tend to fill in. This happened not only on our project but on others I have worked on. It could possibly be due to outside interference such as lots of buildings and embankments which only get blended together because they are so close to each other. When that occurs, the only thing we can do is dig in, no pun intended, and figure stuff out for ourselves.

At one point, our DEM information is devoid of height information it seems and the river and other details is completely flat. I wonder if someone had clicked the off button when the highflying aircraft went over head. I know this isn't anything anyone here can do anything about, but it's worth mentioning.

John

 

[AntonyVW]

Thanks folk the info is useful. I do have a question for Roland though. Ive heard you mention elsewhere that you sometimes use a GPS to check an area out. Do you take spot heights with it? And is it possible to get that date into Transdem to add to an existing DEM to get a more accurate map? Im thinking here of the UK where as you have already state the data is at 50m which is not the best. And things like Ive mentioned above where google earth cant tell if you are on the track or a bridge.

 

[mezzoprezzo]

Warning

I've found the elevation values in Google Earth very poor.

Whilst the GE lat/long information is spectacularly accurate, the altitudes can be many 10's, or hundreds, of metres out.

I'm building the Swanage Railway and used GE imagery for my basemaps. However, for the critical area around Corfe Castle, I resorted to using the OS 1:25000 Leisure Map of Purbeck as the basemap so that the Castle, West Hill and East Hill could be correctly constructed in Surveyor.

One way you can check the accuracy of GE in the area you are modelling is to find a Triangulation point. They are clearly marked on OS maps and well documented on the Web. With the superior imagery now available on GE you can see several of them when zoomed right in. I've checked the Purbeck ones and none have the correct height displayed on GE.

An example is the one at Swyre Head. OS maps the height for this one at 203 metres. GE gives it as 184 metres. The highest point I can find on GE, stroking the cursor around the immediate area, is 196 metres altitude. Not only wrong, but 231 metres north of the pillar!

There is is a good site here where you can select your area of interest and get the triangulation point positions and details.

 

[AntonyVW]

Thak you that was a great help. i took a look at the nearest trig point to us which should be 77m but according to GE its only 65m - quite a difference. The second one is a little different though in that is should be 83m but it comes out at 79m with a higher spot across the road from it at 80m. In essence is no more accurate than can be made with OS data to produce DEMs but usable in some places.

 

[geophil]

Thak you that was a great help. i took a look at the nearest trig point to us which should be 77m but according to GE its only 65m - quite a difference. The second one is a little different though in that is should be 83m but it comes out at 79m with a higher spot across the road from it at 80m. In essence is no more accurate than can be made with OS data to produce DEMs but usable in some places.

For many countries GE elevations are simply SRTM 3 arc sec. I would be very cautious with those. Contour lines in a topo map 1:50,000 and up will be more accurate.

Thanks folk the info is useful. I do have a question for Roland though. Ive heard you mention elsewhere that you sometimes use a GPS to check an area out. Do you take spot heights with it? And is it possible to get that date into Transdem to add to an existing DEM to get a more accurate map? Im thinking here of the UK where as you have already state the data is at 50m which is not the best. And things like Ive mentioned above where google earth cant tell if you are on the track or a bridge.

With many outdoor GPS devices you can record a so-called track log. The files are created in .gpx format which is an XML dialect TransDEM should be able to read. However, the recorded data is vector data and, accordingly, automatic processing in TransDEM is constrained to that of vector data.

The track log must include the height/elevation component, of course. Standard GPS height/elevation, however, is not very reliable. Some GPS devices are equipped with a barometric altimeter which can give much more accurate readings. The altimeter must be calibrated before setting off.

TransDEM can use the height/elevation component when exporting 3D vector data to Trainz, to automatically adjust terrain, by creating cuttings/embankments.

For this, Trainz terrain should have been formed by a terrestrial DEM in the first place, such as O/S Terrain 50 or its predecessor Land-form panorama. Orbital SRTM or ASTER will not work well.

 

[AntonyVW]

Roland, which of the O/S terrain 50 files can be used?

 

[geophil]

You download the whole bunch (162 MB) and unzip. The data is organized by O/S grid square codes. In TransDEM, load an overview map, switch the coordinate system to OSGB36 and turn on the grid square option. This will help you to identify the DEM files you need.

More details in the TransDEM main manual, last chapter, page 180 for TransDEM 2.5, and in the TransDEM forum: http://forum.transdem.de/viewtopic.php?p=1355#p1355.

 

[AntonyVW]

Sorry Roland, let me rephrase it. There are 3 sets of data under OS Terrain 50:

ASCII GRID AND GML (GRID)
Vector (Contours) | Supply format: GML (CONTOURS) and
Vector (Contours) | Supply format: ESRI SHAPE (CONTOURS)

I know the first one is the data for the DEMs but what of the other 2? can their data formats be used as they are vector? If so which is the better?

 

[geophil]

The other two options are contour lines. TransDEM and Trainz need raster DEMs. Other applications prefer contour lines. There are algorithms that generate contour lines from raster DEM/DTM data - TransDEM has such a feature - and vice versa. The latter is more complex. For the Terrain 50 product, the underlying data is the same for the raster and the contour line variant.