New Georeferenced 32bit heightfields questions

[RArcher]

First off, Thanks!  I am very glad that you have added this as it makes it so much easier to lay out real world data.  A few questions / problems I have run into so far however.

The data I am using is Canadian DEM data which in format is very similar to the typical USGS data.  My example file is 0.75 arc seconds using the NAD83 Datum.

I am using GlobalMapper v8 to do the conversion from .dem format into 32bit Geotiff which also saves a .tfw and projection file (.prj)

Now the problem is that the .tfw file is in the UTM coordinate system in the following format:

0.75000000000000000     
0.00000000000000000     
0.00000000000000000     
-0.75000000000000000   
-424800.00000000000000000
180000.00000000000000000

    * Line 1: pixel size in the x-direction
    * Line 2: rotation about y-axis
    * Line 3: rotation about x-axis
    * Line 4: pixel size in the y-direction
    * Line 5: Easting UTM coordinate
    * Line 6: Northing UTM coordinate

Now it seems that TG2 does not currently reference the image properly if the data is in UTM format and it would be really nice if it was able to do so.

When loaded this file inputs the following fields:

NW Corner lat long: xyz: 180000, 0, -424800
NE Corner lat long: xyz: 180000, 0, -423000
SE Corner lat long: xyz: 179100, 0, -423000
SW Corner lat long: xyz: 179100, 0, -424800

When it should be converted to this:

NW Corner lat long: 50, -118
NE Corner lat long: 50, -117.5
SE Corner lat long: 49.75, -117.5
SW Corner lat long: 49.75, -118

Second question is regarding the Apex field.  Is this the center lat, long of the imported heightfield or one of the corners?  For my example that would be  49.875, -117.75.  This should theoretically move the entire heightfield to the 0,0,0 worldspace if I am correct.

Third, is there any chance of getting a "zoom to heightfield" button that will move the camera above a particular heightfield.  When working with tiny heightfields it can be a pain to try and find a 10km x 10km heightfield on the other side of the planet.

Fourth, would it be possible to add the georeferencing features to the image map shader as well?  It would be really helpful to be able to georeference an image overlay that would line up exactly where it should in real world space.  For example overlaying a road network exactly where it should be.

Thanks!

If you need/want any example files please let me know and I will make them available.

-ryan


Edit:  Added files here:

RAW DEM Data:  http://www.archer-designs.com/temp/dem/082f13.zip (5mb)
Converted Geotiff with .tfw and projection file:  http://www.archer-designs.com/temp/dem/82f13-geotiff.zip (3.3mb)

[Tangled-Universe]

Haven't read this all (yet), but this would be nice for the wiki I guess

[RArcher]

This one is more of a request for another feature, but it would be really helpful if latitude and longitude were shown for cursor position in the preview window.  Adding it beside the x, y, z and slope tracking would be really great.

[RArcher]

This one is just a bit of an oversight I would guess.

When choosing Load Heightfield, it would be nice if there was an option to filter by .tif files similar to the options to filter by .ter, .bmp, .tga.  As it is now, it is necessary to first select "all files" and then search through all you files to find the .tif file.

It is also currently possible to crash Terragen (Run Time Error) by connecting a Heightfield Erode v3 to a  Heightfield Vertical Clip to your full heightfield and pressing the "erode" button.

It would also seem that the erode function doesn't much like large (200mb) heightfields anyway as it chugs away for a few minutes then crashes anyway.

I know most of the stuff I've posted in this thread isn't used or of interest to most people, but since the geotiff options were added it would be nice if the functionality was implemented fully instead of just tacked on.

Until then, I'll just keep adding suggestions in this thread as I come across problems.

[RArcher]

Here's some more 


Loading a geotiff of Maui.

My heightfield officially covers the following area:

NW Corner: 21.0625, -156.75
SE Corner: 20.4375, -155.9375

Which would give an apex value of 20.75, -156.34375


When loaded into TG2 the values change to:

NW Corner: 21.0625,  -156.75
SE Corner:  20.4375,  -155.937

This changes the apex to, 20.75, 156.3435.

Using this information the center of the heightfield is off by -26.077m in the x direction and 53.116m in the z direction.

Reinputing the original apex information correctly aligns the x direction to 0, but the z direction is still off by 53.116m.


I can only guess that this error is being introduced because many data fields are now cropping and rounding after 6 digits.

