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.

3DEM

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 SDTS
data through the SDTS2DEM converter application with the resulting file
named greeley.dem. Then I go to 3dem70 and click on "load terrain -> digital
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:

 <<greeleydemscreenshot.jpg>>

Can you help me understand what is going on? Is this somehow corrupt data?
Furthermore, it seems that 3dem70 does not have the "operation -> apply
overlay" function. Is this correct?

Your DEM file is apparently corrupt.  I do not know how it got that way.  I
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 file and
I looked at it in hexedit and could clearly see that all the records were in
the right places but the elevation values were nonsensical (47,000 meters,
etc.)

SDTSDEM5 creates large temporary array data structures from heap memory so
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 if
maybe there is a memory page size setting problem or some similar issue.  I
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, except
that it took forever to create the 3D view because of the size of the file
(9MB).  (30m dems are much more render-friendly.)

I have attached my output file called mygreely.dem.  Try loading this into
3DEM70 and make sure that it works.  You could then try comparing it to
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 I can
possibly figure out what is going on.)

You are technically correct about the overlay selection.  In 3DEM70, you can
do an overlay but you get at it a little differently.  First generate a 3D
view using 'View Scene'.  Once the scene has rendered, choose 'Operation',
'Modify Textures'.  A window will come up.  The leftmost section will be
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 to get
the overlay utility to work properly in 3DEM70.  It always makes funky
overlays that are sort of semi-opaque.  The feature works perfectly in 3DEM,
however.  One used to be able to download a free 3DEM demo to try  but I
think the vendor has discontinued this offer.  However, the new program does
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.

Top

3DStudioMax

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 your DEM2TGA6  and 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.

Top

3DViz

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 file types:

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, .bmp, .gif

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. 

Top

ArcView

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. I
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 can
accept shape files and this is why I'm contacting you. You list a number of
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 and
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
Uinta Mountains.
 

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 in
order to import that type.

If not, here is the link to a
converter:http://www.engineering.usu.edu/cee/faculty/dtarb/SDTSext.html

Top

ASTER DEM

Thanks for your replies.  I checked out your updated
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 had a
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
embedded.

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 of the
embedded metadata.  The program also writes the metadata to the USGS ASCII
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 next big
focus area after I finish with the geotiff DEMs and I will be publishing my
findings then, hopefully around Easter time.

> 1) GEOTIF prompts for the UTM coordinates in decimal meters of the south
> west corner.  The metadata file lists four latitude and four longitude
> 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 with  the
first valid data  point but instead coincide with the first data point of
any type, in this case a missing data point.  That is, the coordinates are
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.  Do we
> specify the input projection as Geographic coordinates with the WGS 1984
> ellipsoid and then enter the latitude and longitude of the southwest
corner
> in decimal degrees as reported in the Metadata file with the output
> projection being UTM, with the WGS 1984 ellipsoid and the appropriate UTM
> 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 in bytes
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)
      3=WGS 84
      4=NAD 83
      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 bradams@usgs.gov 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 DEM
> format will it be correctly oriented as long as we did 1 and 2 above
> correctly?

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
>above
> 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 not ideal
for either visible imaging or DEM production.  My colleague Paul Burkhardt
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.  Heavy
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 cause
the entire DEM to be suspect.  The best I can suggest is to look at the
corresponding L1A image (or the browse image, but this is pretty small).  In
general arid areas will yield uniformly good DEMs while mountainous areas in
the winter can be a problem.

> 6) Is there anything wrong with people from other countries logging in and
> 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 from
foreign users, express extreme gratitude to the
United States government for providing data that is unavailable in their own
countries.  My data indicates that Italy, France, UK, Spain and Canada are
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 is
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 are
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 at
http://www.pcigeomatics.com/ (this is the program the folks at EOS use to
produce the DEMs you order.)  Virtuzo from Supresoft at is another  at
www.supresoft.com.  Neither 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 data files
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)?

Answer:
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.

Examples:

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


Question:
How do I collect Ground Control Points for my image?

Answer
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 exact
geographic coordinates of a certain location on the earth that is
identifiable on each of the stereo ASTER images (3N and 3B). Locations that
make good GCPs include easily identifiable road intersections or other
ground level stationary objects. We require at least eight quality GCPs and
they must be evenly distributed horizontally and vertically throughout the
image to produce a quality DEM.

