It would be wonderful if we could use .dem and .hgt formats for  
heightfields as these are the native file formats for terrain data.

-- 
-Nekar Xenos-

Post a reply to this message

Am 17.01.2011 15:59, schrieb Nekar Xenos:
> It would be wonderful if we could use .dem and .hgt formats for
> heightfields as these are the native file formats for terrain data.

Do you have a source for file format documentation? A (not necessarily 
complete) list of software that generates files in this format might be 
interesting, too.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 17.01.2011 15:59, schrieb Nekar Xenos:
> > It would be wonderful if we could use .dem and .hgt formats for
> > heightfields as these are the native file formats for terrain data.
>
> Do you have a source for file format documentation? A (not necessarily
> complete) list of software that generates files in this format might be
> interesting, too.

This, about USGS DEM:

http://rockyweb.cr.usgs.gov/nmpstds/acrodocs/dem/

Post a reply to this message

On Mon, 17 Jan 2011 20:24:40 +0200, clipka <ano### [at] anonymousorg> wrote:

> Am 17.01.2011 15:59, schrieb Nekar Xenos:
>> It would be wonderful if we could use .dem and .hgt formats for
>> heightfields as these are the native file formats for terrain data.
>
> Do you have a source for file format documentation? A (not necessarily  
> complete) list of software that generates files in this format might be  
> interesting, too.

Maybe this will help:

"Height files have the extension .HGT and are signed two byte integers.
The
bytes are in Motorola "big-endian" order with the most significant byte
first,
directly readable by systems such as Sun SPARC, Silicon Graphics and
Macintosh.
DEC Alpha and most PCs use Intel ("little-endian") order so some
byte-swapping
may be necessary. Heights are in meters referenced to the WGS84 geoid.
Data
voids are assigned the value -32768."

-From http://freegis.org/pipermail/freegis-list/2004-December/002013.html

and

"GDAL includes support for reading USGS SDTS formatted DEMs. USGS DEMs are  
always returned with a data type of signed sixteen bit integer, or 32bit  
float. Projection and georeferencing information is also returned.

SDTS datasets consist of a number of files. Each DEM should have one file  
with a name like XXXCATD.DDF. This should be selected to open the dataset.

The elevation units of DEMs may be feet or meters. The GetType() method on  
a band will attempt to return if the units are Feet ("ft") or Meters  
("m")."

-from http://www.gdal.org/frmt_various.html

Maybe you can also find more info here: http://grass.osgeo.org/

-- 
-Nekar Xenos-

"The spoon is not real"

Post a reply to this message

Am 17.01.2011 20:45, schrieb Carlo C.:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 17.01.2011 15:59, schrieb Nekar Xenos:
>>> It would be wonderful if we could use .dem and .hgt formats for
>>> heightfields as these are the native file formats for terrain data.
>>
>> Do you have a source for file format documentation? A (not necessarily
>> complete) list of software that generates files in this format might be
>> interesting, too.
>
> This, about USGS DEM:
>
> http://rockyweb.cr.usgs.gov/nmpstds/acrodocs/dem/

As far as I understand, the format stores data in a non-rectangular 
format, which will make it pretty difficult for use in height fields.

Post a reply to this message

Am 17.01.2011 20:52, schrieb Nekar Xenos:

> "Height files have the extension .HGT and are signed two byte integers.
> The
> bytes are in Motorola "big-endian" order with the most significant byte
> first,
> directly readable by systems such as Sun SPARC, Silicon Graphics and
> Macintosh.
> DEC Alpha and most PCs use Intel ("little-endian") order so some
> byte-swapping
> may be necessary. Heights are in meters referenced to the WGS84 geoid.
> Data
> voids are assigned the value -32768."

That's pretty meager; some information would be needed about the number 
of columns & rows, and how this format deals with the spheroid shape of 
earth.

Post a reply to this message

On Tue, 18 Jan 2011 09:10:15 +0200, clipka <ano### [at] anonymousorg> wrote:

