POV-Ray : Newsgroups : povray.pov4.discussion.general : Request *.dem and *.hgt format Server Time
29 Mar 2024 08:52:23 EDT (-0400)
  Request *.dem and *.hgt format (Message 5 to 14 of 14)  
<<< Previous 4 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: Request *.dem and *.hgt format
Date: 18 Jan 2011 02:00:41
Message: <4d353a99$1@news.povray.org>
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

From: clipka
Subject: Re: Request *.dem and *.hgt format
Date: 18 Jan 2011 02:10:29
Message: <4d353ce5$1@news.povray.org>
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

From: clipka
Subject: Re: Request *.dem and *.hgt format
Date: 18 Jan 2011 03:06:30
Message: <4d354a06$1@news.povray.org>
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

From: Nekar Xenos
Subject: Re: Request *.dem and *.hgt format
Date: 18 Jan 2011 08:52:09
Message: <op.vpibgzlzufxv4h@go-dynamite>
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

From: clipka
Subject: Re: Request *.dem and *.hgt format
Date: 18 Jan 2011 13:57:37
Message: <4d35e2a1$1@news.povray.org>
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

From: Nekar Xenos
Subject: Re: Request *.dem and *.hgt format
Date: 19 Jan 2011 01:35:54
Message: <op.vpjlxss6ufxv4h@go-dynamite>
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

From: Warp
Subject: Re: Request *.dem and *.hgt format
Date: 19 Jan 2011 12:24:24
Message: <4d371e48@news.povray.org>
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

<<< Previous 4 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.