Question
What is the difference between a Relative DEM and an Absolute DEM?

Answer
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
(GCPs).

A Relative ASTER DEM is generated by using only the satellite ephemeris data
and will yield a product with ground elevations that are quite near those of
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
ephemeris data.
 

I have a question with regard to ASTER DEMs.  First off, the process that
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 GCPs
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., in
BOTH band 3N and 3B).  When I downloaded the image and tried viewing it in
ENVI Freelook, I was not able to find where you can visualize band 3.  Do
you have any experience with this or how I can "easily" visualize band 3?

Thank you in advance for your help.  Your website has been a great help!

I have not done an absolute DEM myself but here is my opinion.

GEOTIF would not help you produce an absolute DEM as it only takes the DEM
already produced and converts it to USGS ASCII format for subsequent
rendering.  What you need to do is what you described in paragraph 2.

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 that I
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.
 

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?

Todd:

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).

John

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

Top
 

ASTER L1A/L1B

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 directory.

I was surprised to find out, that there were no corresponding *.tif files on the other server (152.61.128.25/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 ?
 

Dear Sirs:

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 edcdaac@usgs.gov

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 us.

Thank you and best regards,
Brandy

John added:

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.

Top
 

AutoCAD

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 formats.

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: http://www.cadenceweb.com/1998/1298/circles1298.html

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.

Top

BLACKART

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

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.

 bil Format

I am a student at the University of Delaware majoring in computer science.
For my Object Oriented Software Engineering class project I put together a
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 I
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 I
was using) each point is represented as a 16 bit integer in meters and the
average elevation was around 1500. The file was one of the samples of St.
Louis. From other sources I determined that the average elevation was approx.
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 in
a floating point format, where can I obtain exact representation of the file.

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 it
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 near
1000 feet.

When I create image-type files from DEMs I always perform a linear
transformation of the elevation data so that the minimum elevation in that
particular dataset maps to zero and the maximum maps to a value defined by
the upper boundary of the integer space of the target file format.  For
example, if the elevations in the target file are to be represented by two
byte unsigned integers, I map the minimum elevation  to zero and the maximum
to 65,535.  (Actually, I might reserve 0x0000 and 0xffff for various reasons
and span some subset of the available integer space.)

An unmapped image will be equivalent mathematically to the mapped image but
the unmapped will look odd if it is a viewable format like GIF or TGA if all
the elevations happened to be between 250 and 500, for example.  Also, any
smoothing function imposed by the target application will have more to work
with if the elevations span the entire integer space.  Often the target
application is not particularly interested in the absolute elevations anyway
and allows you to scale them arbitrarily for best appearance.  Perhaps this
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 can
infer the slope and intercept of the transformation function.  Hopefully it
is not some more complicated offset.  Or perhaps there are mapping function
parameters hidden somewhere in the metadata of your file.

As for the file format question, USGS SDTS format is the most important as
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 is that
SDTS is not a fixed-format file and is very unfriendly to programmers as
compared to every other format.  An SDTS profile consists of 18 .ddf
modules, many of which contain information that is required to display an
image.  You have to parse the Data Descriptive Record of each file of
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 the
.bil file.  You need to find the file format specification that tells you
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, big
endian or little endian so you will have to do  some digging on the Internet
to get a definitive answer.

Top

CDED/GLOBE Format

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:
http://www.cits.rncan.gc.ca/siteCITS/servlet/CITS?site_id=01&sessionid=&page_id=1-006-002-001

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 !
 
Dear Joachim:

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 are
lots of programs that can read this type of file directly and output files
of various other formats.  Unfortunately, the GLOBE format is not one of
them.  Building a GLOBE file is fairly easily and the directions are given
on the GLOBE website.  However I think that  it is not practical to
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 of
elevation data, for example 1201 rows by 1201 columns is a common
arrangement.  But according to the information at the GLOBE website file
format page: http://www.ngdc.noaa.gov/seg/topo/report/s11/s11C.html GLOBE
files cannot.  There are only two types of GLOBE tiles allowed I think.  One
type has 10800 rows by 4800 columns and the other has 10800 rows by 6000
columns.

