|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nekar Xenos
Subject: Re: Request *.dem and *.hgt format
Date: 17 Jan 2011 14:52:56
Message: <op.vpgxihr1ufxv4h@xena>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nekar Xenos
Subject: Re: Request *.dem and *.hgt format
Date: 18 Jan 2011 02:37:12
Message: <op.vpht38xvufxv4h@xena>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nekar Xenos
Subject: Re: Request *.dem and *.hgt format
Date: 18 Jan 2011 02:52:58
Message: <op.vphuuhprufxv4h@xena>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nekar Xenos
Subject: Re: Request *.dem and *.hgt format
Date: 18 Jan 2011 02:53:55
Message: <op.vphuv4rjufxv4h@xena>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |