High!

Another step towards Khyberspace... but at the moment, I'm once again 
hampered by obviously misunderstood technology!

About one year ago, by a posting of Christoph Hormann's latest 
achievements in Earth modeling I was informed about the newly published 
data files of the Shuttle Radar Topography Missions (SRTM), showing the 


At ftp://ftp.glcf.umiacs.umd.edu/glcf/SRTM/Degree_Tiles the single 
1-degree tiles are downloadable for free - in the format of 1200 x 1200 
GeoTIFFs. Unfortunately, although they look very much like 16-bit 
heightfield bitmaps for PoV-Ray, their height scale definition is 
completely different, so that PoV-Ray cannot interprete them in a 
sensible way.

As I did not (yet) found any understandable definition of the GeoTIFF 
standard, I had to content myself with converting them into ASCII 
matrizes with a vertical resolution of 1 metre.

The program I used for this is 3DEM, available at 
http://www.visualizationsoftware.com/3dem.html (according to all I know, 
  there is no Linux version of it!). The converted GeoTIFFs then are 
simple tapeworms of 1,440,000 six-digit float values in clear text, 
separated by blanks, without any CRs and LFs.

As PoV-Ray I/O directives accept only ASCII files with commas as 
delimiters, I had to replace those blanks by commas using the "replace" 
utility of Linux, which worked perfectly.

Then, after some problems with the standard mesh object, Jerome M. 
Berger (thank you, Jerome!) suggested me to use mesh2 instead, I 
rendered a first test version of a spherical mesh2 of GeoTIFF tile 
N34E068 (the geographically inclined among us are inviting to look it up 
  in their favourite atlas ;-)).

But the result was weird, obviously the float values in the ASCII matrix 
are arranged in a different way than the pixels in the GEO-TIFF file.

Attached are the mesh2 rendering and an 2D map generated with 3DEM 
showing how the terrain should look instead.

For better comparability of the land features, I placed a waterline at 
2500 metres elevation in both images.

The code is available on p.b.s-f

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download 'iotest-n.png' (67 KB) Download 'n34e068.jpg' (38 KB)

Preview of image 'iotest-n.png'

Preview of image 'n34e068.jpg'

> 
> As I did not (yet) found any understandable definition of the GeoTIFF 
> standard, I had to content myself with converting them into ASCII 
> matrizes with a vertical resolution of 1 metre.

Oh, come on, there is GDAL: http://www.remotesensing.org/gdal/ which 
comes with a simple utility program that converts between any formats 
supported which includes Geotiff of course as well as PNG and PGM which 
can be read by POV-Ray.

> But the result was weird, obviously the float values in the ASCII matrix 
> are arranged in a different way than the pixels in the GEO-TIFF file.

You quite obviously got the size of the images wrong by 1-2 pixel.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 27 Feb. 2005 _____./\/^>_*_<^\/\.______

Post a reply to this message

High!

Shortly after my last post, I looked up the corresponding thread on 
p.b.s-f and found a post of J. M. Berger where he pointed out an error 
in his correction of my original traditional mesh version.

So I replaced all "data" in the vertices block by mtrix[a][b] - and this 
is what I*ve got (again compared to the 2D map from 3DEM - code (now 
really) on p.b.s-f):

See you in Khyberspace!

Yadgar

Now playing: Village (Robert Quine & Fred Meer)

Post a reply to this message

Attachments:
Download 'iotest-n.png' (91 KB) Download 'n34e068.jpg' (38 KB)

Preview of image 'iotest-n.png'

Preview of image 'n34e068.jpg'

Christoph Hormann wrote:

> 
>>
>> As I did not (yet) found any understandable definition of the GeoTIFF 
>> standard, I had to content myself with converting them into ASCII 
>> matrizes with a vertical resolution of 1 metre.
> 
> 
> Oh, come on, there is GDAL: http://www.remotesensing.org/gdal/ which 
> comes with a simple utility program that converts between any formats 
> supported which includes Geotiff of course as well as PNG and PGM which 
> can be read by POV-Ray.
> 
>> But the result was weird, obviously the float values in the ASCII 
>> matrix are arranged in a different way than the pixels in the GEO-TIFF 
>> file.
> 
> 
> You quite obviously got the size of the images wrong by 1-2 pixel.
> 
One pixel, because the matrix is square and there is a diagonal.
Assuming he is reading left to right and top to bottom, Yadgar
is reading one to little per line. A typical obi-wan error I guess
(http://www.catb.org/~esr/jargon/html/O/obi-wan-error.html).

Now playing: New Deal by Dolores Keane

Post a reply to this message

Christoph Hormann wrote:

> Oh, come on, there is GDAL: http://www.remotesensing.org/gdal/ which 
> comes with a simple utility program that converts between any formats 
> supported which includes Geotiff of course as well as PNG and PGM which 
> can be read by POV-Ray.

I never heard of this! So, possibly the detour via the ASCII matrix is 
not longer necessary?

> You quite obviously got the size of the images wrong by 1-2 pixel.

Yes, otherwise there wouldn't be that strange diagonal scarp... must be 
a mistake in J. M. Bergers correction of my original version (using a 
traditional mesh rather than mesh2). I'll soon try it out (the indices 
obviously must be set to 1200 x 1200 x 2, not 1199 x 1199 x 2!), but 
firstly, I have to complete the download of the current Java API ;-)!

