Hi(gh)!

...and thus, most likely no POVghanistan!

The reason: the data structure in the ASCII elevation data tiles 
generated with 3DEM from the original ASTER GeoTIFFs is too 
unpredictable to reliably generate anything from them using POV-Ray!
Values ending in .00 are intermingled with those ending in .0 or being 
real decimal fractures, they are mostly separated by one space, but 
sometimes also two... no combination of sed commands I ever tried 
produced a POV-Ray-processible file! Some tiles work, while others won't...

I could give C++ a try, but even then it would be next to impossible for 
me to take all peculiarities of the ASCII tiles into account... 
POVghanistan will forever be limited to a classic heightfield containing 
Kabul and a small portion of its surroundings I started pixeling 
manually from that Russian topographic map in 2004. OpenCologne will 
never come into existence unless I find a really powerful contour line 
interpolation tool.

It just HURTS to give up some many dreams, from travelling to real 
Afghanistan, growing my hair to waist length, making a living as a 
professional programmer and now building Khyberspace...

See you in Khyberspace, perhaps in another world and time...

Yadgar

Post a reply to this message

Am 2/25/20 2:51 PM, also sprach Jörg "Yadgar" Bleimann:
> Hi(gh)!

> Values ending in .00 are intermingled with those ending in .0 or being 
> real decimal fractures, they are mostly separated by one space, but 
> sometimes also two... no combination of sed commands I ever tried 
> produced a POV-Ray-processible file! Some tiles work, while others won't...
> 
> I could give C++ a try,
How about using Qt C++ regular expressions to read the data and then 
write it out as something rigid for your SDL to interpret?

Regular expressions are pretty flexible when dealing with floating point 
numbers.  For example, I parse this whole file from my cave scene. It 
lays out the points of the plants and paths of the fish.
http://git.buckosoft.com/gitweb/pov.cgi?p=tteoac.git;a=blob;f=ttvo/ocean/forester.inc

This is the file that reads and writes that data.
http://git.buckosoft.com/gitweb/pov.cgi?p=forester.git;a=blob;f=filehandler.cpp

I would be willing to help you get that going, if you'd like.
I'd hate to see your dreams die.  Plus, I want to see POVghanistan. :)

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

Post a reply to this message

Hi(gh)!

On 26.02.20 03:31, Dick Balaska wrote:

> How about using Qt C++ regular expressions to read the data and then 
> write it out as something rigid for your SDL to interpret?
> 
> Regular expressions are pretty flexible when dealing with floating point 
> numbers.  For example, I parse this whole file from my cave scene. It 
> lays out the points of the plants and paths of the fish.
>
http://git.buckosoft.com/gitweb/pov.cgi?p=tteoac.git;a=blob;f=ttvo/ocean/forester.inc 
> 
> 
> This is the file that reads and writes that data.
> http://git.buckosoft.com/gitweb/pov.cgi?p=forester.git;a=blob;f=filehandler.cpp 
> 
> 
> I would be willing to help you get that going, if you'd like.
> I'd hate to see your dreams die.  Plus, I want to see POVghanistan. :)

Meanwhile, I have to soften my harsh initial stance... I finally found a 
way to get those ASCII data tiles POV-readable, albeit at a slight 
expense of accuracy. Very most of the elevation values are in fact 
integers, written pro forma as floats, they end with .00 (or, rarely, 
.0). A tiny fraction of them contains digits different from zero after 
the decimal point, so I decided to truncate them all to integers by 
using this bash script:

swcorner=$1
sed 's/.[0-9][0-9] /,/g' $swcorner".txt" > $swcorner"_pov.txt"
sed 's/ //g' $swcorner"_pov.txt" > $swcorner".txt"
sed 's/,,/,/g' $swcorner".txt" > $swcorner"_pov.txt"
mv -f $swcorner"_pov.txt" $swcorner".txt"

This way, I generated about ten heightfields of the Arctic Norwegian 
archipelago of Svalbard, also known as Spitsbergen, all along the 80th 
parallel (one attached here)... my next task will be cleaning up these 
heightfields manually, as the ASTER Earth surveyor mission's radar was 
not able to tell land from sea ice. I will model sea as a plain "basin" 
about 100 meters deep, no actual bathymetry (at least for the time 
being), at least deep enough to be intransparently dark when I once more 
borrow Christoph Hormann's water like I did earlier in this decade.

Another issue will be finding texture tiles in cylindrical projection to 
apply them to the terrain slices to be generated from the heightfields - 
currently, I only have access the famous cloud-free "Blue Marble" 
mosaic, 86400 by 43200 pixels for the whole Earth equaling 240 x 240 
pixels per square degree - but as my elevation data tiles contain 3600 x 
3600 (plus one in north and east direction for seamless aligning) 
measuring points, I would like to find something at a higher resolution. 
I know that LANDSAT tiles at 1200 x 1200 per square degree exist (or at 
least have existed in the early 2010s). But recently, I could not get 
access to single tiles... does anyone here know more?

An advantage of "Blue Marble" tiles, however, is that they are available 
for each month of 2004, so that advancing and shrinking snow cover as 
well as die-off and re-greening of vegetation can be included into 
POVEarth (at least as basic soil texture as long as there are not real 
snow or vegetation objects placed on the terrain relief)...

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download 'n80e019.png' (4557 KB)

Preview of image 'n80e019.png'

On 2/25/2020 2:51 PM, Jörg "Yadgar" Bleimann wrote:
> Hi(gh)!
> 
> ...and thus, most likely no POVghanistan!
> 
> The reason: the data structure in the ASCII elevation data tiles 
> generated with 3DEM from the original ASTER GeoTIFFs is too 
> unpredictable to reliably generate anything from them using POV-Ray!
> Values ending in .00 are intermingled with those ending in .0 or being 
> real decimal fractures, they are mostly separated by one space, but 
> sometimes also two... no combination of sed commands I ever tried 
> produced a POV-Ray-processible file! Some tiles work, while others won't...
> 
> I could give C++ a try, but even then it would be next to impossible for 
> me to take all peculiarities of the ASCII tiles into account... 
> POVghanistan will forever be limited to a classic heightfield containing 
> Kabul and a small portion of its surroundings I started pixeling 
> manually from that Russian topographic map in 2004. OpenCologne will 
> never come into existence unless I find a really powerful contour line 
> interpolation tool.
> 
> It just HURTS to give up some many dreams, from travelling to real 
> Afghanistan, growing my hair to waist length, making a living as a 
> professional programmer and now building Khyberspace...
> 
> See you in Khyberspace, perhaps in another world and time...
> 
> Yadgar

You should not have to use C++ to do this. Python likely supports 
regular expressions too. And the PyPy extension is very fast!


Michael

Post a reply to this message

> The reason: the data structure in the ASCII elevation data tiles
> generated with 3DEM from the original ASTER GeoTIFFs is too
> unpredictable to reliably generate anything from them using POV-Ray!
> Values ending in .00 are intermingled with those ending in .0 or being
> real decimal fractures, they are mostly separated by one space, but
> sometimes also two... no combination of sed commands I ever tried
> produced a POV-Ray-processible file! Some tiles work, while others won't...


Hi,

I am a software developer, and if you give me examples of all eventualities,
maybe I can create a program that can correct them with the intended substitute
signs. But then again, replacement can be done with programs as simple as
Notepad, too.

What exactly is wrong with the files? Please list all wrong elements and their
correct counterparts, maybe then I can understand better.

Also, have you tried other file versions of those areas, like DEM files?

Post a reply to this message