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.
width buffers
Adds:
- tapered_buffer
- buffer_by_m
expression functions. These expose the same functionality as the
equivalent processing algorithms but for use in expressions
such as geometry generators.
Adds geometry methods to create variable width buffers, including
tapered buffers (with a specified start and end diameter) and
variable width buffers from line string m values.
Also adds processing algorithms which expose these methods
to processing.
Include descriptive text with the specified parameter value
in error, and always check that sources were loaded to avoid
raw Python exceptions when they are not
This pull request is a subset of #6490
This adds a new library for creation of applications based on Qt Quick
framework.
It contains reusable QML / Qt Quick components based on QGIS core
library.
The initial work introduces MapCanvas
To enable compilation of the library, use WITH_QUICK=TRUE
Further documentation of the library is located in doc/qgsquick.dox
For background information see the associated QEP:
qgis/QGIS-Enhancement-Proposals#109
The initial implementation is largely based on the work of Matthias Kuhn
and Marco Bernasocchi on QField probject - kudos to them for the great
job!
