Transdem/Resolution.

[scorpio48]

Hi All,
Here's a bit of a brain teaser.
Which initial Raster map would use the least memory.
One small scale map covering the entire route, but because this would be square it would cover many square KM's of unwanted terrain.
or
Several larger scale maps covering a KM or so, each side of your tracks/main roads, but with a lot of detail.
I started out using the one small scale raster map, but now I'm reaching the end of my route and overlaying with large scale, for the purpose of tiling, Transdem is taking a while to load the contents.
Also:- I noticed that with the large scale (for tiling), some of the maps are misaligned, about the width of a single track, I'm 99.9% sure that when I'm preparing the Raster's (google earth) my pins/map don't move between the saves.
The latter isn't much of a problem and can be corrected in surveyor, I wonder if anyone else has noticed this and found a solution. This only applies to the raster's, the Dem's line up perfectly.
Cheers
Pete.

 

[geophil]

Looking at ot from the Trainz routes point of view:

• Ground Texture to paint the map onto the terrain: independent of scale, one instance of the texture and very few bytes per ground vertex (10 m grid).
• UTM tiles, medium map or images scale. Map/image clipping is painted to a texture of 1024 x 1024 pixel per 1000m x 1000m.
• UTM tile, large map or images scale and higher res textures enabled: Map/image clipping is painted to a texture of 2048 x 2048 pixel per 1000m x 1000m.

A different picture from the TransDEM side of it. Here, it's all pixels of the original map or image which count. Geoerefencing largely maintains the original overall dimensions, so that doesn't change anything. For best results and performance, each map/image should be represented by physical dimensions matching its scale. For WMS and Map Tile sources TransDEM internally converts map scale to an appropriate pixel scale, defined by the "global scale factor". This includes Google Maps. If using Google Earth, I would set the eye altitude to a level that matches image quality. For the typical mid-res imagery of 0.5 or 0.6 m per pixel, proper eye altitude is about 500m. Lower values for eye altitude will not reveal more details but will require more memory. (Different story for hi-res imagery.)

The number and size of images TransDEM can load and process concurrently is limited by the overall process memory of 2 GB. The usual way around memory limitations is to load and export smaller and more manageable bunches of images at a time, and continue doing so along the line.

geophil

 

[scorpio48]

SNIP
The number and size of images TransDEM can load and process concurrently is limited by the overall process memory of 2 GB. The usual way around memory limitations is to load and export smaller and more manageable bunches of images at a time, and continue doing so along the line.

geophil

HI geophil,
Thanks again for the info. While I can understand the majority of your reply, its the 'Snipped' part which is giving me a problem.
If I load smaller bunches of images for the purpose of UTM Tiling, I get the error 'Map may have changed ETC' when I try to export and the tiles usually load in the wrong location. For UTM I use an eye altitude of 550 Meters (Google Earth), which is quite sufficient as I have my Anisotropic Filter set to max in both Google Earth and my GC, I use this so that there is no chance of any difference in resolution, between the centre of my cropped image and the edges.
I have 2 GB of ram, which shows about 80% free when I load Transdem, it has spiked to 3% free on occasion but if I leave it for a second or two it soon settles down. My graphic card is an ATI 256MB Sapphire.The monitoring background program I use, uses <0.5 % of ram. The route is 'open for edit' in 2006.
It may be my misunderstanding the documentation.
As I understand it; you must complete part 1 (including export) before proceeding to part two, Export UTM tiles.
The only way I can sucessfully export UTM tiles is if I create the small scale raster maps during stage one, therefore I can't create them as I go along.
As I have a large route, covering most of West Wales, UK, Transdem is slowing down quite a bit as I reach the end of my route.
Please don't get me wrong, I'm not critisising an excellent program, I'm just wondering if I'm doing something wrong.
Cheers
Pete.

 

[mawilson]

