Before we had two checks - equals() and isGeosEqual() which
performed the exact same check (since equals() called the geos
equality test)
Since the geos equality test is a slow, topological test, which
considers two geometries equal if their component edges overlap,
but disregards ordering of vertices this is not always what we
want. There's also the issue that geos cannot consider m values
when testing the geometries, so two geometries with different
m values would be reported equal.
So, now calling QgsGeometry::equals performs a very fast, strict
equality test where geometries are only equal if the have exactly
the same vertices, type, and order.
And swap most code which was calling the slow geos test to instead
use the fast strict native test.
This forces Python code and plugins to become datum transform
aware, and given that upgrading python code is easy (just
add QgsProject.instance() as a new argument to the constructor)
it's relatively painless to force this on PyQGIS users.
Also fix upgrade the easy QgsCoordinateTransform c++ constructors
where the project is available, or where using QgsProject::instance()
is safe to do.
For others, just avoid the deprecated warnings until we can
get access to the correct project instance where the transform
is being constructed.
These methods are not used in master and are of questionable
value. Better to serialise the source and dest crs separately
and create the transform when required
* update HTML data provider metadata for grass, gdal and ams
* update HTML data provider metadata for WMS and WCS
* move HTML bullet list to QgsHtmlUtils
This option was being applied in the wrong place - within the
map layer classes themselves. This meant that depending on the
user's setting for this option, a plugin calling QgsMapLayer::setName
would not be guaranteed the same behaviour across installs.
(and the same with setDataSource)
Similarly, the option was re-applied on project load, so
moving projects between installs with different values for
this setting would affect the project layer names, breaking
expressions which relied on these...
Instead, move the formatting and capitalization of layer
names to the QgisApp add*Layer methods instead, so this option
only applies on adding new layers to a project.
...by moving extra arguments to new LayerOptions structs. This allows
us to more easily add new layer constructor options without making
the API cumbersome to use.
- Remove QgsSvgCacheEntry from public API (is an internal detail only)
- Modernize code
- Make protected QgsSvgCache members private, since this class is not
designed to be subclassed
- QgsGeometry::fromPoint() was renamed to fromPointXY()
- QgsGeometry::fromMultiPoint() was renamed to fromMultiPointXY()
- QgsGeometry::fromMultiPolyline() was renamed to fromMultiPolylineXY()
- QgsGeometry::fromPolygon() was renamed to fromPolygonXY()
- QgsGeometry::fromMultiPolygon() was renamed to fromMultiPolygonXY()
Previously the method in QgsGeometryUtils was relying on
QgsAbstractGeometry::coordinateSequence, which is an absolute
performance killer.
Instead move to optimised methods in the various abstract
geometry subclasses which rely only on trivial calculations.
and add new QgsGeometry::fromPolyline which uses QgsPoint
We want to encourage people not to use the QgsPointXY method, as it drops
Z/M values. So it's moved across to a different name to make way
for a new QgsGeometry::fromPolyline which uses a QgsPoint list
instead of QgsPointXY, thus keeping Z/M values intact.
Similarly, QgsPolyline now is a list of QgsPoint (keeping z/m values)
and the old 2d QgsPolyline type was renamed to QgsPolylineXY.
Making the QgsPoint method the "preferred" method and making linestrings
just as easy to create from z/m dimensioned points as 2d points is
important to push people to write code which does not discard
these important dimensions.
As a bonus, the QgsPoint methods are more efficient anyway, since
they don't require creation of a temporary list.