I did not see any information that would allow for varying the numbers of
rows or columns.  GLOBE readers probably decode the tile name (for example
B10G) and determine which of the two possible tile types to expect from a
lookup table.  It is then a straight forward job to read the signed 16 bit
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 are.

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 files
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 to store
DEM elevation data very efficiently in TGA format, for example as one, two
or three byte  unsigned integers, either compressed or uncompressed.  I have
written a couple of programs to convert DEMS to this format because many
rendering applications can accept elevation data this way.  The problem with
this approach is that the metadata is lost.  I believe GEOTiff format can
overcome this problem by accommodating metadata, as can SDTS, MicroDEM DEM,
.TER and some other formats.

If this does not confuse you more and you would like more information on any
of these alternative file options, please write to me again and I will send
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.

Any Ideas?

I have no experience with GLOBE data as I prefer the NIMA DTED0 dataset.  I extracted the following instructions from  MicroDem v5.1:

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 data sets.

• 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 subset.

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: http://www.ngdc.noaa.gov/seg/topo/globeget.shtml

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 thinned files.

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 DEM's
available here? What I would like to be able to is build the kind of map (in
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 Canadian
government, like most of the world does not yet make its spatial data
available for free.  You can purchase DEMs in CDED format, which is exactly
the same as USGS ASCII native DEM format at :
http://www.cits.rncan.gc.ca/siteCITS/servlet/CITS/site_id=01&sessionid=&page_id=1-006-002.html
_id=1-006-002-001

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:

http://renres.gov.yk.ca/pubs/rrgis/data/data_desc/90m_dem.html

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.
 

Top

Converters

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 me out.

None of the converters will accept a file name with greater than 8 characters.  Rename the input file using Explorer if necessary.

Top

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 take a
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.  I think
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 key
because of a network card id problem so I do not know how it works.

Top

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

Top

DTED Data

I need to obtain DTED level 1 and DFAD level 1 data for Japan. Specifically,
N39 E139 to
N43 E144.

I work for a company contracted by the US government to produce terrains for
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
greatly appreciated.

Thank you for your time, in the mean time I'll be digging through your web
pages and references.

I'm still a newbie here, but I successfully retrieved some SDTS data of
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 DEM?

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
sections.

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
http://www.nadn.navy.mil/Users/oceano/pguth/website/microdemdown.htm.

Unfortunately, this program only exports in a native MicroDem format.  I
wrote a converter called MDEM2DEM that is available from my website that can
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
manually.

You might also look at NIMAMUSE at
http://www.nima.mil/geospatial/SW_TOOLS/NIMAMUSE/doc/apps/intro/intro.htm  I
have not looked at it myself but it might have an export format you can use.

Top

ETOPO5

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: http://evlweb.eecs.uic.edu/pape/vrml/etopo/mapurl.html.

If you just want a rendering, check out the National Elevation Dataset.
http://edcnts14.cr.usgs.gov:81/Website/store/viewer.


Top

Flight Simulation

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:

http://www.simhq.com/simhq3/sims/boards/bbs/Forum49/HTML/001864.html

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 luck??!!

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 heir@home.net.  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 a
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 into
the DEM.
This one is 257x257 pixels and has 50 different grays.  Darker at the lower
altitudes and getting lighter as the hill rises.   I test mine with the
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 above
11.   To overcome this I make a .raw 257x257 with a very wide darkest grey
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 the
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 DEM data
(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 as
your .RAW format.  He then uses these files as input to FS for his terrains.
Perhaps this would work for you.  The advantage is that MicroDem fairly
easily ingests many DEM formats.

Top

Hexedit

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 help
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) or
"FFFFFF" would result in a white pixel; "FFOOOOO", a red pixel; a text data
could be loaded, in which text consisting of continuous "000000" field with
a "FFFFFF" field located somewhere within would ultimately result in the
program creating a bitmap consisting of a single white pixel on a black
background

* Convert bitmap files into numerical data; a blank white bitmap would
ultimately return data in a series of "FFFFFF" fields or usable
(255,255,255) data

* Allow editing of individual RGB values of pixels and changing the color of
pixels by changing red, green, and blue values independently; selecting a
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 to 255,
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 on
each bitmap was a dim red "770000", the result on the final bitmap would
result in a bright red "FFOOOO" at location 30,30

The type of program that I am looking for is certainly much more basic than
the ones shown on your web page, but it is because it is so basic that I
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 may be
able to, please feel free to forward this e-mail intact to anyone who may
have suggestions or recommendations.
 

I hear what you are saying.  This kind of integrated editing environment
would be a handy thing to have.  I have never seen anything like what you
are describing.  I wonder if the higher end Graphics programs like 3DStudio
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 Graphics File
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 like
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 an
under-specified GIS format to a graphics format where I do not know what the
orientation of the decoded file is, whether it is mirror-imaged, etc.  I
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.  Let
me know if you find anything better.

Actually, that program you told me about, XVI32, has been very useful to me,
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 and
cut-and-paste to a blank bitmap file, and I have this process working fine.
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).  It
also got me back to programming again, and I almost forgot how much I liked
to program.
 

