a batch geocoding algorithm from a QgsGeocoderInterface
Example usage:
# create a class which implements the QgsGeocoderInterface interface:
class MyGeocoder(QgsGeocoderInterface):
def geocodeString(self, string, context, feedback):
# calculate and return results...
my_geocoder = MyGeocoder()
# create an algorithm which allows for batch geocoding operations using the custom geocoder interface
# and implement the few required pure virtual methods
class MyGeocoderAlgorithm(QgsBatchGeocodeAlgorithm):
def __init__(self):
super().__init__(my_geocoder)
def displayName(self):
return "My Geocoder"
def name(self):
return "my_geocoder_alg"
def createInstance(self):
return MyGeocoderAlgorithm()
# optionally, the group(), groupId(), tags(), shortHelpString() and other metadata style methods can be overridden and customized:
def tags(self):
return 'geocode,my service,batch'
[FEATURE] Introduces mesh virtual datasets
With the mesh calculator the user can choose to create those "virtual" dataset groups that will be added to the layer. Then, for these dataset groups, values are not stored in memory but each dataset is calculated when needed whit the formula entered in the mesh calculator.
Those virtual dataset groups are saved with the project.
If needed, the user can remove them or can persist them on files to make them persistent.
Co-authored-by: Étienne Trimaille <gustrimaille@yahoo.fr>
The mesh styling dialog now has new combo box for selection of resampling method for datesets defined on faces.
Also the analysis library has new class QgsMeshContours with export function for contour lines and contour polygons.
Similarly to raster calculator, mesh calculator can take dataset groups from current mesh layer and
combine them with various aritmentic/logical operators to new dataset group.
Contains utilities for retrieving the geotag from images and
for setting an image's geotag.
Working with geotags (before this class!) is super-annoying
and fiddly and relies on either parsing command line tools
or depending on non-standard Python libraries which are
not available everywhere, and often very difficult for users
on certain platforms to get installed and working correctly.
With this class we have stable methods for geotag getting/setting
which are universally available and can be used safely
by plugins and scripts.
Because:
- it's unused in master, and is more code to maintain
just for possible use by plugins
- it's unmaintained, and has had no work done (beside compilation
fixes) in the recent past
- there's no unit tests or detailed documentation to show
how the class should be used
These classes still need a lot of cleanup (e.g. use of proper
3d geometry classes instead of their own 3d line classes, etc)
and we don't want them locked into the 3.0 API.
Better to remove them from the API and reintroduce them after
they have been cleaned up (in >3.0). They are mostly implementation
details anyway, and unlikely to be used outside of the high
level interpolation classes.
We don't want these part of stable API - this namespace really shouldn't
exist, as it mostly contains code which is duplicated in other
parts of the API (with better maintained and tested versions).
These classes are unused in the master QGIS code, and are
unmaintained and with no unit tests or other QA, and
have inflexible API (e.g. always requiring writing outputs
to shapefiles)
They all have equivalent algorithms available via Processing
(where the algorithms are unit tested and maintained). We should
be pushing all QGIS api users to use the Processing algorithms
instead.
