Select a category from the list below or use 'Edit', 'Find' on your
browser to search by key words. The Questions are in boldface and
the Answers are in lighter face.
I have found your site to be an incredible resource
and introduction to
geospatial data acquisition and use.
I'm trying to follow along with your 3DEM tutorial but I'm having difficulty
getting usable data to load in the demo version (3dem70). I have acquired
through your suggested methods DEM, SDTS and DRG data for a practice site
(Greeley, CO which is in Weld County). I successfully (I think) ran the
data through the SDTS2DEM converter application with the resulting file
named greeley.dem. Then I go to 3dem70 and click on "load terrain
model" and select the greeley.dem file. In the window below a graphic
appears that doesn't seem to make much sense. It looks like this:
Can you help me understand what is going on? Is this somehow corrupt data?
Furthermore, it seems that 3dem70 does not have the "operation ->
overlay" function. Is this correct?
Your DEM file is apparently corrupt. I do not know how it got that
received an email about two weeks ago from a user who obtained good results
from the converter using his computer at work but somehow created a
corrupted DEM file using his computer at home. He sent me his DEM
I looked at it in hexedit and could clearly see that all the records were
the right places but the elevation values were nonsensical (47,000 meters,
SDTSDEM5 creates large temporary array data structures from heap memory
theoretically memory is limited only by the size of your hard disk.
However, 10m DEMs like that for Greely are very large. I am wondering
maybe there is a memory page size setting problem or some similar issue.
have an idea on how to fix this and may send you a revised program tomorrow
to test if you do not mind.
Anyway, I downloaded the Greely DEM and ran it through SDTSDEM5 on my
computer and then loaded it up in 3DEM70. Everything worked fine,
that it took forever to create the 3D view because of the size of the
(9MB). (30m dems are much more render-friendly.)
I have attached my output file called mygreely.dem. Try loading
3DEM70 and make sure that it works. You could then try comparing
yours using a text editor or alternatively send me your file and I could
diagnose the problem. (I would appreciate if you could do this so
possibly figure out what is going on.)
You are technically correct about the overlay selection. In 3DEM70,
do an overlay but you get at it a little differently. First generate
view using 'View Scene'. Once the scene has rendered, choose 'Operation',
'Modify Textures'. A window will come up. The leftmost section
labeled 'Terrain'. Under this section, choose 'Load'. You
will be prompted
for the name of the .bmp file to overlay. You will notice that the
registration features are not as good in 3DEM70 as in 3DEM.
That is the good news. The bad news is that I have never been able
the overlay utility to work properly in 3DEM70. It always makes
overlays that are sort of semi-opaque. The feature works perfectly
however. One used to be able to download a free 3DEM demo to try
think the vendor has discontinued this offer. However, the new program
not cost much and works flawlessly.
Good luck and hope to hear from you soon.
Here is the modified converter to try. Just in
case there is some type of memory related problem I changed the sequencing
for opening and deleting the internal data structures. Instead of
opening them all at the beginning and closing them all at the end, I staggered
the opening and closing so that only two maximum are open at any one time.
This should reduce the memory burden on your computer, especially for
large files like the Greely cel0 file. See if this makes any difference.
Hey there John, Nice site. I'm picking
up what I can from it, sifting through info to try and find what I'm looking
for. I'm hoping that you might expedite my quest. I need to
find/create some high resolution grayscale images of the grand canyon
to be used as displacement maps inside of 3dstudiomax. I downloaded
SDTSTGA2. To be honest, I'm not positive which I need.
I've used MicroDEM to spit out a bitmap of the DEM, but was left feeling
like there is a better way to get a higher resolution image. I could
use some advise on URLs to go to and what files I need. (some
of those files are so obscurely named that to the novice they might as
well say anything but something I'd recognize. That pretty much
sums up what I'm doing. Any help at all would be greatly appreciated.
I am not familiar with 3dsmax at all, so all I can do
is guess. I checked out the 3dsmax web page and there was a reference
to world xyz projections so maybe there is hope. What you want to
do is import xyz information into your application so that you can use
it for creating virtual terrains or whatever. Digital terrain data
consists of raster data but your application must map the data in order
to make an image. The raster itself is not the image. There
are dozens of formats that this data comes in, but most of it gridded
elevation data, i.e. an x coordinate, a y coordinate and an elevation
associated with the location on the xy plane. SDTS, USGS DEM, DTED0 and
GTOPO are a few of the formats that the raw data is presented to you in.
The trick then becomes to determine if your application contains a provision
to convert data in this form to something that you can use, for example
- a surface.
The only general-purpose rendering tool with which I
am familiar is POV-Ray. This application wants its gridded elevation
data presented to it in a special Truevision 24 byte TGA file format,
as explained on my web page. Each pixel represents a grid point
and the RGB color value is proportional to the elevation at that
point. Thus the utilities that I provide for converting the USGS
DEM (source) data available from the USGS website to this format.
These utilities will not do you any good unless 3ds max likewise wants
its data in that particular format.
So the first thing to do is to find out what your application
wants (if it can accept this type of data at all). Then you need
to find a source for elevation data ( several are listed on my website).
Then you need to find or create a utility to convert the data to the format
that your application will accept. If you take a look at POV-Ray
and see how they do it you will get a pretty good idea of what to
look for and what questions to ask for 3dsmax. An email to the 3ds
max website for instructions might be a good idea as well.
I am running 3D Viz and am attempting to support residential
and commercial land planning. AS far as local survey data no
problem but I also do presentation and "fly overs" and could
benefit from adding larger areas to each project. Is there any way
to convert the SDTS DEM files to any other AutoCAD file? We have
a good ray tracer in Viz but of course it doesn't recognize the .tga presented
by your file converter. Any help or advice would be appreciated.
I am embarrassed to admit that before your email I had
never heard of 3D Viz. I looked it up and could not find any indication
of a way to get DEM data, which is effectively raster information, into
3DViz. The 3DViz documentation indicated that Viz objects are solids,
(ACIS solids reference) which is not good news for importing raster data
although there was also a reference to 3D faces, which sounds like a surface
and would be good news. Gridded raster data like DEMs can be converted
to a faceted surface by "connecting the dots" of the grid and
calculating surface normals. DEM data could be converted to .tin,
.raw or .stl format this way if it would do any good.
I will keep checking and let you know if I find anything
later, Mark wrote...
John, thank you for the quick response. Perhaps
you work late as I. 3d Viz, being an AutoDesk product supports most
drawing files related to CAD. Viz will open or import the following
AutoCAD .DWG, DXF, Microstation .DGN,
... IGES, STL, .3ds, .max
Graphic, surface materials, and maps may be in the standard
formats including .tga, .jpg, .psd, .tiff, .rgb, .rla, .rpf, .mov, .png,
Viz will create terrain similar to what you show by
loading the survey data as lines, set elevation, select the baseline,
create terrain, then select operands. As you select lines a mesh
is created and several options exist including color by level, multi-color
materials, and any map you can load thru the graphics programs.
I use Photoshop. Of course for a small area this works fine...larger
areas are difficult to make realistic. I have taken black and white
satellite photos, tiled them together, created bump maps, and applied
them to the terrain and I agree with your article that it is a bit tedious
to position and scale to fit. At this point, I don't know what
other questions to ask. If I have contours I can make it work.
There has to be similarity to all of this but right now we're talking
two different languages.
I'm interested in the work you've done in Wyoming
using digital terrain. I
work for bp out of Houston, Texas and my area of interest is Wyoming.
would like to utilize some of the resources you have listed but find them
mostly in a format I can't use. The mapping package I am currently using
accept shape files and this is why I'm contacting you. You list a number
converting programs on your web page but none of them convert to a shape
file. Are you aware of any way I can take the digital maps from the USGS
convert them to a shape file? Maybe there is a place where I can download
these files without converting them. Any help you can give would be
appreciated. I am mainly working around the Wind river Mountains and the
ArcView has a bundled extension that converts from SDTS
(which is what you
need) to shapfile, if you have that package. You just load the extension
order to import that type.
If not, here is the link to a
Thanks for your replies. I checked out your
tutorial and it's as good as the others on your site.
Great step by step directions. Tried your software on
my downloaded ASTERs and it worked like a charm. It
was able to handle the conversion of the full files
without a problem on my machine (PIII500, 128MB),
producing wonderful results.
By the time I got your emails, I had already spent a
lot of time trying to find a free or inexpensive HDF
package that would allow me to open the original HDF
files and then transform them to georeferenced
DEMs...to no avail. I found several applications, but
they either wouldn't work on my machine or were way
too expensive. If I am not mistaken, the advantage of
having such a program is that it would open up access
to all the Aster HDF files available (there is limited
coverage for the ASTER DEM product), which I believe
can be converted to DEMs. I was hoping you could
provide your insight on the matter.
Sorry for the delay in replying to your email.
I got a flurry (actually a
ton) of emails following the article and somehow yours got missed.
Both HDF and Geotiff, carry embedded metadata. Both formats are
poorly documented but I was able to decipher geotiff first and already
tiff reader and so I went with that format. I inspected the geotiff
proprietary tags and geokeys and know that there is very minimal embedded
metadata in the geotiff file. The HDF version may have more metadata
If you want to get at the embedded data cleanly, I recommend buying
GlobalMapper from www.globalmapper.com.
Mike Childs there (no relation)
recently added ASTER Geotiff capability, and the program displays all
embedded metadata. The program also writes the metadata to the USGS
file automatically so that you not have to key it in.
HDF format becomes important for all of the other ASTER and other remotely
sensed satellite data, which is only available in HDF. This is my
focus area after I finish with the geotiff DEMs and I will be publishing
findings then, hopefully around Easter time.
> 1) GEOTIF prompts for the UTM coordinates in decimal meters of
> west corner. The metadata file lists four latitude and four
> values. Can you tell me definitively which ones correspond
to south west?
Here is object data from a .met file that I recently pulled:
OBJECT = GRingPointLatitude
CLASS = "1"
Value = (33.9744, 33.9561, 33.3185, 33.3364)
TYPE = "DOUBLE"
NUM_VAL = 4
END_OBJECT = GRingPointLatitude
OBJECT = GRingPointLongitude
CLASS = "1"
Value = (35.4294, 36.2276, 36.2039, 35.4116)
TYPE = "DOUBLE"
NUM_VAL = 4
END_OBJECT = GRingPointLongitude
I believe that the first
vertex of the gring (polygon) is the upper left (northwest) which would
be 33.9744N 35.4294E and they proceed in a clockwise direction
so the southwest coordinate would be the last pair, in this case 33.3364N
35.4116E. As far as I can tell, these coordinates do not coincide
first valid data point but instead coincide with the first data
any type, in this case a missing data point. That is, the coordinates
for the extent of the image, including the black border. I think.
The origin for a USGS ASCII DEM file is the lower
left corner with the rows increasing to the right and the columns increasing
up. This may give you a chance at getting oriented as far
as subsetting goes.
> 2) When we convert to UTM we use the NADCON program and functions.
> specify the input projection as Geographic coordinates with the WGS
> ellipsoid and then enter the latitude and longitude of the southwest
> in decimal degrees as reported in the Metadata file with the output
> projection being UTM, with the WGS 1984 ellipsoid and the appropriate
> zone? I just want to make sure we are georeferencing this correctly?
This is where I will really lose marks. Your question made
me realize that there is an error in GEOTIF .
ASTER DEMs are UTM WGS 84.
Unfortunately, I left
the horizontal and vertical datum flags set for NGVD29 and NAD27,
respectively when I wrote the program. The horizontal datum flag
should definitely be set to 3, (not 1like I had it in the program.)
I am not sure what
the vertical datum is for ASTER so I (now) set it to 1 for local
mean sea level. I
have corrected this and reposted the program. The two flags are
889 and 891 of the DEM file. You can inspect the file and change
the state of these flags for existing files. The applicable information
from the USGS specification for ASCII DEM files is as follows:
Vertical datum INTEGER*1 I2 889 890
1=local mean sea level
2=National Geodetic Vertical
Datum 1929 (NGVD 29)
3=North American Vertical
Datum 1988 (NAVD 88)
Horizontal datum INTEGER*1 I2 891 892
1=North American Datum 1927 (NAD 27)
2=World Geodetic System 1972 (WGS 72)
5=Old Hawaii Datum
6=Puerto Rico Datum
7=NAD 83 Provisional (shifts in
horizontal coordinates are
computed, but old DEM nodes
are not resampled)
Now that this is corrected, inserting the proper coordinates and UTM zone
will allow the application that is reading the DEM file to display the
data accurately. I hope. To answer your original question,
since ASTER data is UTM WGS84 (unknown (to me) vertical datum) and now
the datum flags in the ASCII output file are set correctly (except for
possibly the vertical datum) the answer to your question is yes, I believe
that what you are doing is correct.
A couple of suggestions. For serious ASTER work you may want to
check out GlobalMapper. Although the
program is not free, it will read ASTER geotiff data and write USGS DEM
files just like GEOTIF, except probably better. It costs about $150
and is available at
www.globalmapper.com. Mike Childs (no relation) will probably
be happy to answer questions about that program. The second suggestion
is to contact the customer support people at EOS-EDC for information.
Brandy Adams has been very helpful and I am sure that she could answer
a lot of your questions better than I. Her email address is
email@example.com and you can also talk to her by calling the telephone
number listed on the EOS Data Gateway page.
> 3) When we specify a subregion of the ASTER DEM to write out in UGS
> format will it be correctly oriented as long as we did 1 and 2 above
Well, mostly. However, when I wrote the ASCII data I assumed a rotational
angle of zero degrees, i.e. that the ASTER rows and columns were oriented
north and south. If what I stated above about the correspondence
of the Gring data to the corners of the image is true, that suggests that
there may be a slight rotation. Or maybe not if the polygon is not
a rectangle. I have not been able to find an indication of rotation
in the metadata (I have not looked too hard either) but there may or may
not be an error for this reason.
> 4) Can you think of problems using ASTER DEM's for hydrologic purposes?
They would seem to be ideal for this purpose.
>5) At what percent cloud cover should we be concerned?
You say not to use
> 10, but is there a lot more error (for hydrologic practices) with
data at 7
> or 8 percent compared to data at 3 or 4?
Cloud cover is a dicey thing. Unfortunately, the ASTER bands are
for either visible imaging or DEM production. My colleague Paul
told me that he has had good luck with cloud cover values as high as 35%.
It all depends on what type of clouds and where they are located.
dense clouds covering part of the image while leaving the rest clear will
yield good data for the clear zones while a thin uniform overcast may
the entire DEM to be suspect. The best I can suggest is to look
corresponding L1A image (or the browse image, but this is pretty small).
general arid areas will yield uniformly good DEMs while mountainous areas
the winter can be a problem.
> 6) Is there anything wrong with people from other countries logging
> downloading these data?
No. If my website
traffic analysis is any indication, 25% to 50% of ASTER
usage comes from overseas. All of the emails that I have received
foreign users, express extreme gratitude to the
United States government for providing data that is unavailable in their
countries. My data indicates that Italy, France, UK, Spain and Canada
the largest foreign patrons.
I worked for Trojan Explosives in Spanish Fork from 1989 to 1993 in
environmental and process and ordnance engineering. I have lived
in various parts of the country working for the parent company, Ensign-Bickford.
Utah was my favorite place of all the states where I have lived.
To try to get some extra credit to make up for my
mistakes, I have posted a new article on ASTER L1A/L1B false color
composite images on the site. I must believe that this data would
be useful in your work as major and minor streams, rivers and lakes can
be seen easily. Since ASTER DEMs are made from L1A images, the ground
features should help in georeferencing as well.
Be sure to download the program MultiSpec if
you do not already have it. It is free and you definitely need some
type of data reader to wade through ASTER data. The program is very
easy to use and quite powerful. The link is in the article.
You don't by any chance know of a program that creates a DEM (relative
fine) from L1A data, do you? It sounds as though that must be ordered
through the EOS gateway. Several of the scenes that work for me
available in L1A format but there doesn't appear to be any DEMs available
or my area.
There are at least two capable programs, PCI Geomatics
(this is the program the folks at EOS use to
produce the DEMs you order.) Virtuzo from Supresoft at is another
program is particularly cheap.
I have not tried either but I have read good things about both.
Question: I was able to find about six raw ASTER
files, that will need to be
processed into DEMs. I'm a bit unclear about how to get the raw
ground-truthed. Can you give me some hints?
The general method for georeferencing either ASTER DEMs or ASTER L1A images
requires the following steps:
1) Find the exact image locations of at least three
and preferably more ground control points distributed evenly across your
image. These points should ideally coincide with high and low points
of the DEM.
2) Derive an affine transformation matrix by running
a least-squares regression on the ground control points.
3) Apply the transformation matrix to each pixel
on the image to map the old location to the new location. In the
case of DEMs, each point has three dimensions while L1A data has two dimensions
and involves only planar transformations.
This is not the easiest thing to do. EOS-EDC
uses the same PCI Geomatics package used to produce the DEMs from the
stereo pairs to do the corrections to produce absolute DEMs. You
would need a similar tool to do the same, unless you request an absolute
DEM from EOS-EDC in which case they will do it for you.
I got the following information from the EOS-EDC
FAQ page regarding the latter procedure:
What is a Ground Control Point (GCP)?
A precisely known UTM or Geographic coordinate of a point on the earth
used to geolocate the image. GCPs are needed to create absolute geolocated
DEMs. The requestor must supply these points, along with their precise
locations on the 3N and 3B images.
Projection: Geographic Datum: WGS84
Feature Location in VNIR Band 3N: Line: 2434 Sample: 153
Feature Location in VNIR Band 3B: Line: 2104 Sample: 302
Coordinates: 44:32:36.42N, 116:26:35.27W
Elevation: 569 meters
Accuracy: X: 10 meters, Y: 10 meters, Z: 10 meters
Projection: UTM Datum: WGS84
Feature Location in VNIR Band 3N: Line: 2434 Sample: 153
Feature Location in VNIR Band 3B: Line: 2104 Sample: 302
UTM Zone: 14
Coordinates: Northing: 342567.34 Easting: 2349554.36
Elevation: 569 meters
Accuracy: X: 10 meters, Y: 10 meters, Z: 10 meters
How do I collect Ground Control Points for my image?
GCPs can come from several sources, including fieldwork where the location
the ground control point is determined using a Global Positioning System
(GPS), or from a map of known accuracy. These sources will provide the
geographic coordinates of a certain location on the earth that is
identifiable on each of the stereo ASTER images (3N and 3B). Locations
make good GCPs include easily identifiable road intersections or other
ground level stationary objects. We require at least eight quality GCPs
they must be evenly distributed horizontally and vertically throughout
image to produce a quality DEM.
What is the difference between a Relative DEM and an Absolute DEM?
An Absolute ASTER DEM is generated by using Ground Control Points (GCP)
supplied by the requestor. The software uses the GCPs to tie the DEM to
known points on the ground and yields a product with real ground elevations.
The Absolute DEM is geocoded using customer supplied Ground Control Points
I read your Aster DEM! article on Spatialnews with great interest.
I am working on an archaeological project and Costa Rica and this seemed
perfect. I checked EOS and the Aster DEM product was not available
for this area, so I would like to be able to order request it. How
can I go about doing this? To order an on-demand DEM you have
to query the dataset: ASTER LEVEL 1A DATA SET - RECONSTRUCTED, UNPROCESSED
INSTRUMENT DATA V002 At the EOS Data Gateway. When your
L1A granules are presented there is a link on the search results page that
you select if you want a DEM produced from the ASTER L1A data.
There is an online help menu to aid this process. The official answer
from the EOS FAQ page is:
A Relative ASTER DEM is generated by using only the satellite ephemeris
and will yield a product with ground elevations that are quite near those
an Absolute DEM. The Relative DEM is not nearly as accurate as the Absolute
DEM horizontally since the Relative DEM is geocoded using only satellite
First, you must choose an appropriate ASTER L1A image. This is
done through the EOS Data Gateway. After the granule ID of the scene has
been obtained, you can order the production of the DEM on the ASTER On-Demand
Processing Requests page. To order a relative DEM, the granule ID is all
that is required. Absolute DEMs require the input of the granule ID along
with customer-derived Ground Control Points (GCPs). Note: The customer must
order the ASTER L1A image from the EOS Data Gateway to determine the Line
and Pixel values that must accompany the GCPs. You can probably
ignore the part about the absolute DEM unless you require the best possible
georeferencing. If you do not get any joy from this, I would suggest
contacting Brandy Adams at EROS South Dakota 605-594-6116 to see what other
options you might have, like perhaps ordering a fly-by if possible.
I have a question with regard to ASTER DEMs. First off, the
is discussed on your website (using GEOTIF) to create a USGS quality DEM,
is this for a relative DEM or are there options in the program to add
for the creation of an absolute DEM?
Second, through the EOS gateway, they will create a DEM for you, but as
you mentioned it takes a long time. The process they describe for
creating an absolute DEM requires at least 8 GCPs in addition to some
information from the ASTER 1A image (line of the sample location, etc.,
BOTH band 3N and 3B). When I downloaded the image and tried viewing
ENVI Freelook, I was not able to find where you can visualize band 3.
you have any experience with this or how I can "easily" visualize
Thank you in advance for your help. Your website has been a great
I have not done an absolute DEM myself but here is my opinion.
The following is a copy of my letter to Brandy Adams of EOS-EDC regarding
the ASTER vertical elevation problem: Brandy:
I maintain a not-for-profit GIS webpage at www.terrainmap.com
where I have posted a few articles on ASTER. During the past week I have
received three emails from ASTER users reporting vertical errors on their
relative ASTER DEMs of up to 300m as compared to known standards like topo
map data. All the users are aware of the projection and datum used for ASTER
images so I do not think this is the problem. They have asked me for the
reason and I am at a loss for an explanation. Based
on the information on the FAQ page, I would have thought that the errors
due to uncertainties in satellite position would have been less than what
these users are observing. Do you think that this is within the normal range
for relative DEMs? I have written a program called
GEOTIF that translates ASTER geotiff files into USGS ASCII files. I would
like to add a translation/rotation algorithm to do something like what EOS-EDC
does for the production of absolute DEMs. Can you supply information on
how this is best done? Thanks for your help.
Hi John, We believe that the errors in
elevation that your users are seeing are due to the DEMs being relative.
We have found our relative DEMs to have a decent vertical accuracy;
some do not have good horizontal accuracy, which is due to the accuracy
of the satellite ephemeris data (used to geocode the DEM). We have seen
DEMs up to 1000 meters off in the horizontal direction. If your users
are comparing our DEM to an existing DEM which is accurate in the horizontal
direction, the elevation differences could be great depending on the terrain.
We tested the vertical accuracy of our relative DEMs by first determining
the horizontal error. We did this by comparing the DEM to an existing map
source and then moving the DEM horizontally until it fit over the map. We
then did the vertical comparison. I forwarded this message to one
or your users as well. Your question about the translation/rotation
algorithm would best be answered by PCI software support. The software we
use to generate the DEMs is PCI/Orthoengine, and their contact information
can be found through the link below:
http://www.pcigeomatics.com/support/support.html If you have
other questions, please let me know. All the best,
GEOTIF would not help you produce an absolute DEM as it only takes the
already produced and converts it to USGS ASCII format for subsequent
rendering. What you need to do is what you described in paragraph
MultiSpec might be a useful tool for this job. I have been able
to view bands 3N and 3B for both L1A and L1B data easily. In order
to do this job right however, it would seem that you would
need to drop marker pixels in the image to check your referencing.
I do not
think that you can do this with MultiSpec, or any of the data readers
have seen. I will keep on the lookout. Anyway the MultiSpec
link is given
on my web page (newest article) along with instructions on how to do exactly
what you are interested in.
Land Processes DAAC User Services
Hello-I have a question about the DEM generated from ASTER data using
GEOTIFF4,I am using GEOTIFF4 to convert ASTER data of the Peruvian Andes,
then converting the DEM to an ArcInfo GRID, for some reason when I view
it in ArcInfo, the grid does not seem to be in the correct projection,
even though the correct projection found in the .met file is assigned
to the grid. In order to check the placement of where the images should
be, I generated a point coverage of the four corner points contained in
the .met file. These points project correctly, however the resulting DEM
from GEOTIFF4 is projecting 10,000km to the north of the corner points
where it should be projecting. Do you have any suggestions as to where
I am going wrong?
Sorry to bug you with such questions, but any help would be gratefully
Sorry for the delay in my reply. The UTM system is a little strange
in that within a given UTM zone the coordinates are not unique. The UTM
latitude coordinate in the northern hemisphere starts at 0 at the equator
and increases to 10,000,000m near the north pole. In the southern hemisphere,
the coordinates start at 0 near the south pole and increase to 10,00,000
at the equator. This leads to the strange situation where the same point
on the equator has two latitudes associated with it, 0 and 10,000,000.
ArcInfo is assuming that your southern hemisphere latitude coordinate
is in the northern hemisphere. When this error occurs, your latitude is
off by exactly 10,000,000m, regardless of the location of the point in
question. There must be a switch somewhere in ArcInfo that allows you
to specify that the coordinate transformation calculation shoud correspond
to a southern hemisphere location. There is no way to encode this in the
UTM coordinates themselves.
Thus, this is one of the rare instances where the problem is not my
fault (I think).
Hello, I'm trying to construct a DEM from an ASTER image (bands 3N
and 3B) using ERDAS 8.5.1 Otho-Base Pro. I've serious problems in finding
the values for side insidence (nadir and backwards) from the hdf or met
files.I found on the web that the keyword for side incidence is "POINTINGANGLE1"
but still no progress has been made.(In order to read hdf files I use
HDFView Version 1.2). Can you, please, help me out. Thank you in advance
for your time. Antoniou.
I do not have any experience with making DEMs from ASTER L1A/B but I
just opened a sample ASTER L1A file in my ASTER directory with my text
editor and found it right away in the metadata section at the very end
of the file: OBJECT = POINTINGANGLE CLASS = "3" NUM_VAL = 1 VALUE = -8.557000
END_OBJECT = POINTINGANGLE Use your text editor to search the string "=
POINTINGANGLE" and it should come up. Your reference to POINTINGANGLE1
seems to be in error, as the CLASS is indicated as 3. Let me know if this
is what you are looking for. John
Thank you for your useful advice. I ordered
the unprocessed data and got the data within 12 days !
I got informed, that *.hdf.met and *.hdf were available in a certain
I was surprised to find out, that there were no corresponding *.tif files
on the other server (188.8.131.52/pub/asterdem/relative, as you mentioned
in your Aster Dem Download Procedure).
So I decided to download some of the huge *.hdf files (110 Megabytes each
) , hoping, I would be able to find (or program) a suitable converter
to *.tif format later. Although I have a highspeed DSL internet access
, there was not enough time to download all available *hdf files before
the deadline given by EOS. So I had to make a better selection.
Here I ran into a second obstacle: I was rather inconvenient to get the
"percent cloudcover" data for each granule. I had already tried
to make a good selection while ordering the granules, but the text-only
output (for Excel processing) of the selection pages did not contain any
data in the cloud-coverage attribute . I send a request to EOS about this
(see below) and got an answer, which I enclose. The cloudcoverage data
was available at the time, when browsing manually through the attribute
pages of each granule.
This data is vital for Germany, as I found out, that less than about 10%
of the granules returned have less than 10% cloud cover
As I am encouraged to dig for more high resolution elevation data of Germany
, here is my main question:
Do you know of a way to get to the *.tif data of my ordered granules,
or how I could convert the *.hdf files to *.tif format locally on my harddisk
I found a flaw in your Search engine.
I wanted to get an overview of the available Aster Dem unprocessed LA1
data of central Germany and set up a query for lat 48 to 51 /longitude
7 to 11 and got a set of more than 100 granules returned. I transferred
this result to its own folder and modified the selected fields to id,
area coordinates and cloudcover in order to have a quality attribute for
the selection of the subsequent process orders . Although the cloudcover
is known in the individual metadata of each granule, in my above query
it remained blank. Is that a known problem and is there a workaraound
Second question :
Is there a way to request the view data (as another quality attribute)
of a set of granules, rather than requesting them individually ?
Thank you very much for your great website and your support !
Answer from firstname.lastname@example.org
Subject Incorrect results returned for criteria entered
Thank you for your comments. There are certain data types, ASTER Level
1A and 1B included, that cannot display the cloud cover amount in the
Results List table. We are aware of this inconvenience, but unfortunately,
no changes are expected to be made to this feature at this time.
We have requested a multiple browse feature, but there is no estimated
time as to when it will be available. In the mean-time, it may be a little
more convenient if you FTP the browse images to your directory and preview
them in a HDF software. Select Request Sample from the Granule List and
fill in the appropriate information. You should only have to fill in your
information once, but you will have to click on Request Sample for each
granule. This may or may not be a faster method.
If you have any other questions or concerns, please feel free to contact
Thank you and best regards,
I think that the EOS reply sums it up. Do not forget
however that the ASTER DEM granules do offer both numerical cloud cover
data and browse images. One possibility might be to check the ASTER
DEM archive first, examine the browse there, and then locate the corresponding
L1A or L1B product.
Unfortunately, there is not a DEM for every L1A image
so this will not work all the time.
In answer to your second question, the program MultiSpec,
mentioned in the L1A article on my website can do exactly the conversion
that you require. That is how I prepared the images on the page.
The link is listed in the article.
I need to convert the stds dem to a format that can
be read in AutoCAD 2000i, any suggestions?
I do not know enough about AutoCAD's 3D capabilities
(particularly the way that it represents surfaces) to give you the answer
you are probably looking for. It may be possible to convert DEM
data to DXF format such that it can be rendered and manipulated directly
in AutoCAD but I doubt it.
However, it should be fairly straight forward to create
a raster image externally, import the image into a layer, and then use
the raster map as a base for further mapmaking by overlaying vector data
that you create in AutoCAD. (One problem is that you will not be
able to change the viewing perspective after you have imported the DEM.)
As you probably know, a DEM is a raster file, as opposed
to the vector data that AutoCAD and other CAD programs normally handle.
So the data structure is basically an array of elevation values arranged
on a rectangular pattern. The data object is the node. There
is one node per array location. The number in the array location
is proportional to or equal to the elevation of the terrain (z-value)
above the horizontal datum. The x and y coordinates are not included
in the array but can be inferred because the grid is regular and the grid
spacing and corner UTM coordinates are indicated in the DEM modules.
You must therefore import the raster data into AutoCad.
AutoCad 2000 apparently has the ability to import raster data in various
In order to create a useful map, you must first map
the numerical DEM data to a projection plane with the proper location,
lighting, etc. so as to create the image that you want. This image
must then be converted to a file format that AutoCad can handle.
The easiest way to do this is to use the program MicroDem
(see my web page for download information). Open your DEM as
a "New DEM" under the "File" menu. Choose the
"View" menu tab once your DEM has loaded and select "Open
GL" and "entire map". You should see a 3D rendering
of the DEM. Manipulate the viewpoint to get the proper perspective.
Check the "lighting" box if you want to get rid of the colors.
Adjust the sun position. Save the image as a .BMP file by right
clicking on the image. This file can now be imported into AutoCad
and serve as the basis of your map.
Alternatively, you could use DEMDRAPE and POV-Ray
or SDTSTER2 and Terragen to do the same thing with more flexibility but
it takes a little more expertise to work these programs correctly.
I have attached an image (Ticaboo Mesa, UT 7.5'
DEM) that I generated this way to show what I mean. A good link
that explains how to import raster data into AutoCAD if you do not already
know how to do this is:
Let me know if this does not make sense or if you need
help. Good luck.
We are trying to find a source for
mapping that we can use in AutoCAD 2002. What we are doing is taking the
mapping and putting things like city boundaries, sewer lines, water lines.
We need to be able to plot these out at various scales like 1” = 200 feet;
1” = 2000 feet; 1” = 50 feet. We will use these maps for design stages
of sewer and water projects. The contour lines need to adjust according
to the scale i.e. the line the same weight no matter what scale we plot
it. We need to plot it in color, similar to what a USGS map looks like.
These maps will be used from design and presentation to framing and putting
on the City hall wall. Can you help us? The key is it has to be editable
in AutoCAD and the line quality sharp.
I have check with ADCi and looked
through their stuff. It looks good but the printed product does not look
like the USGS maps.
We purchased DeLorne mapping software:
Xmap, Export module for XMap and the 3-D TopoQuads for West Virginia.
They almost work except that the print out is jagged and rough the lines
are not flexible with the scale used. They have big wide lines on smaller
scales such as 1” 50 feet.
Thank you for any help you can give.
I talked to the GIS specialist that comes into
our company once a week. I looked at his work and I am sure that
he is producing the type of publication-grade maps that you are interested
in. After talking to him, I am convinced that the only way you are
going to get the kind of results that you want is to use Arc View/Arc
Info from ESRI. I talked to him about doing what he did in AutoCad
and he said forget it, that AutoCad does not even come close to
the ESRI product in terms of capability.
As far as your idea of purchasing a map database and
then overlaying your vectors: I do not think this is possible at this
time. The reason is that there is a fundamental conflict between
the behavior of rasters and vectors upon scaling and other operations.
What our man does works approximately as follows:
First he obtains raster data that represents his mapping base. This
is typically a USGS topo map or an aerial photo. He imports the raster
into Arc Info and converts the raster image to a vector image using the
automated tools in Arc Info. By vectors, I actually mean Arc objects
such as points, lines and polygons which are mathematically speaking vectors
with spatial and other attributes. A road, for example will be contoured
and converted to an Arc polygon object. This object can then be
shaded and entered into the Arc Info database. The same for buildings,
vegetated areas, etc. The result is an array of Arc objects that
serve as a base for subsequent overlay of more vector data, such as fence
lines, utilities, etc.
He then imports the layers to Arc View which apparently
has a different set of tools that are used to create the finished map.
He said that it is possible to generate vector overlays in AutoCad and
then import them to Arc View or to work directly in Arc View.
The result is a vector map that is of flawless quality
and that behaves correctly upon scaling because every object in the map
is a vector object, even if it looks like a raster.
Anyway, I think I got this approximately correct.
I recommend visiting the ESRI website and talking to one of their sales
folks. The software is not cheap but it sounds like what you may
need to produce the kind of maps you described.
T hanks for your help. I called ADCi
and they assured me I could buy their maps and do the same in AutoCAD.
I think since they claim I have 30 days to try it that it may be cheaper
that buying new software. Have you had any experience with their Tiger
maps? I know that I have been a lot of trouble for you and again I want
to thank you for all your help.
Hi John, I really enjoy your site. Keep it up! I was running through
your how to on using WinTopo and BLACKART to generate dems from topos. I
followed your instructions meticulously through WinTopo and successfully
saved out my vectorized topo with elevations as a arcView .shp file. When
I ran it through BLACKART , though, I kept getting the error "Invalid floating
point operation". I've tried various different combinations for the "LSQR
iterations" and "Laplacian Iterations", have regenerated my WinTopo data
sets several times (!), and have reread your how to several times in search
of my error, all to no avail. I was wondering if you had any insight on
what I might be doing wrong. Thanks in advance for any help. Cheers, Matt
Matt: I checked out your attached files as best I could.
Since you did not include the base .tif file I could not load it into
my demo copy of WinTopo. So I proceeded directly to testing it with BLACKART
and found the following: 1) The file produced the same error that you
reported when I attempted to run it. 2) I determined that the problem
was due to a mismatch between the number of records that were indicated
in the index file (this is the .shx file) and the number of records found
in the .dbf file. The .shx file indicted that there were 30 records. (The
program determines this by counting all the bytes in the .shx file, subtracting
100 bytes for the header section, and then dividing the difference by
8 as there are 8 bytes per index file record.) Inspection of the .dbf
file in a word processor will indicate that there are only 27 records
present (the record number is listed at the start of each record). As
a result, the .dbf file reader read past the end of the file and this
caused the immediate grief. (There also appear to be the correct 30 records
in the .shp file). 3) I added error handling for this case, instructing
the program to return zero if the dbf read attempt failed. This eliminated
the fp error that was occurring during the dbf read cycle. 4) Unfortunately,
the file did not get much further as another fp error occured later during
the lsqr computation for reasons that I do not understand right now. At
this point, I am attributing the problems to a faulty or corrupt input
file. As for the problems with the USGS ASCII output file, I can not offer
much help since I do not have the input file to test. I have attached
a simple ASCII input that you can run if this is any help. This file both
runs and produces a file readable by 3DEM. The ASCII file writer is one
that I have used in several programs previously includeing GEOTIFF4 so
it should work fine. It is not necessary that the file be any particular
size or even square in order to work properly. A couple of things to try:
1) I am assuming that you selected 'USGS ASCII' and not 'ASCII' for the
output. 2) I used WinTopo Pro v2.5 to generate my test files. If you have
an earlier version, you might try downloading the latest version. 3) I
uploaded a revised BLACKART to the web site in which I included the source
.tif file for the shape file. Try loading the test file and experimenting
with it. Perhaps this will help you get your own files running properly.
That is all that I have for now. If I think of anything else I will let
you know or post it. John
The image is a simple example to try it. Sorry if my
english is not well, when I make a DEM from WinTopoPro and put in the
BlackArt throw and error. Do you know what I make bad? Thanks for all.
PD: And one another question, Do you know where I can download a Spain
DEM with 30m precision?. I search it but I only find GTOPO30, DTED 0 but
the precision of this files is badly. Regards.
Marc: Su ingles es mas mejor que mi espanol. Hablo solamente
unas pocas palabras de espanol y no puedo escribir tambien. The problem
is that your input file is corrupt. Specifically, the .shp file says that
there is only one row and one column in the input file, and sets up the
input array accordingly. When the program subsequently tries to write
all the data into the array, it over writes the array and causes the error.
The problem seems to be with WinTopo. This can be seen if you try to reload
your input .shp file back into WinTopo. A similar exception results and
WinTopo crashes. I do not know what it is about the geometry of your input
file that WinTopo does not like. Try another file and see if your luck
is better. Regarding your question about Spain 30m DEMs, the only source
is ASTER. Check the ASTER coverage map at http://edcdaac.usgs.gov/aster/dem_map_fullimage.html.
A few DEMs of Spain are available. See my website for full ASTER instructions.
Best regards, John.
My name is David Maldonado and recently I have finished a
mesh terrain scenery of my country Venezuela, using data SMRT. I used your
program BLACKART to correct these data. I think that it's the best tool
that exists for this !!. In this respect I have some questions about your
program that I would thank a lot if you can respond them: What it´s the
meanings of LSQR? When I should use the LSQR Iterations? Is it good to use
LSQR Iterations and Laplacian Iterations at the same time? in which proportion?
How can I generate files DEM that can be processed directly by the Microsoft
SDK tools ? How can I visualize the coordinated X Y (lat, long) of a point,
while I draw an elevation?? Thank you, for your excellent program BLACKART
Greetings, David Maldonado
David: Thank you for your email. The point
you ask about is a little difficult to explain but is an excellent question
I will try to discuss in some detail. The following discussion relates mainly
to the problem of interpolating contour lines to DEMs. Filling holes in
DEMs is a different sort of problem and is discussed separately at the end
of my comments.
In general, BLACKART formulates the interpolation problem
according to the Franklin approximation algorithm by setting up a large
number of simultaneous linear equations, one per elevation node. The equations
are simply the Laplacian stencils (not to be confused with the Laplacian
solver discussed below), which simply says that each node is the average
of its four immediate neighbors. Then another set of equations is added
to the list, which says that each contour line node is equal to the elevation
of that contour line. This will always yield more equations than unknowns,
which of course has no exact solution. The Franklin algorithm then says
compute the "best" solution using a least squares approach. The LSQR algorithm,
which is a well-known iterative least squares solver developed by Dr. Saunders
and Dr. Paige at Stamford University is used to do this. LSQR is an iterative
solver so it starts with an initial estimate of the solution vector and
uses the initial estimate to compute the next iteration of the solution
vector, and then repeats until a solution of sufficient precision is achieved.
The closer the initial estimate is to the solution vector, the less iterations
it will take to compute a solution (actually an approximation rather than
an exact solution) if the process converges.
The solution computed by LSQR
yields a very good interpolation because of the way that the Franklin algorithm
formulates the equations. By this I mostly mean no terracing, although the
Franklin algorithm also avoids other unwanted artifacts as well. If no initial
estimate is supplied to the LSQR solver, it will simply use the zero vector
as its initial estimate and go from there. However, one of the problems
with this is that it can take a long time to converge to a high precision
solution. I determined during the course of my tests at RPI that the solution
time can be greatly reduced if a good initial estimate is supplied. I found
that the best way to estimate the initial solution is to use what is called
a Laplacian solver.
The Laplacian method formulates the problem similarly
to the Franklin formulation except that the nodes are not required to equal
the average of their four neighbors and to the contour elevations simultaneously.
This results in a system where the number of equations exactly equals the
number of unknowns, which can be solved (directly) much more quickly with
much less storage. The interpolation it computes is not very good for producing
a finished product when you are interpolating contour lines. However, it
is quite good for use as an initial estimate. (Many other interpolation
utilities use the Laplacian as their sole solution algorithm.) As a result,
the optimal solution time can be obtained by first running the Laplacian
solver to compute a good initial estimate, and then supplying this initial
estimate to the LSQR solver for the final interpolation. BLACKART will ask
you how many of each type of iteration you wish to run. There is no exact
formula for the optimum combination of each type. In general each Laplacian
iteration computes ten times faster than the corresponding LSQR iteration
so it usually pays to run a sufficiently high number of Laplacian iterations
and then run "enough" LSQR iterations, as judged by the result. You can
tell that you are running sufficient Laplacian iterations by running zero
LSQR iterations and then looking at the result. If it looks like a reasonable
DEM, you are probably running enough.
Because it is so fast, the Laplacian
solver is pretty good for jobs like patching holes in DEMs. In this case,
artifacts like terracing due to contour line remnants are not an issue and
the Laplacian solver often does very well with no LSQR iterations at all.
The LSQR may give a smoother interpolation but I would always try the Laplacian
first with zero LSQR iterations as this may be good enough. See additional
comments below. >
What it´s the meanings of LSQR? See above.
When I should use the LSQR Iterations?
Principally when interpolating
contour lines. When patching DEMs it may not be necessary to run any LSQR
Is it good to use LSQR Iterations and Laplacian Iterations
at the same time? in which proportion?
When interpolating contour
lines it is always advisable to run both at the same time. BLACKART will
first compute a Laplacian solution using the specified number of iterations
and then automatically use the result as the initial estimate for the LSQR
How can I generate files DEM that can be processed directly
by the Microsoft SDK tools ?
I am not sure that I understand the question
but if you save in .bsq format your data will be stored in a flat binary
I16 format which is easy to machine process.
How can I visualize the
coordinated X Y (lat, long) of a point, while I > draw an elevation?
Right now BLACKART does not report this but you can infer it. An SRTM file
has 1201 rows and 1201 columns and spans one degree of latitude and longitude.
So each screen unit (which is reported) is exactly 1/1201 degrees. I may
add a feature to report this over the weekend. Editor's Note: This has since
I am a student at the University of Delaware majoring
in computer science.
For my Object Oriented Software Engineering class project I put together
simple .bil file 3D viewer using OpenGL. THe viewer works in the sense
that it can dynamically display (rotate, zoom, translate accross the
file) the 3D data at a fairly reasonable resolution with smooth shading
and lighting. I am currently reworking the project a little for my own
enjoyment and I came across your site today looking for more info on file
formats. I first would like to say that your site has been more helpful
then the USGS as far as I am concerned. I wish I came across it earlier.
I was wondering if you would be interested in answering a few questions
have regarding the different file formats.
I used the .bil format for the project and I was successful at correctly
displaying the model but I'm unsure what elevation each point
represents. I understand from the metafile that (at least for the file
was using) each point is represented as a 16 bit integer in meters and
average elevation was around 1500. The file was one of the samples of
Louis. From other sources I determined that the average elevation was
500 feet MSL so what point does the .bil file measured from? Have I
misunderstood the documentation? Also, the files seem to be also offered
a floating point format, where can I obtain exact representation of the
I would like to make this program as robust as possible. Should I be using
a different file format other that the .bil? The program just needs simple
elevation in raster file format. Do you have any suggestions?
I had never heard of the .bil format before your email so I had to look
up to see what it was. I was unable to find anything that definitely
answered your question, unfortunately.
I do not think that your problem is the result of some odd vertical datum.
Elevations are almost always measured with respect to MSL or to some
geoid-based datum. These do not differ from each other by anything
When I create image-type files from DEMs I always perform a linear
transformation of the elevation data so that the minimum elevation in
particular dataset maps to zero and the maximum maps to a value defined
the upper boundary of the integer space of the target file format.
example, if the elevations in the target file are to be represented by
byte unsigned integers, I map the minimum elevation to zero and
to 65,535. (Actually, I might reserve 0x0000 and 0xffff for various
and span some subset of the available integer space.)
An unmapped image will be equivalent mathematically to the mapped image
the unmapped will look odd if it is a viewable format like GIF or TGA
the elevations happened to be between 250 and 500, for example.
smoothing function imposed by the target application will have more to
with if the elevations span the entire integer space. Often the
application is not particularly interested in the absolute elevations
and allows you to scale them arbitrarily for best appearance. Perhaps
is what happened to your data.
When I do this I usually report the slope and intercept so that the image
integers can be mapped back to the source elevations if this is necessary.
You might experiment if you have some known elevations and see if you
infer the slope and intercept of the transformation function. Hopefully
is not some more complicated offset. Or perhaps there are mapping
parameters hidden somewhere in the metadata of your file.
As for the file format question, USGS SDTS format is the most important
far as I am concerned because DEM data for all of the United States is
available for 30m and 10m resolution in this format. The problem
SDTS is not a fixed-format file and is very unfriendly to programmers
compared to every other format. An SDTS profile consists of 18 .ddf
modules, many of which contain information that is required to display
image. You have to parse the Data Descriptive Record of each file
interest in order to get information about the Data Descriptive Area in
order to get information about the Data Record. The structure is
complicated and the USGS has done a horrific job of documenting the format
when you consider all the money that has been spent on creating it.
As for your question about floating point I assume you are referring to
.bil file. You need to find the file format specification that tells
how to decode the FPs because there are different ways to represent them.
Almost everybody uses IEEE 754 format but they can be 32 bit or 64 bit,
endian or little endian so you will have to do some digging on the
to get a definitive answer.
My name is Joachim I am webmaster of German GPS Software
TOURATECH-QV. We integrated the possibility to add the Globe data to
our software, so one gets an elevation value as the cursor cruises
over a loaded topographical map.
I confess I know nothing about those various elevation file data
formats, and the amount of different formats available is more
confusing then enlightening me. SO maybe my question is obvious or
stupid, but I hope for an answer: We tried to integrate reading/using
those USGS/Canada DEM/CDED data too, but found out that this format has
significant disadvantages in online processing during use of a map.
Below you find a link to the sample files of Canadian CDED Data:
So my question: Is there a tool (maybe commercially) available to
convert DEM/CDED data to Globe format including output of the
*.hdr(ESRI) header file ?
I hope this question is not too stupid and that you find the time to
send me a short answer.
Thank you very much for your help !
I did some investigation into your request and discovered the following:
The CDED file format is the same as the USGS native DEM format so there
lots of programs that can read this type of file directly and output files
of various other formats. Unfortunately, the GLOBE format is not
them. Building a GLOBE file is fairly easily and the directions
on the GLOBE website. However I think that it is not practical
convert DEM files to the GLOBE format because of a basic compatibility
problem: USGS DEM files can have a variable number of rows and columns
elevation data, for example 1201 rows by 1201 columns is a common
arrangement. But according to the information at the GLOBE website
files cannot. There are only two types of GLOBE tiles allowed I
type has 10800 rows by 4800 columns and the other has 10800 rows by 6000
I did not see any information that would allow for varying the numbers
rows or columns. GLOBE readers probably decode the tile name (for
B10G) and determine which of the two possible tile types to expect from
lookup table. It is then a straight forward job to read the signed
integer data stored in row major order (all the data for row one, followed
by all the data for row two, etc.) once you know how many columns there
I can find no provision to store 1201 rows by 1201 columns in GLOBE format
unless the file is padded with 41,757,599 zeros, or unless lots of DEM
were packed into a single GLOBE tile which is probably not practical.
Perhaps you can convert the CDED format to some other format that is
friendly for data processing in your application. It is possible
DEM elevation data very efficiently in TGA format, for example as one,
or three byte unsigned integers, either compressed or uncompressed.
written a couple of programs to convert DEMS to this format because many
rendering applications can accept elevation data this way. The problem
this approach is that the metadata is lost. I believe GEOTiff format
overcome this problem by accommodating metadata, as can SDTS, MicroDEM
.TER and some other formats.
If this does not confuse you more and you would like more information
of these alternative file options, please write to me again and I will
information on a specific format.
I do have a problem. I downloaded a file of data
for Namibia from the GLOBE site. (not a tile). Unpacked (using microDEM
not WinZip) I got three files .hdr, .fmt .bin. Tried to import into microDem
but keep getting "Invalid floating point operation" error. I've
tried extracting various smaller chunks but get the same error. Data looks
OK in a binary editor.
I also downloaded the entire southern African tile.
(going to have a big phone bill) but when I try the compressed tile .gz
microDEM crashes altogether.
This file is OK as it opens fine in 3DEM.
I have no experience with GLOBE data as I prefer the
NIMA DTED0 dataset. I extracted the following instructions from
GLOBE 30 sec DEM
GLOBE is a global digital elevation model (DEM) with
a horizontal grid spacing of 30 arc seconds (approximately 1 kilometer).
It used both DTED Level 0 and GTOPO30, so it might be superior to those
You must download the data, and the GEO-VU headers,
to use the GLOBE data.
You must do an import of this data set before use.
You will have to subset the files for this data set
before use. The 100+ MB files GLOBE uses are too big to manipulate
and display efficiently. If you wanted to see the “big picture” you
should use a data set like ETOPO5. The import automatically does the
If the data is correctly subset, it will use a DIX index
file and support merge on the fly operations.
GLOBE is available on line at:
GTOPO30/GLOBE Data Set Import
GTOPO30 and GLOBE are global data set of land elevations
with 30” spacing.
Select File, Data Manipulation.
Select Import, GTOPO30.
Select the file you want. They are named based on
the NW corner; you will pick the HDR file and the program will open
both the header and the accompanying DEM file. The window will show
the corners of this data set, and the maximum size DEM that you can
import. If you need a DEM covering a larger area, you should consider
a smaller scale DEM like ETOPO5.
Select the NW corner you want.
Select the SE corner you want.
Give the file a name.
The import will be done, and the program will show
you the directory where it was written.
If you need a larger area than will fit in one DEM, you
can extract pieces using the steps above, thin them, and then merge the
If you need an area that spans several files from GTOPO30
or GLOBE, you can extract pieces using the steps above, and then merge
the resulting files.
ETOPO, unlike GTOPO30 and GLOBE, has elevation data over
both land and water. GTOPO30 and GLOBE cover only the continents.
Have you tried these instructions already? If so
let me know and I will try to think of something else.
What an amazing web site you have. I am interested
in producing maps in
western Canada that show terrain relief and shading. I have a software
program called Surfer that allows me to import DEM's and then create DTMs.
These can be shaded to build relief maps etc.
Have you been successful in building the maps you show in Canada?. Are
available here? What I would like to be able to is build the kind of map
Canada) that you have shown in your section on 3DEM Overlays.
My objective is to build an map of an area with UTM co-ordinates and then
provide a trail through the area for backcountry use with GPS.
Thanks for considering my questions and for the great site!
You can build digital terrain maps for Canada. Unfortunately the
government, like most of the world does not yet make its spatial data
available for free. You can purchase DEMs in CDED format, which
the same as USGS ASCII native DEM format at :
Any application that accepts USGS ASCII DEM should accept CDED format,
including some of the converters on my page.
Here is another link for free DEM data for the Yukon Territory:
You can always get GTOPO30 or NIMA DTED0 data for free, but the resolution
is poor at 1000m postings. Look for information on my page.
You can probably find more sources by exploring the web.
Hello, I'm having a problem with all of the converters
I have downloaded from your site, and they all respond with cannot open
file. I'm running win98 with a 500mmx processor,128 meg ram. Can you help
None of the converters will accept a file name with
greater than 8 characters. Rename the input file using Explorer
DEMs from Imagery
I was wondering if you could steer me to information
on how to create
DEMs from imagery. Are there any software products out there, for a
relatively low cost, that can perform that kind of conversion? (I'm
guessing that the big GIS packages might have an interactive module for
creating elevation products, or DEMs).
My friend Paul recommends the software from PCI Geomantic. You can
look at http://www.pcigeomatics.com/.
He told me the software runs $800,
which is a lot but not out of line with first rate GIS packages.
this package is pretty much the standard.
I tried to look at Virtuozo, an application offered by a Chinese company.
Their website is at http://www.supresoft.com/.
They appear capable and
offer a free demo but I was never able to get set up with their license
because of a network card id problem so I do not know how it works.
DEM to Contours
I frequent your interesting and informative
website from time to time on the search for useful software and new developments.
I wonder if you might be able to point me in the right direction in my
search for a freeware / shareware software pack which could do the following:
derive elevation contour sets from DEM data
output these contours to .SHP files compatible with Arc View
Will look forward to a reply and please do keep up the great work
on your webpage
It's not exactly free (~$130.00) but GlobalMapper is the only program I
know that will (probably) do the job. You just load up the dem and
click "generate contours", then export shapefile, selecting "export
lines". You might send Mike Childs (no relation) at GlobalMapper
an email and check this out with him. I have attached a sample contour
and shape file generated by the program.
I need to obtain DTED level 1 and DFAD level 1 data
for Japan. Specifically,
N39 E139 to
I work for a company contracted by the US government to produce terrains
flight simulators. Getting the required government approval is not a
problem, paying for the data is not a problem, FINDING the data in the
proper format (DTED, DFAD level 1) is proving to be a problem.
Any assistance you provide, (a point in the right direction?), would be
Thank you for your time, in the mean time I'll be digging through your
pages and references.
I'm still a newbie here, but I successfully retrieved some SDTS data
interest and want to convert it to DTED, because I have some sample OpenGL
programs that will take DTED as input.
How do I get from SDTS to DTED? What's the relationship between DTED and
Oh, on another topic, is there elevation data for Mt. Everest?
I do not know of any SDTS to DTED converter. DTED and
USGS DEM are similar in that they both contain elevation data and metadata,
but in different formats.
Both DEM and DTED are somewhat messy formats to read/write to. While
I already have a DEM reader that I use in other converters, I do not have
a DTED writer that I could combine it with to make a quick converter.
The file format specifications for both are available. Let me know
if you are interested in them and I will send you the links
There are many free and low cost viewers out there
that read SDTS directly. Why don't you see if one of
these will do the job for you. MicroDEM and 3DEM are
two examples. Their links are on my web page. A
little searching on the web will produce others. Let
me know if you need help in finding them.
As far as Everest data, the best available at this
moment is NIMA DTED0. I usually import the DTED into
MicroDEM and then go from there. Detailed
instructions for getting at this data are also shown
on the web page, in the International DEMs and Sinai
I am trying to find dted 1 data for the manchester
area of the uk. to use it for planning a private wireless network set
up between friends.
Do you know of any sites that I can download
this information for free? I have been trying to use radio mobile but
the data is not accurate
can you help?
NIMA DTED1 (90m resolution) is currently classified.
The best that is available is DTED0 (1km resolution) from NGA Raster Roam.
You might also check out the UK Ordnance Survey.
The data is not free but may not be very expensive. The advantage
is that it will be of excellent quality and accessible. I have included
the text of an earlier request regarding Ordnance Survey data for reference:
Do you know of a converter to convert DTED into
DEM files? I can't seem to find one.
The only application that I know that is able to read
DTED data is MicroDem,
available for free at
Unfortunately, this program only exports in a native MicroDem format.
wrote a converter called MDEM2DEM that is available from my website that
convert MicroDem to USGS ASCII DEM.
A big problem is that MicroDem "loses" most
of the metadata upon export.
The converter inserts dummy data just to get the image to render.
You must carefully
inspect the type A record in the USGS DEM file and insert the metadata
You might also look at NIMAMUSE at
have not looked at it myself but it might have an export format you can
Would you know if there is a freely available DEM
of the entire US, excluding Hawaii and Alaska? I am aware of the GTOPO30
site, but those are tiled, and several are needed to get the entire country.
I don't need high resolution.
If you want a DEM, the GTOPO may be optimal. I
believe that the ETOPO dataset is coarser (5') so you may want to check
this out. Here is a starting link:
If you just want a rendering, check out the National Elevation Dataset.
Like your site! Just wondering if you knew where
one could obtain some terrains in following file extensions, .DEM, . MAP,
and .PTT files of the same geographic area? I am part of flight
sim "development team" and we were curious to see if other terrains
could be brought into the game (Jane's USAF - Electronic Arts).
I noticed that some of the files that are available through the USGS were
brought into Microsoft Flight Sim. I also noted there were several
translator programs available to convert from one file type to the other.
If you are interested, the following thread is currently being weaved
at the following web-address:
We are basically looking for new terrains to fly over.
The game comes supplied with parts of Nevada, Vietnam, Germany and Iraq.
For each terrain type there is a) terrain tiles, b) the elevation component,
and c) an aviation grade map complete with airport locations, etc. for
larger scale navigation. We are looking for all three. Good
This is just a hobby for me, I am not a programmer
by any stretch of the imagination. Anyway, if you are at all familiar
about the terrains used in flight sims (or at least with the file extensions
I have given above), I would love to hear from you!
I took a quick look at the link you enclosed. From
what I gathered there and from your email the terrain data is in at
least two files. The DEM of course is the digital elevation model
which is just a regular grid in the xy plane mapped to a z coordinate.
It is typical to "drape" a (2D) raster image over the DEM in
order to add features to the otherwise stark landscape. This information
may be in the MAP and PTT files. If they are TGAs this would make
sense because this is a 2D raster format commonly used for this purpose.
There are several examples of this type of draped image on my webpage.
DEM data for the United States is readily available from
gisdatadepot.com. (again, see my site for the link). Getting good
raster data for the drape is a more difficult challenge. USGS land
use DLGs are commonly used, as are aerial and satellite images.
Artificially generated texture maps are also used.
You might try contacting Mike Heir at email@example.com.
He is a Flight Simulator type and he and I worked together to write the
DEM2BSQ converter to support the Flight Simulator community. Perhaps
he can offer some insight to your problems.
Thank you for your message and understanding.
Not knowing how vast and complex the problems with DEMs, I have been using
simple method of making dems in grey scale with PSP7. What
a wonderful new
world you have opened up.
I enclose one of my test .raw files which I use with Grises50 to turn
This one is 257x257 pixels and has 50 different grays. Darker at
altitudes and getting lighter as the hill rises. I test mine
dropper in PSP.
As I only do my own local scenery, different .raw files seem to work well
but I am up against a big problem in that FS2002 does not accept LODs
11. To overcome this I make a .raw 257x257 with a very wide
and the hill rises near the centre. This I turn into the DEM
and make the
lower level just under the Microsoft ground level where I am locating
hill. This seems to work. In experimenting with
different ground heights
one can lower the scenery in FS2002 with this type of procedure.
Thanks for your message. I do not know a lot about
FS but I worked with a
fellow named Mike Heir to develop MDEM2BSQ. The idea is to import
(from the USGS for example) into MicroDem, merge files if necessary, and
then save in flat binary format that he called .BSQ and may be the same
your .RAW format. He then uses these files as input to FS for his
Perhaps this would work for you. The advantage is that MicroDem
easily ingests many DEM formats.
I have been searching the Internet, and download
sites upon it, for a type
of bitmap editor program, with little success, when I arrived at your
website, and it showed programs that are closer to what I have been looking
for than anything else I have found, and I feel that you may be able to
understand the type of program that I am looking for and may be able to
me or suggest something.
I have been searching for a very basic type of bitmap editor which can
perform the sort of functions as these examples:
* Convert numerical data (either with direct input or text files) into
simple digital bitmap (.BMP) files: An input such as (255,255,255)
"FFFFFF" would result in a white pixel; "FFOOOOO",
a red pixel; a text data
could be loaded, in which text consisting of continuous "000000"
a "FFFFFF" field located somewhere within would ultimately result
program creating a bitmap consisting of a single white pixel on a black
* Convert bitmap files into numerical data; a blank white bitmap would
ultimately return data in a series of "FFFFFF" fields or usable
* Allow editing of individual RGB values of pixels and changing the color
pixels by changing red, green, and blue values independently; selecting
red pixel would bring up a dialogue box with information like this: "red=255
green=0 blue=0" and provide the ability to increase the green value
resulting in that individual pixel changing color from red to yellow
* Allow merging of bitmap files so that individual color values in pixels
would produce a pixel equal to the sum of the RGB values of the
corresponding pixels of each bitmap; if two bitmaps of like size (100x100)
were superimposed upon one another, and the RGB value at location 30,30
each bitmap was a dim red "770000", the result on the final
result in a bright red "FFOOOO" at location 30,30
The type of program that I am looking for is certainly much more basic
the ones shown on your web page, but it is because it is so basic that
have become as frustrated trying to find such a program. If you
know of any
simple program that offers any of the features I explained, please reply
with any suggestions. If you cannot help but know of someone who
able to, please feel free to forward this e-mail intact to anyone who
have suggestions or recommendations.
I hear what you are saying. This kind of integrated
I'm thinking that I will need a viewer to check the data against my topo,
and photo data. Then I will need a 3D tool of some sort to manipulate the
terrain elevation data, preferably some kind of program where I can see
the changes I am making in real time, (a GUI) rather than entering huge
volumes of tabular data into a database is preferable.
My questions to you are as follows: What kind of
viewers would you recommend for this project? What
3D rendering/ imaging/ manipulation tool would you recommend for making
slight adjustments to the USGS data? I'm already going to have to
buy one for making 3D objects for the game, (hangers dams, roads, runways,
bridges) so recommend several if you would, and I'll try to find one that
will work for both issues for me. Is there a single
tool that will extract, view, and manipulate the USGS data that I want to
import into the game ? The short answer to your question is that
I do not know of an application that does exactly what you are looking for.
I use hex editors like Ultraedit and Hexedit to do the kind of manipulations
you are talking about (but I do not do this too much because it is so cumbersome).
To do this I simply navigate around the USGS ASCII DEM file or the SDTS
xxxxcel0.ddf file making adjustments using the hex editor and then view
my results using an application like GlobalMapper, MicroDEM, etc.
There are some applications that try to do what you are talking about, applications
such as WebWinds and Noesys. These are aimed at processing satellite images.
I am not sure they will handle SDTS format. I have experimented with
them using geotiff and hdf files and they and the data are extremely
difficult to work with. The data is problematic because DEM files
are just so huge. Wish I could be of more help. I will think about
this a little more and if I come up with anything I will let you know.
would be a handy thing to have. I have never seen anything like
are describing. I wonder if the higher end Graphics programs like
Max, etc. have this functionality.
I have been able to do pretty much everything you described using some
simple tools. The first is the book called "Encyclopedia of
Formats by James D. Murray and William van Ryper". I use this
book to help
decrypt various graphics file formats. I can then use a hex editor
UltraEdit, hexedit or XVI32 to display each byte of the file in as hex
number. I can
then edit the file by hand. I often have to do this when converting
under-specified GIS format to a graphics format where I do not know what
orientation of the decoded file is, whether it is mirror-imaged, etc.
usually tag the file by setting a few dozen pixels by hand in my hex editor
and then inspect it using PaintshopPro.
PaintshopPro does not have all of the tools you are probably looking for
either, but it does have the ability to display the color palette, along
with the hex value of each color. You can also perform arithmetical
operations on files by combining color values of pixels and so on.
Sorry I could not be of much help but that is how I handle these tasks.
me know if you find anything better.
Actually, that program you told me about, XVI32, has been very useful
and I thank you for letting me know about it. I have been able to
manipulate numerical data using QBasic, output this data to a text file
cut-and-paste to a blank bitmap file, and I have this process working
It's allowed me to do some things I didn't think I'd be able to do (I've
found editing a bitmap using a text editor is impossible, for example).
also got me back to programming again, and I almost forgot how much I
Thanks for the beautiful and comprehensive article
about Digital Terrain Models that is posted on geocities.com.
In the part about IKONOS, you mentioned that you
have not been able to determine if IKONOS is capable of generating stereo
orthophoto pairs suitable for the production of DEMs. The answer
is that yes it can and companies and governments are indeed using it to
I have to correct myself here, IKONOS is capable of
collecting stereo pairs
of satellite images in two ways. The first one is the stereo coverage
resulting from the overlapping of two consecutive strips of imagery from
adjacent passes of the satellite over the same area. This kind of images
available to the public. The other kind of stereo coverage that
sensors offer is a stereo that is within the same strip. This is
by collecting the image captured by the first line sensor, then separately
collecting the image captured by the third line sensor. This has
possible since the IKONOS camera has 3 bush-broom line sensors; the first
one is placed at a slight angle to look forward, the middle sensor
placed in a nadir position so it is always orthogonal to the terrain,
the last sensor is a back-ward looking sensor. The second type of
coverage is available only to Space Imaging and its government customers
can not be sold to the private industry.
Now we come to the correction part. I the geocities article you
"stereo orthophoto pairs". In fact stereo pairs of any
photography can be
utilized to produce digital terrain models (DTMs) that can be used to
rectify the imagery and produce ortho photos. Two orthos of the
even if they had the same scale, will not give you stereo coverage because
all the distortions due to relief displacement have been removed from
I'm working with ESRI software and Illustrator on
a map of a sub range of the Andes (Cordillera Huayhuash, Peru).
I am using mapublisher to import all my layers into illustrator. No
problem there. But I also want to create a shaded relief layer. Any suggestions
how to get that layer back into a drawing program and register it.
I've tried exporting an EPS greyscale DEM into
Photoshop and rendering it from there with OK results, I can get
a smooth looking terrain model that I can then use with hypsometric tinting
and shading underneath all my contours and line work, it looks superb
but... The problem is registration and the resultant size of this layer,
even as an 8bit grey scale it is extremely huge(50+ MEGs) unless
I drop the resolution and then it becomes very pixelated and not so good
for print output. Any idea how they got it to look so good on the Rainier
map. I think they are working in the same software environment as
me (MAPublisher). But maybe Op.Sys makes a difference PC vs. MAC? Or maybe
I am way of track, any advice would be appreciated and acknowledged in
I am not familiar with the applications that you are
using and your description of the DEM data type did not ring a bell either.
I am sure it is not the OS or computer that is the key to making a great
image. This is the way I see it:
1) A DEM is raster data of course and each elevation
posting is represented by a number that takes from one to four bytes to
represent. The size of the DEM as far as your application is concerned
is equal to the number of elevation postings times the number of bytes
per posting, plus a small amount of file overhead for any header information.
2) The overlay image is also raster data. Each pixel
is represented by from one to four bytes (usually) depending on the color
depth per pixel. The input file may be in a compressed state (RLE, etc.)
but it needs to be uncompressed by the application in order to process
it. The pixel topology of the overlay will not match the elevation posting
topology of the DEM, unless you manipulate things to cause this to be
3) To make the image, the DEM and overlay need to be
mapped one to the other. The application will maintain the overlay and
DEM data separately, and then should create a third object which is the
DEM/overlay rendering. This should be represented by a data structure
with size of, at most the number of bytes of the overlay, depending on
whether the DEM is mapped to the overlay or the overlay is mapped to the
DEM.. Presumably, some interpolation or sampling algorithm is used to
accomplish this. If the DEM is mapped to the overlay, this is good. If
the overlay is mapped to the DEM, this is bad because sampling or especially
interpolation routines cause distortion of your image.
4) If this image is exported, the file size will depend
on the characteristics of the image and the type of file chosen to represent
it (jpeg, gif, etc.).
5) As layers inside an application, a large amount of
data may have to be maintained in order to allow arbitrary perspectives
to be displayed. For example, a 1201X1201 DEM will require about 2.88
Mbytes at two bytes/posting. A 32 bit uncompressed TGA image of 1024X768
would require 3.14 Mbytes for a total of about 6 Mbytes of data.
Mr. Kitterman's image was probably 4MB.
6) There are other factors that come into play as well.
For example, what is the quality of the source overlay image? An inferior,
muddy image rendered using a large pixel count will merely faithfully
reproduce the inherent infidelity of the source image.
This is what I suggest trying in order to make the
best quality image:
1) Plan out the size of the target image carefully
and choose the DEM and overlay appropriately. Don't use such
large source datasets that manipulating them is too cumbersome.
Remember however that the final image will be somewhat to much smaller
if output in compressed format.
2) Scan your own topo map using the highest quality
3) Scan the image in at exactly the size that you
intend to use for the overlay. Any resizing of the image after scanning
will degrade it.
4) Match the pixel topology of the DEM exactly to that
of the scanned image. There are several ways to do this. One way would
be to write a program to manipulate and rewrite the DEM file but this
would take programming skills. Another way would be to convert the DEM
to a TGA, resize the TGA , import the TGA to POV-Ray as a height field
and then perform the overlay by using the POV-Ray utility for this purpose.
Your application may have a similar utility.
5) You are going to be working with large files for these
steps. Notice that Mr. Kitterman's image is only 448,422 bytes in its
final form but is 4.13 Mbytes when rewritten as a 24 bit TGA file..
6) Save the resulting image as a jpeg for maximum compression.
As far as registration of the overlay to the DEM, this
can be done by imposing small cues onto the DEM and matching them with
data on the overlay. (I give an example of this on my web
page under the Extended DEM). Hopefully things match well enough
because of your file prep so that these tweaks are minimal. At all
costs avoid "rubber sheeting" the overlay because you will lose
image quality. section.
Making an image like this is a lot of work but is probably
necessary to get the kind of results that Mr. Kitterman got.
Hello, my name is Ovidiu I.
and I visited your webpage. The area which
commanded my attention most was Mr. Kitterman's overlay. Could you tell
what software and data set he used? Any information would be greatly
appreciated. Thank you, Ovidiu.
I don't know much about the image other than the info
at the link
. The software is apparently MAPublisher 4.0.
Charles Kitterman works for Kulshan Cartographic Services. The topo
used was apparently one generated by that company. The DEM dataset
Thanks for your very informative and useful site on
terrain modeling. I
have been experimenting with 3dem and have a question: In the second
last paragraph of your Mt. Rainier Challenge section you mentioned looking
at the image in a straight overhead view rather than in perspective
view. How do you view it from directly overhead and also generate
shading? I can only seem to generate the hill shade showing terrain
select >operation >3d view but then I have to view it from an angle.
The overhead view requires a little trick to work easily. First,
view. Under the "terrain position" box select the "far"
radio button. Then
generate your image normally.
When the image has generated, select "Operation" and then "change
Use the "tilt forward" button to rotate the image to the overhead
National Elevation Dataset
I am working with 3DEM and would like to use NED
data that I can get from USGS (mentioned in your DEM starter kit).
problem is I can't get the NED data into 3DEM, what format do you recommend
I get from USGS? the options are Grid-Float, ArcGrid, or Bil.
It seems much simpler to use NED data where you can get a large area rather
than piecing together multiple dems based on quads.
.bil format would definitely be the one to go with. It is a very
byte integer format that would be a breeze to convert to something useful,
like USGS DEM for example. The problem is that there is no .bil
converters in existence that I know of. It is on my list to write
but I have
slowed down writing converters since school started for me.
Kim Kisner of the USGS told me via email that the USGS will be making
data available in SDTS format "soon". In that case, 3DEM
will be able to
read NED data directly. I guess you will have to wait a bit for
since you asked I might get motivated to whip up the converter in a hurry.
Keep checking my website and the USGS website for a solution one way or
other. If you want, you could contact Kim directly at Kisner@usgs.gov
more information regarding SDTS availability.
Any idea where one could obtain a specification for
the DTM format (Mars Digital
Terrain Model) or GTDR (Venus Global Terrain Data Record) format?
The document at
seems to be a good starting place.
If I was deciphering the format I would first read through this document,
then load an appropriate data file from the corresponding ftp at
into a hex editor
and see if I could figure it out. If I could not figure out the
these I would contact someone associated with the ftp and ask for help.
scientists that maintain these sites are usually pretty cooperative.
I got these links from
http://www.ccm.net/~jrsmith/dtm.html so contacting
Mr. Smith, who seems to have a lot of experience would probably also yield
Another possible link is the Mars
Polar Lander website.
Let me know if this leads anywhere in case someone else asks.
Do you know where I can find a DEM of the moon ??!!
I don't know of any source offhand but you could contact Dr. Margot at
and ask about how he obtained the
radar interferometery data from
Thank you for your excellent Digital Terrain Modeling
site. It's resources are excellent.
I'm hoping you can help me solve a *somewhat* unique
issue I'm having with converting DEM files into a
useable Photoshop format.
I promise I'll try and keep this as short as possible
but I must provide a little history for you.
Over the past two weeks I've been trying to solve the
issue of how to convert DEM files into a useable
Photoshop format so I can a create shaded relief
overlay for the trail maps I produce here in Colorado.
I'm on a Windows 98 machine and I use Macromedia
Freehand to produce my maps.
So far I've collected nearly every DEM utility out
there and so far no luck. I obtain my DEM data from
GeoComm.com in the form of the current USGS
SDTS-format 7.5' DEM files. Using SDTSDEM2 I convert
those pesky files into the "native" USGS DEM format.
From that point I've used the following apps with the
1) MicroDEM - Opens the DEM files perfect! Only they
show up in this little window that's 361x464 pixels
and I haven't been able to figure out how to export a
BMP, Tiff or TGA file that will match the physical
dimensions of a DRG file (GeoTiff) when opened in
2) DEM2TGA7 - Seems to run fine but when I open the
resulting *.TGA file in Photoshop it looks like orange
3) Wilbur - Same issue as MicroDEM
Am I going about this the wrong way?! Most of my maps
are output at a minimum size of 11"x17"! I must not be
doing something right. Can you give me a pointer or
I am going to be shooting in the dark a little because I have no experience
with Macromedia Freehand or Photoshop but here goes.
1) The typical SDTS 7.5' DEM has about 480 rows by 380 columns (plus or
minus) of elevation postings. Each elevation posting gets mapped
graphics pixel in a TGA or other graphics file. So the image size
MicroDem produces is exactly what you would expect. The larger scale
1:250,000 USGS DEMs have typically 1201 by 1201 elevation postings so
TGA produced by converting one of these would be about that size.
of course increase the size of these by image processing (resizing) but
an interpolation occurs between pixels to create the new pixels.
2) You can export graphics files from MicroDem by selecting 'Save Image'
from the main menu. You get to select from BMP, JPG or GIF format.
3) This is the third report I have received of DEM2TGA7 output files
being read by Photoshop, so I believe it now. I think this is a
with the Photoshop reader but have no easy way of resolving this because
do not have a copy of this program. (Anyone who has written a file
knows how difficult it is to anticipate all possible flavors of an input
file allowable under the file specification.) I do know that PaintshopPro
will read the output files from DEM2TGA7. You can download a demo
PaintShop for free (see link on my page), import the file, export it to
format (including TGA if that is what you need), and then read it into
Photoshop. I have recommended this a couple of times before when
problem came up and have had no reports of problems in doing it this way.
If none of these help, please contact me again.
I have been trying for the last 2 days to get 4 24K
DDF into Bryce 4 (Bryce is able to import DEM's). I finally figured
out how to merge the 4 24K DDF's in MicroDEM and it looks great.
Also, I exported the merged file into a DEM. Verified this by reopening
the merged file into MicroDEM. But, Bryce complains with "Bad
I/O" error when I try to import the new DEM. Bryce will import
any of the original DDF's . . .
Any idea on how to rectify this? Any help would
I would rather use a DEM as opposed to some
other file format . . .
While typing this, I realized I should just try downloading
some DEM modelers from ZDNET and see if they have a hard time importing
the merged DEM . . .
This is project for the chamber. I want to
start out with this small scene. Then, if I really have the ambition
and time, I want to do an animation/fly through of this area to put on
the website . . .
Question: You probably know this already but you
cannot import MicroDEM output files into Bryce directly, because MicroDEM
DEM format is different from USGS DEM format.
The second question is, if you converted the MicroDEM
output to USGS DEM format, how did you do it? Did you use my program?
If you could clarify these points I will supply more
Thanks for putting your web site together; it is a
You mention that MicroDEM will Merge two 7.5 min DEMs and indeed it behaves
as if it does. However, I am using a program recommended by the USGS (DEM
Works) to open the resulting file. DEM Works just ignores the file with
3D Studio Max is really where I would like to end up but when it tries
open the resulting MicroDEM 4.0 file it replies with "Improper file
Finally there are another set of programs that written by Sol Katz that
the information in a DEM called D2X1.exe. For the MicroDEM merged file
parameters all come back as zero and the program hangs on the MircoDEM
MicroDEM will open its own Merged file and display fine.
Do you know of a way to get a merged MicroDEM file in a valid format for
The problem is that a MicroDem .dem file is not the same as a USGS .dem
file. MicroDem outputs files in its own native file format.
(I am always
amazed by the number of different GIS file formats that exist. It
to get serious in this field without becoming somewhat knowledgeable about
file format conversions, or as one of my former programming teachers called
it "shoveling dirt", i.e. you take it from here and shovel it
According to my research, only two other programs are able to read a
MicroDem .dem directly: Daylon Leveller and DEMScape.
Regardless, I am hoping that the simple answer to your question is to
the "Save Image" selection in Microdem rather than the "Save
DEM". When you
use "Save Image", you get the choice of saving as a .BMP, .JPEG
This is what I have done in the past to create POV-Ray input files.
in MicroDem, import the DEM, save as a .BMP, import to Paintshop Pro,
then save from Painshop to .TGA format which POV-Ray can convert into
image. You should probably save the image in grayscale to get the
results. You may have to fiddle with the source image depending
initial MicroDem settings. Try to perform a "color merge"
"Modify" and "Display Parameter" settings and then
pick "Grayscale Map" from
the "File" menu.
If your target programs can handle one of these formats, you are home
If this does not solve your problem, let me know. I looked at the
.dem file with a binary editor and it looks pretty straight forward.
probably write a quick conversion from this format to any target format
Here is a link that has more MicroDem information from someone more expert
NDEM (South Africa) File Format
It was interesting reading about your Digital Terrain
Mapping and your
enviable knowledge on your deep understanding of the formats involved
highlighted on your Website.
I use the Metacust Ultra Version 2.05 3D environment. I am about to purchase
a particular terrain model from a supplier here in South Africa. Because
do not have a clue how these different formats will impact on my system
decided to ask the expert. Tell me, what are the specific format details
look out for in order for me to make a wise investment. I have a Silicon
Graphics SGI 02 Hardware running the IRIX version 6.5.7M Software and
to create animated graphics for weather presentations. I need to purchase
base map of South Africa onto which I should be able to use available
terrain data and weather data to achieve an excellent graphical
presentation. Now, please excuse me for my lack of understanding of the
various applicable formats, I need to know, what must be my prescribed
format? In other words, which format and or applicable rules must I watch
out for during this purchase? All I know is that my manual stipulates
"The DEM files usable for Metacust Ultra, need to be either the USGS
000 scale DEM standard format or they should be in run-time performance
optimized proprietary format , nDem." Please explain this.
Awaiting your most urgent response.
Please accept my apologies for the delayed reply.
I was on
travel this week and had a small backlog of emails related to the site
work through when I returned. Also, please call me John. Also, please
not call me an expert, which I am not. "In the land of the
one-eyed man is king" applies in this field.
From what I can tell from the information you related, you have few worries.
The application that you are considering appears to like two formats.
know the first one well so let me start with that.
USGS 1:250,000 DEM format (also known as USGS native format) is an old,
well-established format for digital topological data in the United States.
Although it is being superceded in the U.S. by the newer SDTS format,
many GIS applications read this format. In the U.S. at least it
something of a neutral translation format, i.e. you may not speak my
language and I may not speak yours but we both speak USGS native DEM.
is ironic considering that the USGS wanted the hugely complicated SDTS
format to serve this purpose.)
The format is ASCII meaning that it is human-readable. This makes
conversion from this format to another, if this should be necessary, a
easier. It will also be easy to transfer data across platforms (like
Windows to IRIX) since you do not have to worry about issues like
machine-dependant byte order preferences, etc. With all this
going for it,
there must be a down side, right? One is file size. ASCII
USGS DEM files
are going to be a lot larger than binary files. This used to be
before the era of cheap computing but is pretty much a non-issue today.
other is that it is becoming extinct as eventually the USGS will convert
their data sets completely to SDTS. (However, it will live for a
as a translation medium.)
If your application can read data in USGS native DEM format, you are off
a good start. It will not be able by any means to accommodate all
data out there but you will be able translate fairly easily anything that
you cannot read directly.
The link to the file specification can be found at:
I have no experience with the second so the following is conjecture.
appears to stand for National Digital Elevation Model. This is a
file format used by the Chief Directorate to Surveys and Mapping (South
Africa) for their DEM data set. You apparently purchase this DEM
directly from CDSM. When you do, you get a CD with your map data
While I was not able to locate the file specification on the CDSM website,
it is very likely that it is there or available from them. It is
as a raster file format, which essentially means that conversion of this
format, if ever necessary, should be straight forward. It is probably
The only thing that bothers me a little about your letter is the qualifier
"run-time optimized proprietary format" that precedes the reference
I hope that this is redundancy but you would do well to check with the
software supplier to make absolutely sure that the application can read
file format of your source data set directly and that this does not denote
some "improved" version of the format that your application
will choke on.
This is important because data for South Africa is going to be in NDEM
format for the most part. Conversions are pretty easy but you should
up front about any possible problems in reading your source data.
The link to CDSM where you can get information is:
I hope this helps. Write with further questions if it does not.
software supplier should be your most important source of information.
think you are in as good of shape as you can be in this field. Your
application sounds very interesting. I would like to learn of your
experiences so drop me a line sometime if you are able.
Ordnance Survey Data
My brother has just sent me details of your site,
which I was very impressed with. I am a landscape architect working out
of Yorkshire in the UK.
I am interested in doing some modeling with terrain
data available in the UK from Ordnance Survey. The data comes in 2 forms
- DXF and NTF. Which (if at all) of these two forms can be handled by
the software you use for modeling?
I am particularly interested in being able to use
the data to demonstrate change in the landscape - either land raising
or land extraction
You win the award for the most interesting question of
the week. I am not very familiar with the Ordnance Survey database
other than knowing of its fabled history.
I looked at the website, however and found a helpful
It looks like the NTF format is analogous to the SDTS format used by the
USGS here in the states. It has a versatile, free-format file
structure that is correspondingly complex. The DXF format is well-known.
The version used by the OS is the 3D variety, meaning it carries its DEM
data in xyz format. This is of very wasteful since the xy data constitutes
a fixed-spacing grid. It is of course only necessary to specify
the number of rows, number of columns and the spacing (along with at least
two geocoordinates). This is why data in the DXF format is so much larger
than the NTF version.
None of the GIS applications that I use, including MicroDEM
and Global Mapper (which are my most versatile) will accept DEMs in either
NTF or DXF format. I did some research and found two applications
that should get you started. Leveller at
http://www.daylongraphics.com/products/leveller/ and Maprender
at http://www.maprender3d.com/ claim
to accept NTF format so I would check these out and go with NTF
format if they worked. Leveller only costs around US$50 and there
is a free demo that you can try out to make sure it works. Maprender
looks like a nice program but it is more expensive. Hopefully one
or both will be able to do some of what you have in mind. (There
may be others more widely known in the UK. Check with the OS and see what
I hope that this will get you started. Write again
if it does not and we will think of something else.
I am currently working on a research project using
a DEM (Winfield, CO), and
aerial photos of the area, that have been scanned. I would like to
georeference the photos in order to drape them over the DEM. Do you have
suggestions on how to georeference the photos? I have not been able to
any existing georeferenced photos for the area.
Your website is very helpful! Thanks for the insight and direction.
You get the prize for asking the most difficult question
of the week. Or
maybe you win for picking the most out of the way location. Winfield?
That's a ghost town! I hope you get extra credit for your selection.
Only kidding. The location that you are working with certainly is
interesting one from a topographical standpoint. Close to Buena
of the annual FibArk whitewater kayak race, the famous Numbers rapids,
I checked the USGS DOQ directory to see if DOQs were available for your
of interest. Unfortunately, there is coverage for almost all of
except for a big hole over the Collegiate range - i.e. your area of
interest. You can take my word for it or check the coverage map
It would have been
nice if they were available because they are orthorectified, georeferenced,
I next checked Mapquest. They offer free aerial photos of some areas of
country, but not for Chaffe county, CO.
I then did a web search for commercial sources. There is lots available
the front range (probably recycled USGS DOQs), but not for where you are
I then tried satellite imagery. NIMA offers 10m DOIs but coverage
just south of I70, apparently outside your area of interest. You
this for yourself at the NIMA geospatial engine at www.nima.mil
as on my website.)
Then I looked for ASTER L1A satellite imagery from the EOS Data Gateway
They do not have any images
of your area of interest in their archive. You can order a satellite
overflight and get an image of Winfield, but it will take a couple of
Let me know if you are interested and I can tell you how to do it.
(However, ASTER has visible spectrum sensors so there is no predicting
cloud coverage you will get. ASTER may not even produce a useful
taken at this time of year.)
Then, I looked at the Space Imaging Quicklook site at
=08015 and found some images very close to your target. There are
available. I did not check them all but there does not appear to
exact match. However, depending on the extent of coverage of the
have, there may be some overlap and you may be able to infer some
coordinates by looking at the Space Imaging photos. They are all
georeferenced and orthorectified.
This brings us back to using the images that you have and trying to
georeference them using ground features. This is generally not as
it sounds because one mountain can appear quite similar to another.
I have used Paintshop Pro (Photoshop would probably do just as well.)
ground referenced overlays in the past. In this method you
DEM to .tga format and open it in Paintshop. Then you paste
as a new layer over the DEM tga. You decrease the opacity of the
that you can kind of see through it. Then by sliding the overlay around,
referencing ground features and resizing you can usually get an
(It is important to (re)load the original overlay each time you resize
because the interpolation algorithms will lose information each time if
do not.) When you are satisfied with the match you crop both
the DEM and
the overlay and save them separately. You then use an application
POV-Ray that can map the now perfectly matched raster onto the tga-DEM
height field to complete the job.
Alternatively, you might try using 3DEM and guess the corner coordinates.
If you are wrong, try keep trying until you get it right. This should
OK if you know the corner coordinates approximately. (There is a
command in 3DEM that is helpful in doing this job.) This should
by carefully comparing your aerial photos to the USGS topo map and guessing
at some approximate corner coordinates.
Anyway, I have not been too helpful but the short answer is that you can
definitely use your images if you work hard enough at it. There
is no one
correct way in this case but you should succeed with some patience.
know if anything is interesting to you and I can send more details.
I went through your web page.It is very informative.
I have a problem in
registration of satellite image with DEM images. The problem is my DEM
size is small and the satellite image size is big and my reference
image is the
DEM image. So if I do registration of DEM with satellite image then
getting a satellite image with reduced spatial resolution. How can
the DEM with the satellite image without reducing the spatial resolution
I am guessing that the problem is that your overlay software works by
mapping one pixel
of the overlay image to exactly one elevation value (and effectively one
pixel) of your DEM. When there are more pixels in the overlay than
are DEM pixels to map to, your software solves the problem by thinning
overlay image. This in turn results in a degraded overlay image.
The only solution is to increase the number of pixels in the DEM.
means either using a higher resolution DEM, or, if such a thing is not
available then artificially increasing the number of pixels by some type
I looked around for some combination of standard applications that would
the job and did not find anything. I tried saving a DEM as a BMP,
the DEM image upward in Paintshop Pro, then converting it to a tiff, then
importing it into GlobalMapper and then exporting it to an ASCII DEM.
did not work because GlobalMapper refused to take the tiff because it
not a Geotiff with embedded georeferencing information.
I think the only solution would be to write a program to resize the DEM.
This is a big enough job so that it would have to be a pretty important
overlay to justify the effort.
Sorry I could not think of anything better. If I do, I will let
We are in a process of evaluating the stability of
rock slopes is a part
of Saudi Arabia. We are interested in constructing a DEM map, a 3D DEM
and a slope category map from a 1:50,000 contour map. What software can
we use? Will ArcView or MapInfo help?
I looked into this problem as a way of getting DEM data
international locations. I am in the process of exploring this area
at the moment, and here is what I know.
In order to convert a contour map into DEM data you need to first convert
the raster data (bitmapped contours) into vector data (tagged vector
contours.) In order to do this, you must first scan your topo map
convert it to digital data, and then use a raster to vector conversion
program to create the vector data. There are several software packages
available to automate the task. I have used R2V from Able software.
not know what ArcView or MapInfo can do, but I would strongly recommend
you look at software that is designed to do this specific task, rather
a general purpose package.
After you do the conversion, you have to clean the image, repair the contour
lines and then tag them with the appropriate elevation values manually
a semi-automated fashion.
When this is done your program will automatically generate a DEM file
interpolating to grid points.
Let me tell you the bad news. In order to get good results you must
formidable job of cleaning the image. A typical contour map has
of information superimposed on it that will corrupt your results.
remove all conflicting lines that might be interpreted as contour lines,
such as roads, political boundaries, text, shaded regions,etc.
The contour lines, no matter how good your source image is will be broken
many places and will bleed together in many others. These must all
repaired (manually) or otherwise rationalized before you can use the data.
I am in the process of writing some preprocessing software that will help
clean and repair images automatically but am nowhere near done.
I have concluded that this task is virtually impossible and it is much
practical to locate or produce DEM data by other means. I will post
article in Spatial News in the near future to explain how this can be
Unfortunately, It will be a couple of weeks before I have all the details
worked out so that the process I have in mind is feasible. But check
my website for more on this problem in the near future.
Thanks for your prompt response on my email. I reached the stage you
stated by screen digitizing the raster map as I work on large scale
maps. I have the contours in a tagged vector form. Will the R2V create
the DEM then?
Well, R2V will generate the DEM. I just have the
free demo version of R2V
so my test bitmap was limited to 250X250 pixels. When I ran the
generated what looked like a proper USGS native DEM file. Since
I never got
as far as you are at the moment in terms of a high-fidelity source file,
had to go back and work on that problem. However, R2V is set up
to take a
raster image, convert it to vector form automatically, and then it has
utilities for tagging the contours. (these utilities are great if
vectorized contours are continuous and do not bleed.) If you already
this work done by other means, I am not sure that you can easily import
vector data into R2V.
Your best way to answer the question is to download the R2V demo, subset
your input file, run it through the program and see what you get.
I emailed some questions to Dr. Wu already so
if you need some pointers in using the program I will tell you what I
I would appreciate any tips you could give me in the area of preparing
input file. I am trying to write a section for my web page to help
cartographers prepare DEMS from topos. The literature is sparse
area. I recently bought a book called "Machine Interpretation
Drawing Images" by Ablameyko but it does not seem to have too much
I know already.
I got the R2V and could not open the digitized map.
So I started from
scratch, scanned the image then use the R2V to create a vector file then
a 3D DEM. I found it easier to clean the unwanted lines in the scanned
image using the Photoshop software. Further cleaning was also necessary
using the RTV before the creation of the DEM. My problem now is that I
have a 3D DEM, a fancy one that I can animate, but could not have a 2D
DEM file. Any suggestions?
I am very well acquainted (frustrated) with certain applications
legal USGS DEM files and others choking on them. If you want a few
here they are:
Fortunately USGS DEMs are ASCII files so they are easy to read.
inspecting the file manually and comparing it to one that does work for
and try to find small but important differences. I find it better
to use a
hex editor like HexEdit (free download) rather than a word processor because
it shows you the exact position of each character in the file. It
to use small example files for this test.
Sometimes the application will reject the file because of missing or
inconsistent data in the type A record. This is the front part of
that has all the metadata. This is especially a problem when you
building a file from scratch as opposed to converting from another format
where you may not have all the metadata. Try to insert all the metadata
that R2V allows you to put in. You may want to try inserting other
manually (see HexEdit above).
The DEM file specification is available at
You can use
this to as an aid in examining your file.
How about opening the DEM in another application and then exporting from
there to your target. MicroDEM seems to be pretty forgiving in terms
reading DEMs, although its export capabilities are limited. (MicroDEM
open the R2V file, as will DEMworks). You could then save it as
DEM and then use my converter MDEM2DEM to change it back to a DEM and
your target will accept that version.
I told you this would be a pain. But if you really enjoy abuse,
extracting DEM data from satellite imagery.
Regarding your last email: Is the 'join' operation automated in R2V or
you have to manually draw all the little lines between each break?
In order to tag the contours, you need first to join the segments of
each contour in one line. You need to turn the line editor ON, select
all the line segments forming on contour and join them. Click View,
Overlays, Line IDs and start assign value for each contour. Sometimes
you still see few spots on each contour having a zero value. You need
clean these. After that from the file 3D data, you can create the 3D
DEM. I suggest you check the R2V tutorial file.
I tried to export the 3D DEM to IDRISI, but it wouldn't accept it. I'm
still trying with other software.
Before I start with the editing, I'll try other software.
I'll also ask
one of our GIS Department staff to help in the editing process. The join
operation is an automated one for the selected segments and does draw
line between each break. But you should be careful because it sometimes
creates un-needed lines. Each time you select a segment to join, check
and make sure that no other un-needed lines are added to your contour.
After you finish joining and set value for the contour line, you will
still see some points on the contour line that have zero values. You
need to delete them.
Hi I just read your web page and found it interesting. I have some DTED
level 1 files that have been created by digitizing bathymetry contour
but without inputting any depth data in between the depth contour lines.
what I am left with are DTED format files with depth steps let say -20,
-50, -100 and -200 meters like instead real gridded depth data. Many of
only have few depth contour lines (let say 4 or 5) over the whole 1x1
cell. I want to generate real gridded DTED level 1 without loosing the
location of the depth contour lines and shorelines. Meaning replacing
flat depth steps between contour lines by interpolated depths. What would
you think could be the best tool or approach to do so. I look at some
and I have installed MicroDem 5.1 beta version but didn't the good one.
It sounds like R2V from Able Software might help.
It will allow you to
import your data in raster or bitmap format, add information for example
tagging contour lines, and then output a DEM file.
The program will show up in your search engine. I am in the process
writing a web page section on how this can be done.
I found a lot of interesting information in your
I am just going to make some 3D models of several
bottom areas of the Baltic sea (as a part of my research project). I am
ecologist so GIS is more like a hobby, but it is very powerful thing to
visualize my ecological data. Unfortunately getting DEM or whatever data
on relief of the Baltic sea is a BIG problem.
So I decided to make my own. Just from simple paper
maps. But, I don't know what software I should use (keeping in mind the
fact it should be not too expensive). Could you please give me an advice.
Thank you in advance.
I have to do a DEM map in Idrisi. I have paper
maps with level curves.
May you tell me what is the best way to digitalize
the curve levels and transform them to DEM?
The best way that I know of is to use the tools in ArcInfo
to convert the raster contours to tagged vectors. This program is
very expensive (about USD 3000) and not easy to use but is apparently
the standard for this type of work.
As I mentioned on my web page, RV2 is less expensive
(USD 900) but requires more work to make the conversion.
I am not an expert in this area and the article on my
web page www.terrainmap.com tells
most of what I know about this subject.
Please could you help direct me to topo`s of the ocean
area around Long Island.
I do not know much about sea floor topography. The NOAA is probably
best source of data. Here is a link for you to explore:
GlobalMapper will read ETOPO2 data files which are available from the
These might get you started. You have to pay for both the ETOPO
MicroDEM will read NOS EEZ Bathymetry. A source for this data and
coastal bathymetry can be found at:
It seems like none of this data is free but it is not too expensive.
Hi, my name is Jody. I am trying to use some
DEM data I have downloaded off the web and am having a few issues.
Your web site has been most hopeful with information regarding DEM's as
well as file conversions, but I am still having issues with files I am
The highlighted file is the original, I have
unzipped the files and as you can see they all have the file ext. .DDF?
Do you know of a utility that will allow me to convert these to .DEM?
Any input on this issue will be appreciated. Thanks
for your help.
Download the utility SDTSDEM2 listed under the "News
and Information" section of my web page at
www.terrainmap.com Run it and type in the path and then the first
four numbers in the file name of the profile for example c:\DEM\9769
(unless the utility is in the same directory, in which case just type
in 9769) . The utility will query you for the output file name,
to which you should respond <path><filename>.dem, i.e. c:\dem\outfile.dem.
A file in USGS native format file will be produced.
Several of the .ddf files in the SDTS profile that
you downloaded contain information required by SDTSDEM2 to (re)construct
the USGS native DEM. After converting you can read the .dem
file with a text editor because it will be in ASCII format.
Can you tell me the difference between your two versions
of the sdts to
dem converter and the SDTS2DEM that comes with source code at version
.016 that was updated on 9/5/01 by Gregg Townsend (based on the original
sol katz code) and is available at www.gisdatadepot.com/dem/?
As far as the dem data goes, they are equivalent in that they both convert
the gridded elevation data in the xxxxcel0 file to a series of USTS DEM
type B records.
Differences would be in the metadata contained in the type A record.
may know, there are 18 SDTS files in the profile, each of which contains
information, some more relevant than others. My program dips into the
.ldef, lspdm, .iref, and ddsh files to extract such data and
into the proper fields in the type A record of the output .dem file.
Gregg's revision of the original Sol Katz program may be better than mine,
in that he may extract more of this metadata from the SDTS profiles.
problem is that even though his source code is available, it uses an obscure
(to me) standard library for handling the SDTS files. I was unable
figure out what was going on in that program so I decided to write
my own. I wrote my program is an extension of an SDTS reader that
for other purposes anyway.
Like I say in the disclaimer on my page, if your need is for
mission-critical output you had better write your own conversion program
that you know exactly what is going on. The weakness of my program
it does not extract all the available metadata from the SDTS profile.
some cases I insert default information in type A fields that I consider
secondary importance and that I know to be generally true for the USGS
However, there is a possibility that one of these more obscure fields
be in error of some input file throws it a curve. These errors are
obviously not important if all you are doing is creating images like I
I'm interested in combining GIS with 3D prototyping.
Are you aware of any
converters that are freeware that will produce STL (StereoLithography)
from DEM files?
Here's a high end version of what I'd like to do: http://www.stm-usa.com/
you may have seen these guys already. Pretty cool synthesis of a
technologies. I really just want to mill hardwood topo models.
Thanks for any pointers you might offer. And thanks for the freeware
converters. I'm a big POV fan.
I had communicated with Mike G. about STL format a while ago and
recently received a follow up email from him. I had been planning
an STL converter but I keep getting interested in other things and never
around to starting it. You might try contacting Mike and see where
up. Here is a copy of the email that he sent me.
If you don't have any luck let me know and maybe I can write a converter
quickly over the semester break.
Sorry about the delay in responding to your letter.
I found a shareware (fairly cheap) converter called "AccuTrans3D"
which can convert to/from many different 3D file formats, including
from DEM to STL. I have been using that successfully in making
some 3D topographic maps, starting out with Mt. Saint Helens.
Unfortunately, now it seems that the AccuTrans3D web site
is unavailable. In any case, I'm going to get Rhino3D soon.
Now my big problem is dust collection! Yech.
I just released a product which you might be interested in.
It allows extremely large images to be viewed on the web.
It's now available in a beta release at http://www.xippix.com/cooker
I am doing a final year project on the Sao Miguel
island of Azores.
I have been using arc/view and recently came across your website and thought
would be a good idea to do an animation of the area that I am studying.
however I am not to sure which extensions I am currently using. I did
digitize the contour lines, I had to scan in the image and proceed to
'trace' the contours and other features using ArcFiew.
therefore I would like to use the package Terragen, to create an animation
flyby, or just 3d visualizations of the area.
The problem being I don't know what file extensions are compatible with
Terragen, and what extension my files are currently in.
I can't find any data about this island on the Internet to carry out my
I hope that you can enlighten me on this topic and help me with a suitable
Your digitized image is probably in some type of vector format that is
incompatible with Terragen. In fact, Terragen requires its own unique
format for input data. This is called a TER file.
Your best method is probably to export your file from ArcView in some
of DEM format. Usually USGS ASCII DEM is offered as an option (although
do not know for sure whether Arc View can do this.)
Then import the file into MicroDem (see my web page for the link if you
not have it). Save the file as a MicroDem DEM.
Then use my utility MDEM2TER to convert the MicroDem DEM to TER format
MDEM2TER. I realize that this is cumbersome but it is the only way
Firstly, I apologies for the nature of this question
since it no doubt has
been answered before, but being a 3D newbie I'm still grappling with some
Like a lot of people, I have started my 3D terrain experience with Terragen.
I've played around and am beginning to produce some nice images
animations. However, what I really want to do is build a model of
Now I am aware that I need to download the relevant data. From your
I had a look at the NIMA website and seemed to find the co-ordinates I
need to create my model. The problem is, which format should I download
then how do I get the file into Terragen?
From viewing the pages on your website, I understood that the SDTSTER4
utility you created would allow for the export of .ter files. What
having problems with is using the information I get from NIMA so that
use the utility to convert it to a .ter file. Can this be done?
As far as I understand it I need a USGS 7.5' DEM file for the utility
work, but is that what the NIMA file is?
If you could provide me with any pointers to put me back on the right
I'd really appreciate it.
Terragen only accepts its own TER file format.
So you have to translate whatever your input is into that. NIMA
data must be first imported into MicroDem, merged, saved in MicroDem native
DEM format, and then converted to TER using my utility MDEM2TER.
Look at the Sinai Challenge section of my web page for further instructions.
You can go directly from SDTS to TER using SDTS2TER4
for US DEM data as you noted. Merging is not usually required in
Thanks so much for those pointers. I had completely
missed the Sinai
Challenge' section for some reason!!
Anyway, it all worked well, but I was really disappointed with the quality
of the data in that I could hardly even get the land forms to appear in
render. Is this just simply because the detail just isn't there
source? As a result I went to have a look at GTOPO30 and downloaded
that might be better.
Is this a fairly typical problem with international DEMs? Or do
you know of
any other sites that I might try? The problem is, the island of
only 17 by 23 KM!!!
I have been looking at your page, it's wonderful!
I purchased TopoUSA regional per your suggestion but
it is entirely too "rough" for my liking. I would like
to produce much more refined maps. My question is: I
can save alot of time if I can use the data cd in
TopoUSA since it has done the downloads and has the
data on it. Is there any way I could access the
information (it seems very cryptic)? If not I am going
to return the product since it is useless to me. I am
evaluating a product called Surfer 7 made by Golden
Software to use for my map creations. Do you know
anything about it? Thanks for your time!
I am sorry that I steered you wrong on TopoUSA.
I agree about the
limitations and do not use the program at all for my work, but I definitely
would use the maps thus created for hiking and camping. Perhaps
sell/give it a hiker. If it is any consolation I will insert your
into the page so that others will be forewarned. In my defense do
get a lot
of emails from people who are not exactly power users and really thought
offered a good solution for them.
I had the same idea about the data when I bought it. Unfortunately,
not stored in any type of conventional file structure that I have been
to get at. When I tried to open a file using my hex editor it just
up my computer. Even if I could open a file, the format is unknown
data is almost certainly compressed using an unknown compression scheme.
did a web search to see if anyone had decrypted it yet but came up empty.
I got an email once asking for a converter from DEM to Golden Soft Surfer
Grid format, but have no experience with using it at all. My experience
pretty much limited to the packages discussed on the web page.
I'm trying to import the SDTS files from www.gisdatadepot.com
into Vistapro. The program has a utility to convert the "old style"
ASCII USGS DEMs. When using your program mdem2dem the result looks different
than the ASCII DEMs I know from a while ago, and I can't convert it any
longer (3DEM doesn't like them either). The biggest difference I see so
far, is that the converted file has lots of columns with -9999 in it.
I hope you have an idea what I'm doing wrong....
Thank you for sending the files. Unfortunately,
I was not able to solve your problem right away. I unzipped your
file named "Bonita.dem" and looked at it using the text editor.
It looked normal. I tried to open the file using MicroDem, DEMWorks
and 3DEM. The file opened correctly in all three, as normal.
I have attached a rather large BMP screen shot of the 3DEM image in
case you do not believe me. I do not have a copy of VistaPro so
I cannot run tests with this program.
I am using the 3DEM 8.4.1 demo version that I downloaded
from http://www.davecentral.com/5457.html very
recently. Are we using the same version of 3DEM? I think I
can get 3DEM70 for free. I will download this version and try the
import to see if this is the problem. I notice that the ny-e
file that you sent me is a 1:250K DEM. DLGV-32 from the USGS has
the same problem of not reading converted 1:24,000 SDTS DEMS (both from
MDEM2DEM and the Sol Katz program SDTS2DEM) but reading the 1:250,000
unconverted DEMS successfully. DEM readers are finicky and sometimes
they will not read the file if only one flag in the ASCII DEM is set to
a wrong integer. Since MicroDem loses a lot of the Metadata I had
to set a lot of the internal flags for a 1:24000 UTM file. Perhaps
this is the problem.
For the moment, I am stuck until I can run some additional
tests. Try downloading the 3DEM demo from the link above and loading
Bonita.dem. I will write back to you when I have more information.
I downloaded 3DEM70 from
http://www.simtel.net/pub/pd/6700.shtml. This program also rendered
your file Bonita.dem successfully. I just entered <File><Load
Terrain><Digital Model>, made sure that the file type was set
to <USGS DEM or GTOPO30 DEM> and then clicked on the file.
It loaded perfectly. The rendered image is attached.
I also downloaded the demo version of VistaPro.
This program is looking for a VistaPro native DEM (which is different
from a USGS DEM) or a V4s file. The demo version would not load
any of the USGS DEMS, including ny-e.
later, Klaus wrote...
First of all, you're right, I can read the dem file your
program creates with 3dem. Sorry for the mistake.
For my (unsuccessful) test reading the SDTS dems I used
3dem Version 8.4.4. The program starts reading the sdts and asks for a
dem file to save the converted data to. After the conversion 3dem tries
to read in the dem file and gives a "Incompatible File Format"
error message. When looking into the file, it has some values like 4.512D+006
in it. I thought, that this might be the problem I have. I downloaded
version 10.0.5 like you suggested and this one could read the sdts,
but doesn't write an ASCII dem....
So there still seems to be a difference between the
"old time" ASCII dems and the new ones. Those created by your
program can be used with 3dem, but not with Vistapro. The way of reading
a sdts with 3dem to get an ASCII dem, Vistapro likes, results in this
"Incompatible File Format" message.
So I still need to find out, what has changed. I attached
the conversion program, which reads the ASCII dems and writes the Vistapro
dems to this mail. Maybe you can figure out, what the tool doesn't like.
Hello, could you say me how can I convert a VISTAPRO
to a USGS DEM ?.
Muchas gracias para sus dos cartas.
Busque en el Internet por el dato tecnico del archivo
de datos de VistaPro.
Noticias buenas: descubri el dato tecnico basico
facilmente y rapidamente. Noticias malas: el dato
tecnico no inluyo la informacion del algoritmo para la
compression del archivo de datos, se llama "run length
compression" en ingles. Busque muchas horas en el
Internet por este informacion pero no tuve exito. Es
necessario a obtener este informacion para hacer la
programma a leer el archivo. Se aparece que el
algoritmo es un secreto commercial.
Escribi a el autor de la programa y lo pregunte por el
algoritmo que desiero. Espero que el lo respondera
pronto a mi peticion.
Muchas gracias a me permite a practica me espanol con
usted. Usted sabe, hablo solamente unas pocas
palabras de espanol.
y Arturo escribe...
Hola de nuevo, antes de nada felicitarle por su buen
de Castellano (Español).
Cuando le pregunte por un conversor de VistaPro a USGS DEM,
era porque necesitaba introducir un DEM que cree de una
parte de España en el programa World Construction Set, ya he
solucionado ese problema, ya que he encontrado en la WEB
un conversor de
VistaPro DEM a STM, y World Construction Set acepta este
formato sin problemas.
Ahora mi problema es saber como hacer funcionar el World
Construction Set ya que no tengo ningun manual.
Le envio un archivo que me dejo un amigo de las Islas
Canarias (España)en formato XYZ, tengo problemas con el ya
que World Construction Set no me lo acepta, podria darme
alguna idea de como poder trabajar con el.
I just started digesting you Digital Terrain Modeling and Mapping using
DEM,SDTS, DRG, DLG and DTED Data and think its great.
The first terrain modeler I used was Vistapro and I still like it. The
problem with it is finding data. I would like to take advantage of the
current SDTS data and can do it indirectly by producing a shaded contour
map which vistapro can read. This is really pain and I would like to go
directly from SDTS to the VistaPro DEM file or the old USGS DEM file for
which there is a Vistapro DEM converter. Can any of the SDTS converters
XYZ To ArcView
Are you aware of any xyz to dem converters. I have
three columns, east, north and elevation and would like to generate contours.
Thanks in advance,
I am not aware of any. The problem in general is that standard DEM
file formats require a bunch of metadata. A raw xyz grid file will
not have this data and so a converter will not know what to put in the DEM
file fields. This question came up from another person just last
week. As a test I tried converting an xyz grid into a tiff format
and then asked GlobalMapper to read it in as if it was a Geotiff.
The read went OK but I was not permitted to write the file because there
was no metadata keys.