DEM MAP REQUEST
- Thread starter lsstaten
- Start date
Darn - problem.....
The area required to be merged straddles two UTM zones, resulting in different north-south alignments (or whatever the tec explanation is
) between the two halves of the maps...
The left half is UTM zone 17, the right half is UTM 18. Try as I might, Microdem will not merge the two part-merged DEM's.
Anybody know if there is a way to make this work....
andy
The area required to be merged straddles two UTM zones, resulting in different north-south alignments (or whatever the tec explanation is
) between the two halves of the maps...
The left half is UTM zone 17, the right half is UTM 18. Try as I might, Microdem will not merge the two part-merged DEM's.
Anybody know if there is a way to make this work....
andy
Darn again!
I have had more trouble with this little lot than any other HOG route I have attempted.
Geophil - the convert/merge/convert idea worked splendidly and I have at last got the route into Trainz but alas although much of the route is as it should be, there is about 25% of it (randomly spread around) which looks like this...
It may be botchy DEM data, or it could be that Microdem has played havoc during the UTM/Lat-Long/UTM conversions, I know not which. Sorry Isstaten, I had thought to while away a couple of hours on a wet Sunday with this project, but 8 hours later it is beyond your humble servant's abilities to put right.
Barring that is, more suggestions from cleverer Trainzers than I...
Andy
Edit: PS For anyone trying to work out the whys and wherefores of this one, there is another conversion involved. Although most of the quads were available in 10m and 30m versions, a couple were 10m only and a couple more 30m only, so a consistent set was not possible. A couple of quads were also therefore converted in Microdem from 30m to 10m, before being converted to lat/long and back to UTM........
I have had more trouble with this little lot than any other HOG route I have attempted.
Geophil - the convert/merge/convert idea worked splendidly and I have at last got the route into Trainz but alas although much of the route is as it should be, there is about 25% of it (randomly spread around) which looks like this...
It may be botchy DEM data, or it could be that Microdem has played havoc during the UTM/Lat-Long/UTM conversions, I know not which. Sorry Isstaten, I had thought to while away a couple of hours on a wet Sunday with this project, but 8 hours later it is beyond your humble servant's abilities to put right.
Barring that is, more suggestions from cleverer Trainzers than I...
Andy
Edit: PS For anyone trying to work out the whys and wherefores of this one, there is another conversion involved. Although most of the quads were available in 10m and 30m versions, a couple were 10m only and a couple more 30m only, so a consistent set was not possible. A couple of quads were also therefore converted in Microdem from 30m to 10m, before being converted to lat/long and back to UTM........
Last edited:
Microdem doesn't create the map, it creates two images used in HOG to create a Trainz .gnd file.
This .gnd file is then copied into a map folder created in Trainz to overwrite the Trainz route data with the HOG-created data.
I don't use 06, but the principle would be the same as in 04 - create a new route with the same name as the .gnd file created in HOG, then open the new route folder (presumably using cmp?) and replace the gnd file in the folder with the HOG gnd file...
Andy
This .gnd file is then copied into a map folder created in Trainz to overwrite the Trainz route data with the HOG-created data.
I don't use 06, but the principle would be the same as in 04 - create a new route with the same name as the .gnd file created in HOG, then open the new route folder (presumably using cmp?) and replace the gnd file in the folder with the HOG gnd file...
Andy
Fixed it
Geophil's suggestion of converting the quads to lat/long works and the quads can therefore be merged, but there is no need to convert them back to UTM before proceeding as normal with re-sizing, saving and overlaying Tiger etc. The file corruption above must have occurred during the conversion back to UTM.
I have emailed a link to Isstaten, but the cdp will be up at TPR in a couple of days.
I got a bit carried away with this one and went well beyond the initial brief - the route extends from Big Pool Md northwards to Hagerstown Md and south to beyond Martinsburg Wv. The cdp weighs in at a whopping 40Mb, I doubt if anyone could cope with the whole thing, but there are about 50 different worthwhile routes wrapped up in this - major yards, several class 1 roads, urban industrial, rural branches, you name it! Just lop off lots of boards and keep what you need
Incidentally if large-scale board pruning is required you can lop off literally hundreds with no memory problems if you get rid of them before you start the route.....
Happy trainzing Isstaten
Andy...
Geophil's suggestion of converting the quads to lat/long works and the quads can therefore be merged, but there is no need to convert them back to UTM before proceeding as normal with re-sizing, saving and overlaying Tiger etc. The file corruption above must have occurred during the conversion back to UTM.
I have emailed a link to Isstaten, but the cdp will be up at TPR in a couple of days.
I got a bit carried away with this one and went well beyond the initial brief - the route extends from Big Pool Md northwards to Hagerstown Md and south to beyond Martinsburg Wv. The cdp weighs in at a whopping 40Mb, I doubt if anyone could cope with the whole thing, but there are about 50 different worthwhile routes wrapped up in this - major yards, several class 1 roads, urban industrial, rural branches, you name it! Just lop off lots of boards and keep what you need
Incidentally if large-scale board pruning is required you can lop off literally hundreds with no memory problems if you get rid of them before you start the route.....
Happy trainzing Isstaten
Andy...
Andy,
if you do not re-convert to UTM after merging and keep lat/long as your coordinate system instead, you will end up with a significant distortion, approximately 2:3 for the latitudes in question. The result will appear stretched in E/W direction or compressed in N/S, depending on the axis for normalisation.
Technically/mathematically these coordinate conversions require a complete re-sampling of the DEMs. I don't know how MicroDEM has implemented this, which kind of filtering they use to avoid holes, and grid spacing (10 m vs 30 m) may have an influence, too.
geophil
if you do not re-convert to UTM after merging and keep lat/long as your coordinate system instead, you will end up with a significant distortion, approximately 2:3 for the latitudes in question. The result will appear stretched in E/W direction or compressed in N/S, depending on the axis for normalisation.
Technically/mathematically these coordinate conversions require a complete re-sampling of the DEMs. I don't know how MicroDEM has implemented this, which kind of filtering they use to avoid holes, and grid spacing (10 m vs 30 m) may have an influence, too.
geophil
Hi Geophil - I am fascinated by this business of representing a globe in 2 dimensions, more problems than I had ever imagined!
I still have both the UTM and Lat/Long tga's used to generate the gnd file, and indeed the proportions are different.
The UTM tga is 5710 x 4472
The Lat/Long tga is 5430 x 4188
Relative size east-west - 95.1%
Relative size north-south - 93.6% (or more-or-less 2% undersize)
Also fascinating that the two systems yield a difference of almost 3 kilometers in the width of the map....
Andy
I still have both the UTM and Lat/Long tga's used to generate the gnd file, and indeed the proportions are different.
The UTM tga is 5710 x 4472
The Lat/Long tga is 5430 x 4188
Relative size east-west - 95.1%
Relative size north-south - 93.6% (or more-or-less 2% undersize)
Also fascinating that the two systems yield a difference of almost 3 kilometers in the width of the map....
Andy
Andy,
now I'm confused. Apparently, your MicroDEM lat/long view of the DEM isn't based on a lat/long Cartesian coordinate system. Such a Cartesian system, often called the Plate Carrée pseudo projection, would have fractions of degrees as the unit for their principal axes, with the same scale on both axes. You find such a map representation in Plate Carrée on various geo portals on the Web, like the NSW map server, or Toporama for Canada.
If it was Plate Carrée you would have the 2:3 distortion aspect, and not 5 or 10%. But there are many other map projections out there and MicroDEM might tell you which one is in use. Some map projections are unsuitable for prototypical route building, though. Those are designed for small scale maps. The advantage of a projection like UTM (a form of Transverse Mercator) is both being "conformal" and, in a limited range with controllable error, also nearly "equal-area/equidistant" - and hence, it's used for large scale maps and plans.
TIGER data is not very accurate, so perhaps in this particular case projection errors won't matter that much. Difficulties would start if the route builder tries to overlay Google Earth images.
MSTS is an example with a neither "conformal" nor "equal area/equidistant" native projection (it's Goode-Homolosine) but users didn't take much notice because they didn't have the means to find out - the famous marker files are very tolerant in this respect.
geophil
now I'm confused. Apparently, your MicroDEM lat/long view of the DEM isn't based on a lat/long Cartesian coordinate system. Such a Cartesian system, often called the Plate Carrée pseudo projection, would have fractions of degrees as the unit for their principal axes, with the same scale on both axes. You find such a map representation in Plate Carrée on various geo portals on the Web, like the NSW map server, or Toporama for Canada.
If it was Plate Carrée you would have the 2:3 distortion aspect, and not 5 or 10%. But there are many other map projections out there and MicroDEM might tell you which one is in use. Some map projections are unsuitable for prototypical route building, though. Those are designed for small scale maps. The advantage of a projection like UTM (a form of Transverse Mercator) is both being "conformal" and, in a limited range with controllable error, also nearly "equal-area/equidistant" - and hence, it's used for large scale maps and plans.
TIGER data is not very accurate, so perhaps in this particular case projection errors won't matter that much. Difficulties would start if the route builder tries to overlay Google Earth images.
MSTS is an example with a neither "conformal" nor "equal area/equidistant" native projection (it's Goode-Homolosine) but users didn't take much notice because they didn't have the means to find out - the famous marker files are very tolerant in this respect.
geophil
trammiejono
Member
can some one please make antonito CO to Silverton CO
thanks
thanks