Top

IKONOS

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 do so.

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 two
adjacent passes of the satellite over the same area. This kind of images is
available to the public.  The other kind of stereo coverage that IKONOS
sensors offer is a stereo that is within the same strip.  This is produced
by collecting the image captured by the first line sensor, then separately
collecting the image captured by the third line sensor.  This has been
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 is
placed in a nadir position so it is always orthogonal to the terrain, and
the last sensor is a back-ward looking sensor.  The second type of stereo
coverage is available only to Space Imaging and its government customers and
can not be sold to the private industry.
Now we come to the correction part.  I the geocities article you mentioned
"stereo orthophoto pairs".  In fact stereo pairs of any photography can be
utilized to produce digital terrain models (DTMs) that can be used to ortho
rectify the imagery and produce ortho photos.  Two orthos of the same area,
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 them.


Top

Kitterman's Map

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 final product.

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 so.

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 source possible.

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 me
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
http://www.avenza.com/MPcomp/ .  The software is apparently MAPublisher 4.0.
Charles Kitterman works for Kulshan Cartographic Services.  The topo map
used was apparently one generated by that company.  The DEM dataset was most
probably USGS.
 

Thanks for your very informative and useful site on terrain modeling.  I
have been experimenting with 3dem and have a question:  In the second to
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 hill
shading?  I can only seem to generate the hill shade showing terrain when I
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, select 3D
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 position".
Use the "tilt forward" button to rotate the image to the overhead view
position.
 

Top

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).  The
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 simple two
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 to USGS
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 NED
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 now but
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 the
other.  If you want, you could contact Kim directly at  Kisner@usgs.gov for
more information regarding SDTS availability.

Top

Mars DTM

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
http://www-pdsimage.jpl.nasa.gov/jbcache/viking/vo_2007/document/volinfo.txt
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
http://www-pdsimage.jpl.nasa.gov/jbcache/viking/vo_2007/ into a hex editor
and see if I could figure it out.  If I could not figure out the format from
these I would contact someone associated with the ftp and ask for help.  The
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
valuable information.

Another possible link is the Mars Polar Lander website.

Let me know if this leads anywhere in case someone else asks.
 

Top

Moon DTM

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 this
link http://www.gps.caltech.edu/~margot/ and ask about how he obtained the
radar interferometery data from http://dsnra.jpl.nasa.gov/

Top

MicroDEM

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
corresponding results.

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
Photoshop.

2) DEM2TGA7 - Seems to run fine but when I open the
resulting *.TGA file in Photoshop it looks like orange
snowstorm.

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
two?

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 to one
graphics pixel in a TGA or other graphics file.  So the image size that
MicroDem produces is exactly what you would expect.  The larger scale
1:250,000 USGS DEMs have typically 1201 by 1201 elevation postings so the
TGA produced by converting one of these would be about that size.  You can
of course increase the size of these by image processing (resizing) but then
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 not
being read by Photoshop, so I believe it now.  I think this is a problem
with the Photoshop reader but have no easy way of resolving this because I
do not have a copy of this program.  (Anyone who has written a file reader
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 copy of
PaintShop for free (see link on my page), import the file, export it to any
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 this
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 be appreciated.

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 information

Thanks for putting your web site together; it is a wonderful resource!

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 no
errors.

3D Studio Max is really where I would like to end up but when it tries to
open the resulting MicroDEM 4.0 file it replies with "Improper file format."

Finally there are another set of programs that written by Sol Katz that list
the information in a DEM called D2X1.exe. For the MicroDEM merged file the
parameters all come back as zero and the program hangs on the MircoDEM
generated file.

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
other programs?

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 is hard
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 over there.)

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 use
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 or .GIF
format.

