TransDEM Forum

TransDEM News, Support, Hints and Resources
It is currently 09 May 2024 10:05

All times are UTC + 1 hour




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: 18 Jan 2011 19:41 
Offline

Joined: 18 Jan 2011 19:07
Posts: 5
[edit by geophil: moved here from http://forum.transdem.de/viewtopic.php?f=6&t=10&sid=93b9c8d9ffa8625433b3487640ce56cf]

Hello Gisa,

First off I would like to thank you for your tutorial, it has helped me immensely.

I have a problem with the merging of multiple dems. I am trying to model the CP Galt sub or the CN Dundas sub. Due to the fact that both lines run in a south west direction from the Mississauga area to London it is necessary to disect up to 8 grids for the Dundas and 9 for the Galt.
For example on the Dundas I started with 30M5w the next grid would be the 40P8e, the amount of track in this grid is very small although necessary. the next grids would be 40P1e, 40P1w, 40P2e, 40P2w,
40I15w which again requires very little track, and finally the 40I14e.

The program will only let me merge 7 grids successfully.
Is this a program limitation or is it my computer memory?

I am running an older machine on XP with 3.2 gigs of ram
and a Nvidia GeForce GTS 250 with 1 gig of ram

Thanks for your help

Gerry Lee ( Loadman )


Top
 Profile  
 
PostPosted: 19 Jan 2011 09:44 
Offline

Joined: 05 Jan 2011 16:45
Posts: 1465
It could indeed be a memory issue. In his tutorial Gisa suggests to reduce the DEM raster to 10m on opening the original DEM files. As you won't gain much here I would rather leave the default value as pre-set by TransDEM to save memory. TransDEM will convert to the 10 or 5m grid on-the-fly when exporting to Trainz, baseboard by baseboard.

But even with the original DEM raster you may hit the memory limit which is 2GB on 32 bit Windows without tweaking. See the TransDEM main manual on page 17 how to increase this limit to 3GB.

Merging DEMs is expensive, memory-wise. During the merge process, additional memory is needed, at least the size of the two existing DEMs combined, projected to a rectangle. TransDEM 2.1.1 will also try to optimize the undo stack, i.e. clean it, to make more room. But if it's already empty, memory allocation may eventually fail.

This is not a real problem, though. TransDEM has the concept of keeping all loaded geo data in memory. And the 2G space (3GB with tweaking or 4GB on 64bit) seems to be enough for reasonably sized route modules. "Module" is the keyword here. If your route becomes larger, split it into two modules. You can seamlessly merge in Trainz Surveyor later. (The Trainz memory concept is different, it loads baseboards on demand.)

The absolute coordinate system in TransDEM comes handy when merging route modules. TransDEM maintains a static mapping between UTM coordinates and baseboard edges. As long as you stay in the same UTM zone, baseboard edges will always fit, even if exported from different TransDEM sessions and different geo data. (The DEMs should be taken from the same source and series, of course.)


Top
 Profile  
 
PostPosted: 19 Jan 2011 10:59 
Offline

Joined: 18 Jan 2011 19:07
Posts: 5
Thanks for the tip about merging in Trainz, I will give it a try!

Gerry Lee


Top
 Profile  
 
PostPosted: 26 Jan 2011 15:20 
Offline

Joined: 09 Jan 2011 07:20
Posts: 28
Hi Gerry,


I didn't notice your post here. I'm glad my tutorials could help you out.

Dr. Ziegler gave some excellent advice: break it into modules. It is a pain that you need to get those grids, even if the line touches a small part of them, but there isn't really much we can do about it because of the memory considerations. You could merge them later and it will be virtually seamless when you do, so just split it in half if you need to. ;)

I know someone who is hoping to work on the Grimsby sub and if he ever finished it along with your route, that'd be a lot of amazing trackage right there. :)

A lot of this stuff seems difficult for now, but keep plugging away at it because the results will be worth it later.

Dr. Ziegler, I wanted to ask, when I open up the Canadian .DEM I could put in a different number? You suggested 10 a long time ago, but what should I put there to be accurate? I think the numbers 23 x 17 showed but I can't remember...

8)

Gisa ^^


Top
 Profile  
 
PostPosted: 26 Jan 2011 16:56 
Offline

Joined: 05 Jan 2011 16:45
Posts: 1465
mrgisa wrote:
when I open up the Canadian .DEM I could put in a different number? You suggested 10 a long time ago, but what should I put there to be accurate? I think the numbers 23 x 17 showed but I can't remember...

When importing lat/long encoded DEMs TransDEM creates a default value for the metric raster which will usually be on the conservative side data-wise, i.e. trying not to lose detail.

Until TransDEM 2.0 the suggested raster width was a multiple of 10 m. With TransDEM 2.0 and support for the 5m Trainz grid, the higher resolution DEMs will be rounded to a multiple of 5m. Actual resolution in metres of all lat/long DEMs depends on latitude. (Closer to the equator a resolution rectangle will become more of a square.) If at a certain latitude the DEM transforms to a 23 x 17 m rectangle, TransDEM will now suggest 15m. That's better than the lower value of the rectangle.

In former versions of TransDEM the suggested value in this case would have been 20m. To be on the safe side - not losing detail - you would have manually changed the value to 10m. With newer TransDEM versions and the Canadian DEMs that's no longer necessary or recommended. (see note below)

For the US 1/9 arc sec DEM TransDEM will suggest 5m. If the major purpose of processing the DEM is a Trainz route, leave it at 5m as suggested. However, to get the most of viewing the DEM or using it for other purposes, you may want to set to 3 m, which is closer to the nominal resolution, at the expense to eating even more memory.


Note: There is a slight error in this way of processing the DEM. For true lossless transformation, the re-sampling raster width for the 23 x 17 m rectangle would have to be 8.5 m. This is what the Nyquist–Shannon sampling theorem says. However, I have never noticed "noise" in the transformed DEMs. Noise would be the result of subsampling.


Top
 Profile  
 
PostPosted: 27 Jan 2011 01:37 
Offline

Joined: 09 Jan 2011 07:20
Posts: 28
Thanks for the detailed explanation Dr. Ziegler.

So it would be safe for me to assume that for:
- American Data, it's best to use 3 m x 3 m
and for:
- Canadian Data 8.5 m

8)

Gisa ^^


Top
 Profile  
 
PostPosted: 27 Jan 2011 09:44 
Offline

Joined: 05 Jan 2011 16:45
Posts: 1465
mrgisa wrote:
So it would be safe for me to assume that for:
- American Data, it's best to use 3 m x 3 m
and for:
- Canadian Data 8.5 m
Not really. You would normally leave it at the default value. This value is always computed dynamically, from the coordinates and resolution of the particular DEM just opened.

Not fulfilling the Shannon theorem by subsampling seems a venial sin to me. We do it all day, taking JPEG photos or playing MP3 audio. And likewise with the DEM, you will not notice the difference.

Remember, a lower DEM grid width will save memory and give more manoeuvring space.


Top
 Profile  
 
PostPosted: 27 Jan 2011 12:34 
Offline

Joined: 09 Jan 2011 07:20
Posts: 28
I see. The value for Canadian data seems to default at 15 meters so if I ever make another route, I'll go with this.

Thank you kindly for your explanation. :)

8)

Gisa ^^


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

Imprint & Privacy

Powered by phpBB® Forum Software © phpBB Group