Makes some operations with OGR sources magnitudes faster, ie
zoom to 20 selected features in a 4 million point dataset:
before: 14 seconds of blocked gui
after: instant
Win!
* Remove deprecated Qgis::WKBType and API cleanup
Renames QgsWKBTypes to QgsWkbTypes
Replaces usage of the enums:
* Qgis::WKBType with QgsWkbTypes::Type
* Qgis::GeometryType with QgsWkbTypes::GeometryType
Their values should be forward compatible (a fact that was already
explited up to now by casting between the types)
Renames some SSLxxx to SslXxx and URIxxx to UriXxx
* Fix build warnings and simplify type handling
* Add a fixer to rewrite imports
* The forgotten rebase conflictThe forgotten rebase conflicts
* QgsDataSourcURI > QgsDataSourceUri
* QgsWKBTypes > QgsWkbTypes
* Qgis.WKBGeom > QgsWkbTypes.Geom
* Further python fixes
* Guess what... Qgis::wkbDimensions != QgsWkbTypes::wkbDimensions
* Fix tests
* Python 3 updates
* [travis] pull request caching cannot be disabled
so at least use it in r/w mode
* Fix python3 print in plugins
This sanity check is unnecessary and breaks styling if the sqlite file is moved or renamed.
The t_table_catalog column is kept for backwards compatibility.
Before the algorithm was written to optimise clipping a few
features against thousands of mask features. The revised algorithm
is optimised for clipping thousands of input features against
a few mask features.
Given that this second operation is much more likely, it makes
sense to optimise for this use case.
I've also applied some other optimisations like taking advantage
of spatial indexes on the providers, using prepared geometries
and also only applying an intersection operation if the geometry
isn't wholly contained by the mask geometry.
Benchmarks:
clipping roads layer with 1 million lines against 2 polygons
before: 5 mins 30 seconds
after: 10 seconds
clipping address layer with 5 million points against 2 polygons
before: 50 minutes
after: 30 seconds
Previously there was the expressionField (a field name or an expression)
mainly used for the feature list in the form view of the dual view.
On the other hand there was the displayField which could contain either
a simple field name or a complex HTML structure with embedded expressions.
And to know what it was you could compare it's content with the field names, if
a field name matched, you used it as a displayField (original purpose) and
if not... well, you could deal with HTML if you had a use for it.
The main problem is that there are two different usages for this kind of
thing
* plain text identifier (field or expression)
* pretty, rich text feature info
This commit cleans up with this. You want rich text and a lot of info:
go for mapTipTemplate.
You want a plain text string to identify features: go for
the displayExpression.