This is what I have done in the past to create POV-Ray input files.  I start
in MicroDem, import the DEM, save as a .BMP, import to Paintshop Pro, and
then save from Painshop to .TGA format which POV-Ray can convert into a 3D
image.  You should probably save the image in grayscale to get the best
results.  You may have to fiddle with the source image depending on your
initial MicroDem settings.  Try to perform a "color merge" under the
"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 free.
If this does not solve your problem, let me know.  I looked at the MicroDem
.dem file with a binary editor and it looks pretty straight forward.  I can
probably write a quick conversion from this format to any target format if
necessary.

Here is a link that has more MicroDem information from someone more expert
than I:

http://www.3dartist.com/3dao/r/allenbil/md/md4art.htm


Good luck.

 

Top

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 as
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 I
do not have a clue how these different formats will impact on my system I
decided to ask the expert. Tell me, what are the specific format details to
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 I need
to create animated graphics for weather presentations. I need to purchase a
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 that
"The DEM files usable for Metacust Ultra, need to be either the USGS 1:250
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 to
work through when I returned.  Also, please call me John. Also, please do
not call me an expert, which I am not.  "In the land of the blind, 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.  I
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,
many GIS applications read this format.  In the U.S. at least it serves as
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.  (This
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 lot
easier.  It will also be easy to transfer data across platforms (like from
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 an issue
before the era of cheap computing but is pretty much a non-issue today.  The
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 long time
as a translation medium.)

If your application can read data in USGS native DEM format, you are off to
a good start.  It will not be able by any means to accommodate all the GIS
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:
ftp://mapping.usgs.gov/pub/ti/DEM/demguide/dugdem.txt.

I have no experience with the second so the following is conjecture.  NDEM
appears to stand for National Digital Elevation Model.  This is a raster
file format used by the Chief Directorate to Surveys and Mapping (South
Africa) for their DEM data set.  You apparently purchase this DEM data
directly from CDSM.  When you do, you get a CD with your map data in NDEM
format.

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 described
as a raster file format, which essentially means that conversion of this
format, if ever necessary, should be straight forward.  It is probably a
binary format.

The only thing that bothers me a little about your letter is the qualifier
"run-time optimized proprietary format" that precedes the reference to NDEM.
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 the
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 know
up front about any possible problems in reading your source data.

The link to CDSM where you can get information is:
http://w3sli.wcape.gov.za/Default.htm.

I hope this helps.  Write with further questions if it does not.  Your
software supplier should be your most important source of information.  I
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 future
experiences so drop me a line sometime if you are able.
 

Top

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 document at http://www.ordsvy.gov.uk/downloads/height/profile/profil_w.pdf.  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 they recommend.)

I hope that this will get you started.  Write again if it does not and we will think of something else.

Top

Ortho Imagery

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 any
suggestions on how to georeference the photos? I have not been able to find
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 an
interesting one from a topographical standpoint.  Close to Buena Vista home
of the annual FibArk whitewater kayak race, the famous Numbers rapids, Mt.
Elbert, etc.

I checked the USGS DOQ directory to see if DOQs were available for your area
of interest.  Unfortunately, there is coverage for almost all of the state
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 yourself at
http://mcmcweb.er.usgs.gov/status/rmmc/co/co_doq.html.  It would have been
nice if they were available because they are orthorectified, georeferenced,
and cheap.

I next checked Mapquest. They offer free aerial photos of some areas of the
country, but not for Chaffe county, CO.

I then did a web search for commercial sources.  There is lots available for
the front range (probably recycled USGS DOQs), but not for where you are
looking.

I then tried satellite imagery.  NIMA offers 10m DOIs but coverage stops
just south of I70, apparently outside your area of interest.  You can check
this for yourself at the NIMA geospatial engine  at www.nima.mil (same link
as on my website.)

Then I looked for ASTER L1A satellite imagery from the EOS Data Gateway
http://edcimswww.cr.usgs.gov/pub/imswelcome/.  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 weeks.
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 the
cloud coverage you will get.  ASTER may not even produce a useful image if
taken at this time of year.)