See you in Khyberspace!

Yadgar

Post a reply to this message

Are you sure this isn't the old byte order boondoggle?
From the GeoTiff spec at 
http://www.remotesensing.org/geotiff/spec/geotiff2.3.html#2.3
" It is worth emphasizing here that the TIFF spec indicates that 
TIFF-compliant readers shall honor the 'byte-order' indicator, meaning that 
4-byte integers from files created on opposite order machines will be 
swapped in software, and that 8-byte DOUBLE's will be 8-byte swapped."

DLM



news:424e9093@news.povray.org...
> High!
>
> Shortly after my last post, I looked up the corresponding thread on
> p.b.s-f and found a post of J. M. Berger where he pointed out an error
> in his correction of my original traditional mesh version.
>
> So I replaced all "data" in the vertices block by mtrix[a][b] - and this
> is what I*ve got (again compared to the 2D map from 3DEM - code (now
> really) on p.b.s-f):
>
> See you in Khyberspace!
>
> Yadgar
>
> Now playing: Village (Robert Quine & Fred Meer)
>
>
>


--------------------------------------------------------------------------------






--------------------------------------------------------------------------------

Post a reply to this message

andrel wrote:

> One pixel, because the matrix is square and there is a diagonal.
> Assuming he is reading left to right and top to bottom, Yadgar
> is reading one to little per line. A typical obi-wan error I guess
> (http://www.catb.org/~esr/jargon/html/O/obi-wan-error.html).

Yes, that's it... how on Earth could I know that the ASCII matrix is in 
fact 1201 by 1201? I once again tried it with 1201 instead of 1200, and, 
finally got it right (attached here)!

But the GeoTIFF conversion tools mentioned before by Christoph is VERY 
intriguing... I think I'll try it out somewhat later, when I finished 
the first ground views for better judgement!

See you in Khyberspace!

Yadgar

Now playing: Earth (Adalbert von Deyen)

Post a reply to this message

Attachments:
Download 'iotest-n.png' (85 KB)

Preview of image 'iotest-n.png'

Christoph Hormann wrote:

> Oh, come on, there is GDAL: http://www.remotesensing.org/gdal/ which 
> comes with a simple utility program that converts between any formats 
> supported which includes Geotiff of course as well as PNG and PGM which 
> can be read by POV-Ray.

I looked it up and found a dozen programs which use the GDAL library... 
which of them do you mean exactly?

See you in Khyberspace!

Yadgar

Post a reply to this message

> 
>> Oh, come on, there is GDAL: http://www.remotesensing.org/gdal/ which 
>> comes with a simple utility program that converts between any formats 
>> supported which includes Geotiff of course as well as PNG and PGM 
>> which can be read by POV-Ray.
> 
> 
> I looked it up and found a dozen programs which use the GDAL library... 
> which of them do you mean exactly?

None.  Just read what i wrote - GDAL comes with an utility program 
gdal_translate (see http://www.remotesensing.org/gdal/gdal_utilities.html).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 27 Feb. 2005 _____./\/^>_*_<^\/\.______

Post a reply to this message

> andrel wrote:
> 
>> One pixel, because the matrix is square and there is a diagonal.
>> Assuming he is reading left to right and top to bottom, Yadgar
>> is reading one to little per line. A typical obi-wan error I guess
>> (http://www.catb.org/~esr/jargon/html/O/obi-wan-error.html).
> 
> 
> Yes, that's it... how on Earth could I know that the ASCII matrix is in 
> fact 1201 by 1201? 
1) counting ;)
2) it is not uncommon to add one extra line to make sure that
  interpolation can be performed without having to read the
  surrounding tiles.
3) look at the result and you can easily spot what is wrong
> I once again tried it with 1201 instead of 1200, and, 
> finally got it right (attached here)!
> 
> But the GeoTIFF conversion tools mentioned before by Christoph is VERY 
> intriguing... I think I'll try it out somewhat later, when I finished 
> the first ground views for better judgement!
> 
> See you in Khyberspace!
> 
> Yadgar
> 
> Now playing: Earth (Adalbert von Deyen)
>

Post a reply to this message