Tagged as feature to be included in release notes.
Because:
- The use case for this algorithm is very unclear for users - the name
does not describe what the algorithm does, and there's no help
documentation available for the algorithm either. Given this I suspect
that the algorithm is not being put into use.
- The algorithm needs enhancement to be more useful. There's no logic
in place which dictates how neighbouring features are chosen to
dissolve into the selected feature (it's effectively random - you're
just as likely to get a huge narrow polygon stretching across a map as
you are a nice compact cluster). To be more useful the algorithm would
need logic to either minimise the area of the dissolved feature, or
minimise the total number of dissolved features, or ... ?
Improvements:
- Maintain Z/M values
- Keep original data type for group/order fields
- Group field is optional
- Added unit tests
- Don't export text files for features by default
Improvements:
- transparent reprojection to match hub/spoke CRS
- keep all attributes from matched hub/spoke features
- don't break after matching one hub point to spoke - instead
join ALL hub/spoke points with matching id values
Allows upgrading geometries to include these dimensions, or
overwriting any existing Z/M values with a new value.
Intended mostly as a test run for QgsProcessingFeatureBasedAlgorithm
Instead of a separate Points In Polygon algorithm just for this
extra option, add it to the original Points In Polygon algorithm
as a non-default option.
- Add QgsGeometry method to densify by distance
- Fix bug in processing algorithm which resulted in duplicate
vertices and incorrectly spaced extra vertices
features assigned to same color
This is the most cartographically pleasing color arrangement in my
opinion as it creates a nicely distributed set of colors.
This ports to old (pre 2.0!!) topocolor plugin to processing. It's based
off my beta 2.x fork (never publicly released) which implemented
a bunch of improvements to the algorithm allowing for minimal number
of required colors and also balanced counts of features assigned
each individual color.
** Pretty sure this plugin was highlighted in Victor's presentation
about plugins-which-shouldn't-be-plugins-and-should-be-processing-algs
instead. It's a prime example of a plugin where the amount of code
required for gui+setup exceeded the actual "guts" of the plugin by
a huge factor, and which is much more useful when it can be
integrated into a larger processing model.
If you have a layer with an unknown CRS, this algorithm gives a list
of possible candidate CRSes which the layer could be in.
It allows users to set the area (and corresponding CRS) which they know
the layer should be located near. The algorithm then tests every CRS
in the database to see what candidate CRSes would cause the layer
to be located at that preset area.
It's much faster than it sounds!! (just a couple of seconds)
Sponsored by SMEC/Surbana Jurong
Adds a new QgsGeometry::orthagonalize method which tries to make
angles in geometries either right angles or straight lines
Also adds a processing algorithm exposing this feature.
Replaces the existing 'Basic Stats for Numeric Fields' and
'Basic Stats for String Fields' algorithms and adds support
for date/time/datetime fields.
Having a single unified algorithm allows more flexible models
where a field type may not be known in advance.
Deprecate existing basic stats algorithms
Copy min area parameter from 'Fill holes' algorithm to 'delete
holes' algorithm.
Also:
- make algorithm maintain z/m values
- make algorithm work with curved geometries
- add unit tests