> Am 17.01.2011 20:52, schrieb Nekar Xenos:
>
>> "Height files have the extension .HGT and are signed two byte integers.
>> The
>> bytes are in Motorola "big-endian" order with the most significant byte
>> first,
>> directly readable by systems such as Sun SPARC, Silicon Graphics and
>> Macintosh.
>> DEC Alpha and most PCs use Intel ("little-endian") order so some
>> byte-swapping
>> may be necessary. Heights are in meters referenced to the WGS84 geoid.
>> Data
>> voids are assigned the value -32768."
>
> That's pretty meager; some information would be needed about the number  
> of columns & rows, and how this format deals with the spheroid shape of  
> earth.

 from http://www2.jpl.nasa.gov/srtm/faq.html :

"The SRTM data files have names like "N34W119.hgt". What do the letters  
and numbers refer to, and what is ".hgt" format?

Each data file covers a one-degree-of-latitude by one-degree-of-longitude  
block of Earth's surface. The first seven characters indicate the  
southwest corner of the block, with N, S, E, and W referring to north,  
south, east, and west. Thus, the "N34W119.hgt" file covers latitudes 34 to  
35 North and longitudes 118-119 West (this file includes downtown Los  
Angeles, California). The filename extension ".hgt" simply stands for the  
word "height", meaning elevation. It is NOT a format type. These files are  
in "raw" format (no headers and not compressed), 16-bit signed integers,  
elevation measured in meters above sea level, in a "geographic" (latitude  
and longitude array) projection, with data voids indicated by -32768.  
International 3-arc-second files have 1201 columns and 1201 rows of data,  
with a total filesize of 2,884,802 bytes ( = 1201 x 1201 x 2). United  
States 1-arc-second files have 3601 columns and 3601 rows of data, with a  
total filesize of 25,934,402 bytes ( = 3601 x 3601 x 2). For more  
information read the text file "SRTM_Topo.txt" at  
http://edcftp.cr.usgs.gov/pub/data/srtm/Readme.html
"

-- 
-Nekar Xenos-

"The spoon is not real"

Post a reply to this message

On Tue, 18 Jan 2011 09:10:15 +0200, clipka <ano### [at] anonymousorg> wrote:

> Am 17.01.2011 20:52, schrieb Nekar Xenos:
>
>> "Height files have the extension .HGT and are signed two byte integers.
>> The
>> bytes are in Motorola "big-endian" order with the most significant byte
>> first,
>> directly readable by systems such as Sun SPARC, Silicon Graphics and
>> Macintosh.
>> DEC Alpha and most PCs use Intel ("little-endian") order so some
>> byte-swapping
>> may be necessary. Heights are in meters referenced to the WGS84 geoid.
>> Data
>> voids are assigned the value -32768."
>
> That's pretty meager; some information would be needed about the number  
> of columns & rows, and how this format deals with the spheroid shape of  
> earth.

http://stackoverflow.com/questions/357415/how-to-read-nasa-hgt-binary-files

http://dds.cr.usgs.gov/srtm/version1/Documentation/SRTM_Topo.txt

hope this helps

-- 
-Nekar Xenos-

"The spoon is not real"

Post a reply to this message

On Tue, 18 Jan 2011 09:10:15 +0200, clipka <ano### [at] anonymousorg> wrote:

> Am 17.01.2011 20:52, schrieb Nekar Xenos:
>
>> "Height files have the extension .HGT and are signed two byte integers.
>> The
>> bytes are in Motorola "big-endian" order with the most significant byte
>> first,
>> directly readable by systems such as Sun SPARC, Silicon Graphics and
>> Macintosh.
>> DEC Alpha and most PCs use Intel ("little-endian") order so some
>> byte-swapping
>> may be necessary. Heights are in meters referenced to the WGS84 geoid.
>> Data
>> voids are assigned the value -32768."
>
> That's pretty meager; some information would be needed about the number  
> of columns & rows, and how this format deals with the spheroid shape of  
> earth.

http://dds.cr.usgs.gov/srtm/version2_1/Documentation/

-- 
-Nekar Xenos-

"The spoon is not real"

Post a reply to this message

Am 18.01.2011 08:37, schrieb Nekar Xenos:

> Each data file covers a one-degree-of-latitude by
> one-degree-of-longitude block of Earth's surface. The first seven

Hm, so this is also pretty difficult to turn into a height field, except 
for terrain near the equator.

Post a reply to this message