And add a new target CRS argument to parameterAsExtent. If set, and
the source CRS of the rectangle parameter can be determined, then
the returned value will be the rectangle automatically reprojected
to the desired target CRS.
This is meant to be used by plugins (DBManager is the
first candidate) to notify the application that
the GUI elements that handle connections needs to
be updated (i.e. the data source manager dialog
and the browsers)
input layers with Z or M values present
Also ensure that written geometries are always multitype, to
match the created layer geometry type (before the layer was
being created as a multi* layer, but single part geometries
were sometimes created. This causes errors with some data
providers)
Like the main Join Attributes by Location algorithm, this algorithm
takes two layers and combines the attributes based on a spatial
criteria.
However this algorithm calculates summaries for the attributes for
all matching features, e.g. calculating the mean/min/max/etc.
The list of fields to summaries, and the summaries to
calculate for those, can be selected.
Improvements:
- transparently handle different source/join CRS
- added option to create output feature for EVERY joined
feature (i.e. 1 to many type join)
- added option to select joined fields to take
- optimised performance of algorithm
The previous option to create a summary of joined features has been
removed, and will be moved to a separate 'Join by location (summary)'
algorithm.
Instead of including these classes in app, we instead make a
shell data provider which implements only the dataItemProviders()
and sourceSelectProviders() methods.
Helps keep GeoNode GUI related code partitioned
Avoids a lot of duplicate code.
Note that while this refactoring was done to allow WFS and WMS
settings to be simultaneously visible, I've removed the settings
from the GeoNode connection for now. Looking into this they were
being stored, but not used at all when loading the layers from
the GeoNode instance.