I believe the 2GB limit geophil is refering to is the limit on total task space (code and data) that XP enforces. That limit exists regardless of what you have in your system unless to turn on the "3GB switch" and have an application that is compiled for the switch. Then total task space goes to 3GB except for a 256K block at 2GB that Windows holds sacred.

 

[geophil]

Yes, the 2GB limit is the default Windows process limit for "user space", largely independent of the amount of physical memory in you machine.

The TransDEM message "... may have changed ..." is a warning message, as TransDEM does not know what has happened to a Trainz route after it has been created. If you have not changed your route files in the meantime, you can ignore this message.

UTM tiles in the wrong position can be caused by erroneous reuse of KUIDs by TransDEM. To prevent this, do not delete earlier UTM tiles after importing them with CMP until all the tiles for the route have been created.

geophil

 

[scorpio48]

I believe the 2GB limit geophil is refering to is the limit on total task space (code and data) that XP enforces. That limit exists regardless of what you have in your system unless to turn on the "3GB switch" and have an application that is compiled for the switch. Then total task space goes to 3GB except for a 256K block at 2GB that Windows holds sacred.

Yes, the 2GB limit is the default Windows process limit for "user space", largely independent of the amount of physical memory in you machine.

The TransDEM message "... may have changed ..." is a warning message, as TransDEM does not know what has happened to a Trainz route after it has been created. If you have not changed your route files in the meantime, you can ignore this message.

UTM tiles in the wrong position can be caused by erroneous reuse of KUIDs by TransDEM. To prevent this, do not delete earlier UTM tiles after importing them with CMP until all the tiles for the route have been created.

geophil

Thanks Both,
Your replies have helped tremendously. Must admit, I was a trad confused, put it down to my age:hehe: .
One more query regarding using Google Earth in a semi-auto way with Transdem.
If I crop the image from Google Earth in Transdem, (to remove the Status-bar Etc) the raster map don't line up with the Dem. It is always a few clicks South of the Dem.
I assume its something to do with the SW corner being removed.
Also, I noticed that with Google Earth, ver; 4.5 and above. setting the Elevation Exaggeration to 0 (Zero) as stated in the documentation, seems to effect the finished project, You also lose the elevation of various points as you move your mouse across the GE map, ( The elevation readout in the status bar is always 0 (zero)). To overcome this I have set the exaggeration to 0.5. I have checked the result in surveyor, using an OS map and the 'get height' tool, and all height points checked are spot-on.
Thanks again,
Cheers
Pete.

 

[geophil]

There is only a loose coupling between the Google Earth placemark and the Google Earth screenshot. TransDEM expects the placemark to be in the centre of the image and also expects that eye altitude corresponds to the dimensions of the screenshot for correct scale. Cropping the image will shift its centre. Changing the dimensions will change scale. Two sources of error.

You can hide the status bar and compass in the Google Earth settings. I would also select an invisible pin icon for the placemark.

If Elevation Exaggeration is non-zero, Google Earth will lift the ground, hereby changing scale of the screenshot even for level terrain. TransDEM is not able to detect this. For mountainous terrain it will also cause distortion.

Keep in mind that Google Earth renders the surface of the globe as a 3-dim model in a perspective projection. What we want for TransDEM is a 2-dim flat image. The goal is to minimise error and switching off elevation is a way to accomplish this.

(Raising eye altitude to large values will also significantly increase error as we will notice the curvature of the earth, but error is negligible for the eye altitude range we usually apply here.)

geophil

 

[scorpio48]

There is only a loose coupling between the Google Earth placemark and the Google Earth screenshot. TransDEM expects the placemark to be in the centre of the image and also expects that eye altitude corresponds to the dimensions of the screenshot for correct scale. Cropping the image will shift its centre. Changing the dimensions will change scale. Two sources of error.

You can hide the status bar and compass in the Google Earth settings. I would also select an invisible pin icon for the placemark.

If Elevation Exaggeration is non-zero, Google Earth will lift the ground, hereby changing scale of the screenshot even for level terrain. TransDEM is not able to detect this. For mountainous terrain it will also cause distortion.