Then, I looked at the Space Imaging Quicklook site at
http://www.spaceimaging.com/gallery/quicklook/collection3_geo.asp?vFIPS_CODE
=08015 and found some images very close to your target.  There are 13
available.  I did not check them all but there does not appear to be an
exact match.  However, depending on the extent of coverage of the images you
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 easy as
it sounds  because one mountain can appear quite similar to another.

I have used Paintshop Pro (Photoshop would probably do just as well.) to do
ground referenced overlays in the past.   In this method you convert your
DEM to .tga format and open it in Paintshop.  Then  you paste your overlay
as a new layer over the DEM tga.  You decrease the opacity of the overlay so
that you can kind of see through it. Then by sliding the overlay around,
referencing ground features and resizing  you can usually get an OK match.
(It is important to (re)load the original overlay each time you resize it
because the interpolation algorithms will lose information each time if you
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 like
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 work
OK if you know the corner coordinates approximately.  (There is a nudge
command in 3DEM that is helpful in doing this job.)  This should be possible
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.  Let me
know if anything is interesting to you and I can send more details.

Top

Overlay Problem

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 image
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 I am 
getting a satellite image with reduced spatial resolution.  How can I register
the DEM with the satellite image without reducing the spatial resolution of satellite
image?

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 there
are DEM pixels to map to, your software solves the problem by thinning the
overlay image.  This in turn results in a degraded overlay image.

The only solution is to increase the number of pixels in the DEM.  This
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 of
resizing algorithm.

I looked around for some combination of standard applications that would do
the job and did not find anything.  I tried saving a DEM as a BMP, resizing
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.  This
did not work because GlobalMapper refused to take the tiff because it was
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 you know.
 

Top

R2V

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?
Thanks.

I looked into this problem as a way of getting DEM data for hard-to-obtain
international locations.  I am in the process of exploring this area myself
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 to
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.  I do
not know what ArcView or MapInfo can do, but I would strongly recommend that
you look at software that is designed to do this specific task, rather than
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 or in
a semi-automated fashion.

When this is done your program will automatically generate a DEM file by
interpolating to grid points.

Let me tell you the bad news.  In order to get good results you must do a
formidable job of cleaning the image.  A typical contour map has all sorts
of information superimposed on it that will corrupt your results.  You must
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 in
many places and will bleed together in many others.  These must all be
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 more
practical to locate or produce DEM data by other means.  I will post an
article in Spatial News in the near future to explain how this can be done.
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 SN or
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?
Thanks again.

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 program, it
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, I
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 your
vectorized contours are continuous and do not bleed.)  If you already have
this work done by other means, I am not sure that you can easily import the
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.  The link
is  http://www.ablesw.com/.  I emailed some questions to Dr. Wu already so
if you need some pointers in using the program I will tell you what I know.

I would appreciate any tips you could give me in the area of preparing the
input file.  I am trying to write a section for my web page to help amateur
cartographers prepare DEMS from topos.  The literature is sparse in this
area.  I recently bought a book called "Machine Interpretation of Line
Drawing Images" by Ablameyko but it does not seem to have too much more than
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 reading
legal USGS DEM files and others choking on them.  If you want a few tips,
here they are:

Fortunately USGS DEMs are ASCII files so they are easy to read.  Try
inspecting the file manually and comparing it to one that does work for you
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 is best
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 the file
that has all the metadata.  This is especially a problem when you are
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 data
manually (see HexEdit above).

The DEM file specification is available at
http://rockyweb.cr.usgs.gov/nmpstds/acrodocs/dem/2DEM0198.PDF.  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 of
reading DEMs, although its export capabilities are limited. (MicroDEM will
open the R2V file, as will DEMworks).  You could then save it as a MicroDEM
DEM and then use my converter MDEM2DEM to change it back to a DEM and see if
your target will accept that version.

I told you this would be a pain.  But if you really enjoy abuse, try
extracting DEM data from satellite imagery.

