Better Georeferencing Support request

Started by uuderzo, June 16, 2020, 02:59:29 am

Previous topic - Next topic

uuderzo

June 16, 2020, 02:59:29 am Last Edit: June 16, 2020, 03:43:26 am by uuderzo
Hello!

I'm a new Terragen Pro user and my first "test project" was to render a georeferenced DEM patch with a projected NON-georeferenced satellite image.
After placing the planet origin on the DEM patch (as it's centered in European area and i had navigation issues before that) i still have serious difficulties in projecting the satellite image over the DEM patch. I extrapolated satellite image coordinates by hand and they are expressed in degrees using WGS84 coordinate system.

Terragen understands well the georeferenced patch and it's placed accordingly on the planet, but for the satellite image it's another story. I don't have a clue on how to convert WGS84 degrees coordinates into XYZ "flat planet" Terragen coordinate system, and i cannot use the DEM boundary as guide because the satellite image is a sub-area of the DEM patch. So a long trial and error work is needed to match the two elements and i'm still struggling understanding if i'm wrong with the picture projection size and/or coordinates. Moreover, trying to move the picture my trial and error is made really difficult by the need to wait for the viewport refresh after each slight modification.

As the Pro version states it handles geo referred data (and it does indeed) i expected a better support for manual inputting of the coordinates.

Hence my proposal: Terragen works with its internal XYZ coordinate system, and that's right because it sure will speed up its internal calculations.
But... what if the position input fields could be modified to accept also other coordinate systems? After all, Terragen already "understands" other coordinate systems because it can import georeferenced data, the only issue with that is that the data must be embedded into the input file and cannot be inputted manually.
I mean... Terragen should already have all the conversion functions inside.

The input boxes could work as an intermediate layer, that allow the user choose the reference system for inputting the positional coordinates and under the hood those coordinates are on the fly converted into Terragen XYZ coordinates, while mantaining the original coordinate system values on the user side.
Maybe by adding a new drop down listbox where appropriate that defaults to Terragen internal coordinate system but allows the user to change how the inputted numbers will be interpreted by the application. Being able to choose the coordinate system in nodes where external data is specified, such as "Geog image map" would be really useful for my workflow!

I mean... i could input my hand extrapolated coordinates in a "one shot one kill" fashion, save a lot of time and be sure it's everything correctly aligned without doubts. On the other side, Terragen could be more easy to grasp when facing those situations by more users so i think this can be a nice addition.

I don't know if this idea could be extended to each node, maybe this could be useful and sure it would add uniformity to the whole user experience. Say, for example, that one needs to place a building on a specific location obtained by cartographic extrapolation, such as UTM charts ans so on. This would make the whole process a breeze.

What do you think?

Thanks! Umberto

uuderzo

I add a screenshot just to better explain my proposal.

Please notice the drop down list just over the coordinates input boxes.
This list should contain all the projection systems known to Terragen. Obviously the default will be "Terragen default".

I think that a drop down list box should be added because it would act as unifying element of all input boxes in a certain logical group.
My initial thought was a smaller popup near the coordinates copy/paste button but this would have a double disadvantage:
  • each coordinate pair would have a potential different projection system and this would cause a "logical" mess while terragen maybe would work still well with it. Maybe each logical group of input boxes could be synchronized but still not nice imo.
  • it would be difficult to have a glimpse on what projection system is corrently configured.

sboerner

I've run into the same issue. Interesting suggestion.

WAS

You definitely did a waaaaay better putting this feature request together than I had in my mind. This sounds really promising for users coming from other coordinate and measurement systems.

uuderzo

Thank you WAS for you support in helping me defining the request!

Matt

Georeferencing projections are performed by a third party library, GDAL. Perhaps we could get Terragen to be more involved in the reprojection, but I'm not sure at the moment.

Do you have latitude and longitude information for the corners of the image? If so, it should be possible to manually enter them into the Geog Image Map Shader (uncheck "Auto georeference from file" and uncheck "Reproject on the fly").
Just because milk is white doesn't mean that clouds are made of milk.

uuderzo

Well... i performed some tests and inputting lat/lon inverted i get a projection near to what i'm after. It's not perfect, there is an offset but now i need to understand if i miscalculated my coordinates or if the DEM has come geo referencing issues. Anyway, it's a quantum leap for me that i can nearly match the two elements by inputting known coordinates.

I still cannot understand a point: given that the tiff file i'm using for satellite image has no geo referenced data and no coordinate system defined, how do Terragen manage do understand my degrees coordinates if it doesn't know the projection? Do it assume WGS84 by default?

Thanks! Umberto

WAS

I think what he means, is you can load the regular tiff image with the Geog Image Map shader, and apply your own coordinates. But the coordinates provided from your project don't seem to work.

uuderzo

June 18, 2020, 03:00:15 am #8 Last Edit: June 18, 2020, 03:04:18 am by uuderzo
Well, yes... in my mind the external coordinates that i manually computed need a related projection system to be correctly interpreted by the software.
This is where i'm puzzled and this is the reson i proposed for a manual projection system override when necessary to make the software digest whatever coordinate i have without trying to convert them in XYZ flat planet (which i dubt is a standard outside Terragen). Well i don't pretend Terragen to eat strange projection systems such as Montemario (which is very italian singularity). Moreover, the peculiar node flow structure of the software brings the user to a more numerical approach to terrain generation, and being forced to trial and error when projecting external data doesn't match well with all the rest imo.

To be clear... if i need to do terrain art without real world references the problem fades out, but if i have to refer external resource it's easy to get into a coordinate nightmare :D

Just to say, i'm a speleologist and i love to render cave entrances surroundings for better environment understanding. Sure it's only an hobby, but why not :)

