DEM terrain merger lines

[greg4933]

Hello,
I am using ArcMap 10.1 for process and refining various types of DEMS from 1/3 to 1/9 sec scale dems. I am not mix matching. As most transdem users may have noticed that the standard block 1/3 dem will not load in trans dem due to memory or file size issues. I have been processing these files into smaller files so transdem can open them. One issue I am having is when merging in trainz I am getting a line at the point of merged routes. But yet when I open both files in arcmap the elevation represented on the edges have the correct elevation values from the original file. The 1/3 dem files I am processing down to half the original file, and 1/9 I plan to process down to 1-4x blocks of 24k qquads.

Process I am using.
1. get dem file n38w076.img 1/3 scale
2. generate a shape file cutting the USGS blocks in half.
3. select only one half of a block with define query options.
4.use tool under Data Management Tools, Raster, Raster processing "clip" select dem n38w076, extent used from process step #2 Extraction/clip shapefile.
5. open trans dem, and load clipped dem.img file.
6. save tansdem file.
7. repeat steps 1-6 for the second half of the original n38w076.img file.
8. export both transdem files seperatly as a blank terrain.
9. load into trainz
10. open for edit one route.
11. select merge option.
12. merge your layers.
13. adjust the two layers so they match.
14. save new route.

Am I missing a step to correct terrain alignment issues? If so please fill in the process blank.
If I can overcome this issue I will start working with 1/9 dem data. To create highly detailed terrain.

I am creating routes from the early 1900's, and I am also working on making a blank terrain and calling it develop America. Where you place your own roads, railroad, and cities on the land scape.

 

[greg4933]

Think I thought of a way. The issue I think is in transdem where some the the edges are being cutoff, and terrain is not being represented properly. I am going to try making overlapping routes, and delete some overlapping edge blocks from both routes to correct terrain alignment issues. Think this may correct the issue.

 

[JCitron]

I've seen this when merging any route together in Trainz so I think this is more of a Trainz-related issue. When terrain ends at the edge of the Trainz route, it drops back to zero. Since the edges aren't a perfect 90-degrees, there is going to be a gap between merged terrain areas.

John

 

[geophil]

I am going to try making overlapping routes, and delete some overlapping edge blocks from both routes to correct terrain alignment issues.

Have you checked the info.txt file that is created by TransDEM for each exported route moule? It tells you the UTM coordinates of the edges. For seamless merging the corresponding edge coordinates of adjacent modules have to be identical.

 

[greg4933]

Think part of the issue is also like someone said somewhere else (John). Transdem likes things to be square. Finding a perfect square dem will not happen with out distortion of some sort. I have ran shape vector files ending on the edge of dems and 1 to 2 pixels in and found transdem does not like vertices being that close to the edge. 1-2 pixel with a 1/3 where one pixel represents 10m x 10m. I can do this kind of detail in Arcmap for precision, and accuracy.

Virginia02.txt file
TransDEM Trainz Export --- © 2006-2011 Roland Ziegler

Geodetic Datum = WGS84
UTMZone = 18S

UTM Southwest Corner Easting = 400640
UTM Southwest Corner Northing = 4150800

UTM Northeast Corner Easting = 485600
UTM Northeast Corner Northing = 4210560

Extension East-West = 84.960 km
Extension North-South = 59.760 km

Trainz World Origin = N 37∞ 46.303' W 75∞ 38.506'

Baseboard UTM Grid Offset: x = 0 m, y = 0 m

# Trainz Baseboards East-West = 118
# Trainz Baseboards North-South = 83
# Trainz Baseboards total = 9794
# actually created Trainz Baseboards after filtering = 3480
# hereof in 5 m grid = 3480

Actual Elevation Range Minimum = 0 m
Actual Elevation Range Maximum = 36 m


Virginia01.txt file
TransDEM Trainz Export --- © 2006-2011 Roland Ziegler

Geodetic Datum = WGS84
UTMZone = 18S

UTM Southwest Corner Easting = 400640
UTM Southwest Corner Northing = 4095360

UTM Northeast Corner Easting = 457520
UTM Northeast Corner Northing = 4150800

Extension East-West = 56.880 km
Extension North-South = 55.440 km

Trainz World Origin = N 37∞ 16.224' W 75∞ 53.354'

Baseboard UTM Grid Offset: x = 0 m, y = 0 m

# Trainz Baseboards East-West = 79
# Trainz Baseboards North-South = 77
# Trainz Baseboards total = 6083
# actually created Trainz Baseboards after filtering = 1426
# hereof in 5 m grid = 1426

Actual Elevation Range Minimum = 0 m
Actual Elevation Range Maximum = 29 m

 

[geophil]

Many items handled by TransDEM are either square or rectangular. Even a polyline in vector data has a rectangular bounding box.

Typical squares are UTM tiles (1000 * 1000m or 500 x 500m), Trainz baseboards (720 x 720m), Trainz ground vertex wares (10 x 10m or 5 x 5m) and the image pixel, of course.

DEMs and raster images are always rectangular, not squares.

But we also need to look at the effects of projection. DEMs are often delivered in geographic coordinates, Plate Carrée pseudo projection, which means significant distortion for moderate and higher latitudes if not treated properly first, i.e. converted to some Cartesian system, UTM in the case of TransDEM. UTM projection mathematically is rather complex but what we always see is some minor rotation applied to the original rectangle. Even the "rotated" DEM is still a rectangle, however, now with some black/transparent "wedges" at the edges.

To obtain real clean cuts with straight lines you will have to edit a DEM in UTM coordinates, not in the original Plate Carrée format.

(There is a function in TransDEM that creates seamless tiles in Plate Carrée coordinates, from UTM projected raster data: JPEG image export for Garmin GPS devices. It uses temporary overlapping for each individual tile, to avoid the black patches when unprojecting.)


Your info.txt files look okay to me. The common border is UTM Northing 4150800. I guess that's not the problem. More likely it's the different rectangles in the two projections, Plate Carrée and UTM.