[Oshyan]

Thanks for the feedback. It's definitely appreciated. The georef does need a bit more fine-tuning.

- Oshyan

[Matt]

Hi Ryan,

Thanks for all the feedback. Replies below.

Now the problem is that the .tfw file is in the UTM coordinate system in the following format:

0.75000000000000000     
0.00000000000000000     
0.00000000000000000     
-0.75000000000000000   
-424800.00000000000000000
180000.00000000000000000

    * Line 1: pixel size in the x-direction
    * Line 2: rotation about y-axis
    * Line 3: rotation about x-axis
    * Line 4: pixel size in the y-direction
    * Line 5: Easting UTM coordinate
    * Line 6: Northing UTM coordinate


Now it seems that TG2 does not currently reference the image properly if the data is in UTM format and it would be really nice if it was able to do so.

I'll see if I can accommodate this in future. The problem is that the .tfw file (and I think even the .prj file, looking at the example you uploaded) don't give me enough information to know whether to interpret as metres (e.g. UTM) or as lat-long.

I can address that by giving you more settings.

But.. it looks like there's an inconsistency in the example above. The Easting and Northing values are in metres, but the pixel sizes (which are 0.75 here) are in arcseconds I guess. They should be in the same units as the Easting and Northing values according to what I've read elsewhere, but if I interpret them as such your terrain will be too small. So... I can code something to work with this file (knowing it's arcseconds), but that hack might break it for other files.

EDIT: maybe they're not in metres. Are they all in arcseconds here? Other UTM examples I've read about are in metres.

The required data is often stored in the geotiff file itself, but it's a lot more work to fully support those data. I am going to look into it though.

I don't know what the best short term solution to this is. For now I am just supporting lat-long georeferencing information in the .tfw files, unless you have some ideas to how to solve the apparent inconsistency above.

Second question is regarding the Apex field.  Is this the center lat, long of the imported heightfield or one of the corners?  For my example that would be  49.875, -117.75.  This should theoretically move the entire heightfield to the 0,0,0 worldspace if I am correct.

You can choose whatever apex you want. It doesn't even need to be one of the corners or the center. If you choose one of the corners, it just means that corner will then lie directly on 0,0,0. If you choose the centre, the centre will lie on 0,0,0. It's probably not important, you just want to choose something that is somewhere around your heightfield so that your heightfield appears somewhere near the origin where it's most convenient and accurate. Therefore don't worry if you enter rounded values in the planet apex setting. Just choose something and don't change it after you start adding objects, image maps etc. to your scene.

Third, is there any chance of getting a "zoom to heightfield" button that will move the camera above a particular heightfield.  When working with tiny heightfields it can be a pain to try and find a 10km x 10km heightfield on the other side of the planet.

I'm sure that's something we'll get to. For objects and other things too.

Fourth, would it be possible to add the georeferencing features to the image map shader as well?  It would be really helpful to be able to georeference an image overlay that would line up exactly where it should in real world space.  For example overlaying a road network exactly where it should be.

Yes, I'm hoping to do that pretty soon.

Matt

[Matt]

Here's some more 


Loading a geotiff of Maui.

My heightfield officially covers the following area:

NW Corner: 21.0625, -156.75
SE Corner: 20.4375, -155.9375

Which would give an apex value of 20.75, -156.34375


When loaded into TG2 the values change to:

NW Corner: 21.0625,  -156.75
SE Corner:  20.4375,  -155.937

This changes the apex to, 20.75, 156.3435.

Using this information the center of the heightfield is off by -26.077m in the x direction and 53.116m in the z direction.

Reinputing the original apex information correctly aligns the x direction to 0, but the z direction is still off by 53.116m.


I can only guess that this error is being introduced because many data fields are now cropping and rounding after 6 digits.

The values you see in the edit boxes may be rounded, but internally the value may have been stored with higher accuracy. The only time this accuracy is lost if if you then start editing the value, in which case you're then 'entering' the truncated displayed value, copying and pasting values etc. (Accuracy can also be lost when saving a .tgd or .tgc, but it stores up to 10 significant digits.)

But as I said in my other reply, you don't need to be so accurate when you choose a value for your planet's apex. All that does is decide where to position your heightfield, and it's not important to have it exactly centred. You should just choose reasonable values that bring your heightfield near the origin, and then stick with those values.

Matt