news:4d0a3421@news.povray.org...
> High!
>
> On 15.12.2010 22:53, Dre wrote:
>
>> Hey, I live in southern Tasmania!!
>
> In Hobart?

Yep!  Well Kingston actually, 10 minutes away.  I work in Hobart city :)

>
>>
>> I dont suppose you could tell me where you got the data for the 
>> heightfield?
>
> Look here: http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Australia/
>
> These are data tiles from a Shuttle Radar Topography Mission (SRTM) in
> February 2000, covering the entire land surface of the Earth between

> of 3 arcseconds per data point. The name of each file indicates the
> geographical coordinates of the *southwestern*, i. e. left lower corner
> of the tile. So, you just look up the coordinate range of Tasmania in
> your preferred atlas and find the respective tiles.
>
> These tiles are NOT image files, but you can make them visible (and even
> generate nice 3-D views, which export also to VRML) with a Windows
> freeware called "3DEM". You find 3DEM here:
> http://freegeographytools.com/3dem_setup.exe
> With 3DEM, you can iron out error pixels (mostly resulting from cloud
> cover) with the "Patch missing data" feature - but this works only for
> error pixels which have no connection to the tile's edges!
>
> To use them with PoV-Ray, you'll have to export the read-in data tile as
> "ASCII terrain matrix". I wrote a POV script which generates a 16-bit
> PNG heightfield from these ASCII files - attached here (ascii2png.pov)!
>
> The ASCII files have the height data as number strings at two-digit
> accuracy (xxxx.xx), each separated by a blank. PoV-Ray needs the blanks
> to be replaced by commas to read the data in properly. If you have
> access to Linux with its powerful UNIX console command line tools,
> you're fine - just type in:
>
> sed 's/ /,/g' original_file destination_file
>
> and within two seconds, almost 1,5 million blanks are replaced by commas!
>
> Unfortunately, I currently do not know of any Windows tool capable of
> doing that job at a comparable speed - common GUI text editors, not to
> mention full-fledged word processors toil for hours! But even if you
> have no Linux on your computer, you can download a "Live CD" image of a
> Debian distribution and burn it - afterwards you'll be able to boot a
> proper Linux installation from the disk! If you face problems to write
> data on your harddisk (because of missing rights), just try a USB stick
> instead, it probably will work!
>
> Note that the size of the data tiles is in fact 1201 by 1201 rather than
> 1200 x 1200, so adjacent rows and columns would repeat - if you want to
> join two or more of your generated PNG heightfields, you'll first have
> to remove the easternmost column and southernmost row.
>
> And joining heightfields would be the only way to get rid of the error
> pixels which, with the original tiles, lie at the edges. I also wrote a
> POV script (png2ascii.pov) to re-export joined heightfields to an ASCII
> terrain matrix readable by 3DEM - the software will ask you about the
> size and corner coordinates and then you can smooth out the remaining
> error pixels.
>
> After exporting them back to ASCII (and, of course, once more replacing
> blanks by comma) and finally to PNG, you'll have a faultless heightfield
> of your desired area. Note that the creation of the PNG heightfields
> required quite at lot of memory, as each "pixel" in fact is a small box
> object rendered in an orthographic view without light_source but with
> ambient 1 - to do 1200 x 1200 boxes, you should have at least 1.5 GB of 
> RAM!
>
> As the tiles are square degree tiles, the resulting cartographic
> projection is cylindrical, so that only along the Equator, the
> heightfields give a realistical representation of terrain, while towards
> the poles, the terrain is increasingly stretched in west-east direction.
>
> To get an undistorted landscape, you'll have to finally convert the PNG
> heightfield into a mesh2 which follows Earth's curvature according to
> its geographical coordinates. I also wrote a script to do this
> (mesh2writer), but as you see in the example rendering I attached, some
> artifacts resulting from floating point inaccuracy show up. To avoid
> them, we probably must use Christoph Hormann's IsoCSG include
> (http://www.imagico.de/pov/ic/index.html) which is able to convert a
> mesh2 into an isosurface!
>
> I added two scripts I wrote to do the conversion from PNG to mesh2 -
> mesh2writer.pov which writes the full POV code for the entire mesh (for
> parsing speed reasons, the mesh2 is generated only once and then written
> to harddisk), and png2mesh2.pov which includes the code written by the
> former script and generates the scene from it.
>
>> I'm very interested in recreating the area around my house for starters 
>> :)
>
> As the SRTM data tiles mentioned above have an effective resolution of
> about 90 metres per data point, you'll be better off with pixeling
> heightfield from a scanned-in topographic map, perhaps 1:25,000 (which
> can be quite cumbersome work)... but then adjusting it to Earth
> curvature would be somewhat difficult, as those maps are based on
> geodetic (equal distances between points) rather than geographic
> coordinates.
>
>> Then the whole island, that would be sweet!!!
>
> Yes, with Tasmanian Tigers roaming the forests! In fact, I think
> Tasmania a very interesting part of the world, as it is located in the
> "Roaring Forties", mainly when it comes to vegetation and animals, and I
> really would like to visit your island!
>
> See you in Khyberspace!
>
> Yadgar
>

Thanks very much for the very thorough write up.  I'm going to take a look 
at that data over the weekend and see what I can come up with.

Tasmania is an awesome place, wonderful place to live.  Unfortunately a 
disease is threatening the Tassie Devils existance (no Tigers btw) so you 
better hurry if you want to see them :)

Thanks again for the info, much appreciated!

Cheers Dre

Post a reply to this message