Regarding your last email: Is the 'join' operation automated in R2V or do
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 to
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 lines
but without inputting any depth data in between the depth contour lines. So
what I am left with are DTED format files with depth steps let say -20, -30,
-50, -100 and -200 meters like instead real gridded depth data. Many of them
only have few depth contour lines (let say 4 or 5) over the whole 1x1 degree
cell. I want to generate real gridded DTED level 1 without loosing the
location of the depth contour lines and shorelines. Meaning replacing the
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 stuff
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 of
writing a web page section on how this can be done.

I found a lot of interesting information in your site.

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.

Top

Seafloor Bathymetry

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 the
best source of data.  Here is a link for you to explore:

http://www.ngdc.noaa.gov/mgg/bathymetry/relief.html

GlobalMapper will read ETOPO2 data files which are available from the NOAA.
These might get you started.  You have to pay for both the ETOPO data and
GlobalMapper.

MicroDEM will read NOS EEZ Bathymetry.  A source for this data and more
coastal bathymetry can be found at:

http://www.ngdc.noaa.gov/mgg/bathymetry/multibeam/multibeam_products.html

It seems like none of this data is free but it is not too expensive.
 

Top

SDTS

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 getting.

 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.  As you
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 .cel0
.ldef, lspdm, .iref,  and ddsh files to extract such  data and insert it
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.  The
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 to
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 I needed
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 so
that you know exactly what is going on.  The weakness of my program is that
it does not extract all the available metadata from the SDTS profile.  In
some cases I insert default information in type A fields that I consider of
secondary importance and that I know to be generally true for the USGS data.
However, there is a possibility that one of these more obscure fields could
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 do.

Top

STL Format

I'm interested in combining GIS with 3D prototyping.  Are you aware of any
converters that are freeware that will produce STL (StereoLithography) files
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 couple of
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 to write
an STL converter but I keep getting interested in other things and never get
around to starting it.  You might try contacting Mike and see where he ended
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.

His email:

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
 

Top

Terragen

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 it
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 not
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 idea.
I hope that you can enlighten me on this topic and help me with a suitable
solution.

Your digitized image is probably in some type of vector format that is
incompatible with Terragen.  In fact, Terragen requires its own unique file
format for input data.  This is called a TER file.

Your best method is probably to export your file from ArcView in some type
of DEM format.  Usually USGS ASCII DEM is offered as an option (although I
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 do
not have it).  Save the file as a MicroDem DEM.

Then use my utility MDEM2TER to convert the MicroDem DEM to TER format using
MDEM2TER.  I realize that this is cumbersome but it is the only way that I
know.

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 of
the techniques.

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 and
animations.  However, what I really want to do is build a model of Grenada,
West Indies.

Now I am aware that I need to download the relevant data.  From your website
I had a look at the NIMA website and seemed to find the co-ordinates I would
need to create my model.  The problem is, which format should I download and
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 I'm
having problems with is using the information I get from NIMA so that I can
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 to
work, but is that what the NIMA file is?

If you could provide me with any pointers to put me back on the right track
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 this case.

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 the
render.  Is this just simply because the detail just isn't there from the
source?  As a result I went to have a look at GTOPO30 and downloaded a 10MB
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 Grenada is
only 17 by 23 KM!!!

Top

TopoUSA

Hi!
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 you could
sell/give it a hiker.  If it is any consolation I will insert your feedback
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 it
offered a good solution for them.

I had the same idea about the data when I bought it.  Unfortunately, it is
not stored in any type of conventional file structure that I have been able
to get at.  When I tried to open a file using my hex editor it just locked
up my computer.  Even if I could open a file, the format is unknown and the
data is almost certainly compressed using an unknown compression scheme.  I
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 is
pretty much limited to the packages discussed on the web page.

Top

VistaPRO

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.

later...

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 4.0 DEM
to a USGS DEM ?.

Thank you.
Arthur (Spain)

Arturo:

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.

John

y Arturo escribe...

Hola de nuevo, antes de nada felicitarle por su buen nivel
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
http://amber.rc.arizona.edu/lw/demscape.html 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.

Gracias.
Arturo.

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 do
this

Top

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,

Top