Bad geo-referencing bug fix
Using VRT with large coordinate system (like RGF93/CCxx) and high
resolution raster, highest resolution tiles were shifted regardingi
original raster.
It seemed that when creating the VRT file, georeferencing is
truncated while converted to text, leading to loss of precision.
Allows the full range of formatting options exposed through
text renderer - e.g. scalebar text with buffers, shadows,
background shapes, letter spacing, etc.
Say goodbye to unreadable scale bar text!
Because users are still getting confused with the difference
between the cartesian areas and ellipsoidal areas, show both
in the identify results dock.
The reasoning here is:
- if a user understands this concept, they will know the correct
one to use, and its good for us to inform them of the difference
here. Plus, it means they immediately see if the ellipsoid
setting is correct and the difference it is making for the
area/length calculation.
- if a user has no idea what the difference is, then we should
make them aware that there's (at least!) two different possible
measurement values. They can then either research what these mean and make
the right choice (and become better informed GIS practitioners),
OR pick a random one - which really is no different then the
previous situation, because an uniformed user is just as likely
to be working in an unsuitable projection with a poor ellipsoid
choice.
In short, we don't try to guess the right choice for users
and instead give them all the information and let them make the
call which value to use.
Often the polygonZ/multipatch data do not have consistent ordering of vertices
(e.g. all clock-wise or counter clock-wise). Disabling culling helps to avoid
seemingly missing surfaces, but the shading is still not correct due to reversed
normals. This new option to add back faces fixes the problem: for each triangle
we create both front and back face with correct normals - at the expense of increased
number of vertex data.
Instead of using 'SDO_UTIL.FROM_WKTGEOMETRY' to generate `SDO_GEOMETRY` object
for Point, the `testdata` generate Point and MultiPoint with `SDO_POINT_TYPE`
or `SDO_ELEM_INFO_ARRAY` and `SDO_ORDINATE_ARRAY`.
With this way of creating Point and MultiPoint, we can test the way Point and
MultiPoint are converting to WKB.
Since it's not directly possible to pop the last command off
an QUndoStack (the command which is destroyed/discard by calling
this method), we add a dummy obsolete command to force this to occur.
Pushing the new command deletes the destroyed one, and since the new
command is obsolete it's automatically deleted by the undo stack.