Matt

Quote from: uuderzo on June 17, 2020, 03:30:09 amI still cannot understand a point: given that the tiff file i'm using for satellite image has no geo referenced data and no coordinate system defined, how do Terragen manage do understand my degrees coordinates if it doesn't know the projection? Do it assume WGS84 by default?

Thanks! Umberto

I am not very familiar with the WGS84 projection, but I believe it is important to model the shape of the Earth more precisely than a simple sphere. The Terragen planet is a mathematically perfect sphere (before displacement shaders are applied), so WGS84 doesn't apply. The latitude and longitude values are simple to map to positions on the surface of this sphere. Any lat/lon position is easy for the software to place relative to any other lat/lon position. As long as all projections obey this simple formula, everything should work.

If you know the lat-lon positions of the corners of a map, it should be possible to align them with other maps in many cases. However, things might get a bit dicey towards the north and south pole, as the interpolation of values can be interpreted slightly differently by different systems. I am not sure how often this causes problems in practice.

Terragen's UI is strongly biased towards placing things in XYZ (which isn't unique to Terragen by any means) and unfortunately lacks a good set of lat/lon displays and tools, but the Geog Heightfield and Geog Image Map tools are intended to allow you to align different maps based on their lat/lon coordinates, and I hope that is working. The Geog Image Map shader has an option called "Reproject on the fly" which calls on the GDAL library to figure out a more precise mapping, but this might be different from what the Geog Heightfield shader does so you might not always be able to use it.
Just because milk is white doesn't mean that clouds are made of milk.

Matt

Quote from: uuderzo on June 18, 2020, 03:00:15 amThis is where i'm puzzled and this is the reson i proposed for a manual projection system override when necessary to make the software digest whatever coordinate i have without trying to convert them in XYZ flat planet (which i dubt is a standard outside Terragen).

I'm not really sure what you mean by this. Entering lat/long coordinates by hand is the simplest "manual projection system override" I can think of. Can you give me more info on what you'd like it to do?
Just because milk is white doesn't mean that clouds are made of milk.

Matt

I got the impression that you are already using the "Lat long at apex" setting of the Planet, but if not, this may be useful:


When you use a georeferenced DEM and the Georeference parameter is checked it will be placed at the correct position on the planet. However accuracy falls away as you move away from the origin of the planet, which corresponds to 0° latitude, 0° longitude or the Prime Meridian at the Equator. To ensure the best accuracy it's suggested that you move the planet origin to the area you're interested in. It's easy to do this. Let's say you've loaded a DEM and it's georeferenced. We'll move the planet origin so that it's at the southwest corner of the DEM. Follow these steps:

1) Click the copy/paste button (clipboard icon) at right of the SW corner lat long parameter.
Choose "Copy coordinates" from the menu which pops up. This will copy the lat/long values from both text fields at the same time.

2) Open the parameter view for the Planet 01 node (the default planet object). You can find this in the Objects node list or double click on the node in the network view.

3) Paste the values into the planet's Lat long at apex parameter. You should use the copy/paste button for this again. Click the button and choose "Paste coordinates".

Those steps move the planet origin to the area you're interested and should ensure the best results.


From https://planetside.co.uk/wiki/index.php?title=Geog_Heightfield_Load

It doesn't have to be one of the corners, it can be anywhere in your area of interest, but the instructions use one of the corners because they're easy to copy and paste with the clipboard.

Just because milk is white doesn't mean that clouds are made of milk.

uuderzo

@Matt, after your explanation on how Terragen handles coordinates i better understand how it works. I misunderstood the georeferencing features of Terragen, as i intended that it would handle and project correctly on several different systems. There are projections that don't work in degrees but in meters, such as UTM where you need to specify the quadrant name and the cartesian coordinates of a point into the quadrant (in fact i didn't understand how to input such coordinates and i guessed that they were handled exclusively through file metadata reading).

I don't know if GDAL handles UTM but sure if the manual input fields interpret numbers as degrees, there would be some incompatibility.
This is the reason i proposed being able to specify the projection system for each node, so one can be in degrees, one in meters and so on.

I'm not really interested in seeing a projection on the very perfect real planet earth position, just interested in some kind of compatibility between projection system. That said, now i know that it's necessary to use the same projection system for all different components of the project to get the result. Obviously excluding the UTM system which is another cup of tea.

Not a real issue, just needed to understand that.

Thanks! Umberto