 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.01.2011 20:45, schrieb Carlo C.:
> clipka<ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 18 Jan 2011 09:00:28 +0200, clipka <ano### [at] anonymousorg> wrote:
> 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.
So I guess we need to ad a request for spherical heightfields as well :)
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.01.2011 14:52, schrieb Nekar Xenos:
>>> 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.
>
> So I guess we need to ad a request for spherical heightfields as well :)
Given the various possible ways of mapping sample points to lat/long
coordinates, the least common denominator would probably be a triangle
mesh, so what you'd actually ask for seems to boil down to another
syntax for describing mesh/mesh2 objects. Somethng like
mesh_file {
FILE_TYPE FILE_NAME
[...]
}
(The same syntax could also be used for .obj files.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 18 Jan 2011 20:57:21 +0200, clipka <ano### [at] anonymousorg> wrote:
> Am 18.01.2011 14:52, schrieb Nekar Xenos:
>
>>>> 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.
>>
>> So I guess we need to ad a request for spherical heightfields as well :)
>
> Given the various possible ways of mapping sample points to lat/long
> coordinates, the least common denominator would probably be a triangle
> mesh, so what you'd actually ask for seems to boil down to another
> syntax for describing mesh/mesh2 objects. Somethng like
>
> mesh_file {
> FILE_TYPE FILE_NAME
> [...]
> }
>
> (The same syntax could also be used for .obj files.)
Sounds good to me :)
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nekar Xenos <nek### [at] gmailcom> wrote:
> > mesh_file {
> > FILE_TYPE FILE_NAME
> > [...]
> > }
> >
> > (The same syntax could also be used for .obj files.)
> Sounds good to me :)
Sounds, once again, something which should be implemented via scripting
(in the hypothetical new scripting language of POV-Ray 4.0) rather than as
a core feature.
Adding more and more new core features is *not* going to help with the
transition to POV-Ray 4.0 (if that ever comes into fruition).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
