TransDEM Forum

I am stumbling across the limitations of the Map Tiles functionality in TransDEM. I want to have OpenStreetMap tiles of zoom level 18 (or greater) along my line. But since zoom 18 has such a small scale, the downloaded tile is very small, only giving me a tile some metres around my route. Is there any way to set the radius around the route to get the tiles for?

However, I am fairly solid on the use of OSM Tile Servers, so I'd be happy to just calculate a bounding box and download all tiles directly from OSM myself. However, by looking at the .png and .trf files that TransDEM stores, I can see that TransDEM does some post-processing to the tile once it has been downloaded from OSM. Roland, can you explain the .trf file format, so that I can just write a script to download and re-project tiles from OSM myself?

Secondly, from looking at .lgb files, I can see that they are just a text file that lists all *_georef *.png/*.trf files that were created by TransDEM. How does .lgb handle overlap? Which picture is on top, the later or earlier entry in the .lgb-file? Is there any way to make an .lgb file reference files in subdirectories relative to the .lgb file?

Hmm, I tried to simply write an arbitrary multiple of 256 into the Map Size Width & Height field, and it turns out that actually CAN write any value there. However, the resulting image is still ~2048x2048px regardless… Roland, maybe you could allow for ANY multiple of 256? Implementation-wise that shouldn't be difficult, since you're doing it already anyways, right (the difference between 1024px and 2048px)? Stupid people like me who enter crazy values like 65536 should just have to cope with the huge amounts of data that will result in

If I want large scale all over in my tests I simply duplicate the polyline marking the course of the route and move the (slightly adjusted) copies laterally. But normally I go for a smaller scale (suitable for ground textures) and only use large scale or ortho-imagery in the immediate vicinity of the route.

Quite a bit indeed, like stitching together and converting from normalized Mercator to UTM.The .trf file defines a two-dimensional affine transformation plus the UTM zone and some extras. However, for TransDEM purposes, the transformation is limited to translation and uniform scaling.

• Punkt0 and Punkt0_t define the translation. Punkt0 is the SE corner in image coordinates and must always be 0. Punkt0_t is the same point in UTM coordinates.
• alpha defines the rotation and must be 0.
• Skalierung defines scaling, metres per pixel, and must be the same for x and y
• Scherung defines shear and must be 0.
• UTMZone is self speaking
• Groesse is an option with some built-in redundancy. It defines image size in UTM coordinates (metres) and allows the actual image to be resized outside TransDEM, hereby invalidating the specified scaling. Groesse, if present, always has precedence over Skalierung.
• png simply says that the associated image is in png format. Originally the image format was gif.

No specific handling, all images remain independent and will be stacked upon each other. The operating system handles decompressing and memory consumption.
The later.

I'm afraid not. Any absolute relative path in an entry will be stripped off.

Oh, it should not allow arbitrary values. There are practical limitations. 2048x2048 not only means 64 tiles per image to be downloaded, but also to convert the images to UTM, pixel by pixel. Duplicating the image width means quadrupling the number of pixels and all pixel operations. Furthermore, some operations use integer 64bit arithmetic for exact results and these may run into overflow with large dimension images.

Great!! Thanks!

I'll see what I can do with this. I think I read about some GDAL function that can do this transformation to png files, so it should theoretically be scriptable, I'll look into it...

Yeah, your suggestion of simply moving/duplicating the path to the left and right side of the original was my first idea to... However, I am lazy, so I in my case I just got myself a KML file from the City of New York containing the entire New York Subway network as paths. This is obviously way to complex for the Map Tile functionality in TransDEM, so I already did have to do some XML-magic to group the different linestrings in the KML by name, getting one file per subway line. For many lines this was still too complex, so I also did some analysis on the linestrings and joined them where possible…

Point is: I have a lot of path files, 62 individual files in the NYC example. And I can already see that zoom level 20 generates map tiles ~234x234m. Level 16 gives map tiles that are okay-ish (~3750x3750m), but lack some detail. Specifically, Level >=18 shows platforms and other tiny, but useful details that are helpful when generating a route. But as you can see, the difference in size is pretty large, so I'd have to make 16! parallel paths, to get my desired result :O 16*62 is too big a number to contemplate

My easy quick, and dirty hack is as follows: Download all tiles for level 16. Then do it again for level 20. Finally, create an lgb containing first level 16, then level 20 tiles. The result is having high detail tiles along the path, that are superimposed upon lower detail but bigger map tiles for the surrounding area. I think I can live with that.

Only caveat with this approach: Text labels will get mangled. Interestingly, streets, tracks, and all other OSM vector data line up perfectly even along different zoom level boundaries.