Keep in mind that Google Earth renders the surface of the globe as a 3-dim model in a perspective projection. What we want for TransDEM is a 2-dim flat image. The goal is to minimise error and switching off elevation is a way to accomplish this.

(Raising eye altitude to large values will also significantly increase error as we will notice the curvature of the earth, but error is negligible for the eye altitude range we usually apply here.)

geophil

Thanks GP,
I noticed that on one export the terrain was completely flat in surveyor, although in reality its extremely mountainous. When I changed the Exaggeration to 0.5 in GE' the problem disappeared. Of course it may be a coincidence because it only happened on one occasion, and I haven't tried it with zero exaggeration since. I have thoroughly checked the terrain in surveyor and I haven't noticed any distortion. I will however run a test program of North Wales (Snowdonia) using zero exaggeration. As I said it may have been a one-of glitch.
I understand the problem caused by cropping, unfortunately you can't hide the Google 'trademark' on the maps, but if I allow enough overlap and lay my raster's in reverse order, then each raster laid should cover the TM.
None of the above are major problems compared to what Transdem can do. If I was working without it I'll probably still be on my first hill.
As I explained in another post, I am currently trying out three new programs, so perhaps its time I sat back for a day or two and take stock.
Thanks again
Cheers
Pete

 

[geophil]

Slight confusion as it seems.

Google Earth screenshots are simple two dimensional "photographs". They cannot carry any elevation. The only data source processed by TransDEM which is responsible for terraforming in Trainz is the DEM.

Did you add map ground textures to your route? (The easiest way to a suitable map would be the Map Tile client in TransDEM.) With this map you can easily verify that mountainous terrain appears where it should.

If UTM tiles show up at the wrong places, I suggest to delete them all in CMP and recreate them in TransDEM. Probably an inadvertent reuse of KUIDs by TransDEM.

There is also another method of verification:

When creating the rout in TransDEM, enable writing of UTM coordinates to the terrain surface in addition to UTM grid lines. Painted coordinate values will be legible in the Surveyor minimap.

Then compare with the UTM tile names (name of the objects in Surveyor). The names also carry the coordinate information, marking their south-west corner.

geophil

 

[scorpio48]

Slight confusion as it seems.

Google Earth screenshots are simple two dimensional "photographs". They cannot carry any elevation. The only data source processed by TransDEM which is responsible for terraforming in Trainz is the DEM.

Did you add map ground textures to your route? (The easiest way to a suitable map would be the Map Tile client in TransDEM.) With this map you can easily verify that mountainous terrain appears where it should.

If UTM tiles show up at the wrong places, I suggest to delete them all in CMP and recreate them in TransDEM. Probably an inadvertent reuse of KUIDs by TransDEM.

There is also another method of verification:

When creating the rout in TransDEM, enable writing of UTM coordinates to the terrain surface in addition to UTM grid lines. Painted coordinate values will be legible in the Surveyor minimap.

Then compare with the UTM tile names (name of the objects in Surveyor). The names also carry the coordinate information, marking their south-west corner.

geophil

Hi GP,
Thank you once again for the reply.
I did run a test program, as mentioned in my last thread, using zero exaggeration,and I'm glad to report all is as it should be.
My initial thought was that there may have been a conflict in the program where GE was overwriting code from the Dem data, I realise that you would have thoroughly tested the program before release, but little glitches do slip through the net,

The problem with the UTM tiles was 100% my fault, somehow, I accidentally added a character to the route name, so the warning was correct, the route didn't exist.
When I reported that they were in the wrong position, the truth is I only checked where they should have been and the immediate surrounding area, as its a large map I assumed that they were placed elsewhere.
As sod's law predicts, it took me several hours to find my error.

I haven't tried the ground texture yet, but I will take up your suggestion.

The vector route works fine, I have experimented with that feature using various filters and all is as it should be.

Thank you once again for an excellent program, and my apologies for taking up so much of your time.
Cheers
Pete.