Drop/port c++ plugins

[nyalldawson]

It's pretty much universally agreed that the inbuilt c++ plugins are evil, and should be either:

• ported to python and moved to the plugin repository
• ported to python and made enabled by default and not able to be disabled (eg like the console)
• ported to core libraries and made a processing algorithm
• ported to core libraries and added to app

3.0 would be a good time to address this, as we are already bringing other large changes for users.

My suggestions would be:

• coordinate capture: basic functionality moved to right click menu, complete functionality now offered by third party plugin
• evis: removed
• geometry_checker: ported to analysis library with a revamped python gui, made enabled-by-default
• geometry_snapper: ported to analysis with a processing algorithm frontend
• georeferencer: ported to analysis and app - gps importer: reworked into nicely integrated functionality such as data source manager tab, instead of one giant all encompassing dialog
• grass: can't see any alternative to a c++ plugin here
• heatmap: ported to analysis with a processing algorithm frontend
• interpolation: replaced with a Processing fronten
• offline editing: most of the guts of this is already in core, so we could either move the interface to app or to a python plugin (enabled by default or in the repo)
• oracle raster: ???? removed from QGIS
• raster terrain analysis: replaced with a Processsing frontend
• road graph: ported to analysis with a processing frontend
• spatial query: not sure there is a strong requirement for this plugin anymore - 90% of what it offers is available through processing
• topology: logic moved to analysis and merged with geometry checker? ;)

[NathanW2]

+1

offline editing:would be nice as core and not as a plugin. Project -> Take Offline.

[nyalldawson]

https://github.com/qgis/QGIS/commit/9b667d1e8a0759a8f4d807cae98e7e4224dbf5ac removes the geometry snapper plugin

[pcav]

Hi Nyall, thanks for raising this. My comments (when different from +1) below:

evis: ideally ported to python and moved to plugin repo this would be great, but I think the workflow should be much simplified and the interface updated

geometry_checker: ported to analysis library with a revamped python gui, made enabled-by-default I found it relatively unstable, crashing often, so I would suggest to take extra care in porting

gps importer: ???? this is now largely obsolete; IMHO the only things still useful are:

• up- and downloading of data to and from a GPS unit; the logic of it should however be unified with the GPS panel, that AFAIK uses a different mechanism

• conversion between old data formats; this is done through GPSBabel, unsure if this is still usable, and that GPSBabel is still shipped in the package; this is a legacy function, unclear how many people still have these kind of files

  heatmap: ported to analysis with a processing algorithm frontend agreed, a perfect candidate; it could be a good chance of fixing http://hub.qgis.org/issues/9124

  offline editing: most of the guts of this is already in core, so we could either move the interface to >app or to a python plugin (enabled by default or in the repo) maybe this could be integrated into DB Manager

  spatial query: not sure there is a strong requirement for this plugin anymore - 90% of what it >offers is available through processing I do not think this is still needed, but probably better asking the users

  topology: logic moved to analysis and merged with geometry checker? ;) merging would be very good; this is still one of the remaining duplications of functions; quite confusing for users

[m-kuhn]

I was thinking about exposing offline editing in processing. It can make sense to integrate it in a model (extent to selection, only copy selected features offline / use the same extent to make an offline copy of a WMS layer ... ).

The offline editing plugin could still continue to exist in a python plugin.

[alexbruy]

+1 for this proposal.

• interpolation: has already been partially ported to processing. C++ plugin still has some features not available in processing version which need porting.
• raster terrain analysis: has already been partially ported to processing. C++ plugin still has some features not available in processing version which need porting.

I plan to work on both plugins and move remaining functionality to Processing

• road graph: most of the guts of this is already in analysis, so we could either move the interface to app or to a python plugin (enabled by default or in the repo)

Why not move in to Processing? I also can take care of this.

Also it is a bit offtopic here, but there is related issue #60. We have lot of geoprocessing algs implemented in Python inside Processing and in the same time we have some of them implemented in the analysis library. IMHO it would be nice to put geoprocessing algs in analysis library too.

[nyalldawson]

@m-kuhn

I was thinking about exposing offline editing in processing. It can make sense to integrate it in a model (extent to selection, only copy selected features offline / use the same extent to make an offline copy of a WMS layer ... )

Great - sounds perfect.

The offline editing plugin could still continue to exist in a python plugin.

Are you thinking included with qgis and enabled by default or manually installed via the repo?

[nyalldawson]

@alexbruy

I plan to work on both plugins and move remaining functionality to Processing

Fantastic news!

road graph: most of the guts of this is already in analysis, so we could either move the interface to app or to a python plugin (enabled by default or in the repo) Why not move in to Processing? I also can take care of this.

I guess I was thinking that the configuration of the graph might not be translatable to a processing algorithm. But if you think different, then I'd be very happy to see this also as part of processing. It'd be very useful to be able to generate paths from models.

[luipir]

roadgraph has a python wrapper plugin called RAZ (http://plugins.qgis.org/plugins/raz/) and can be used as base. The advantage to use it is that can be select multi points for start and stop. Something that can be solved using v.net.path with Processing iteraction on features, btw grass algoritms has I/O overhead => better a porting.

[karl-magnus]

I think spatial query is a very basic GIS tool used by many not so advances users. We have select by polygon, select by expression etc. in the Attributes toolbar. And it shoud be just as easy to find. I suppose the new tool in processing is select by location. I know that you can choose to use selected features in the processing options. But it's not there in the tool as in the old one. And can you choose to use selected features in one layer and all in the other (intersection layer)? And the we have the versioning and installing problem with processing being a plugin. Just worried about this tool becomes more difficult to find and use.

[pcav]

@karl-magnus: would a shortcut like the one used to replace fTools do for you?

[karl-magnus]

@pcav: That would make it almost equivalent to today’s behavior and that's ok. Just the “use selected records or not”-option that’s accessed via processing options. But the default setting of using selected record is good. Ideally I would like to have it as a tool in a toolbar besides Select by polygon, select by expression etc for easy acces for not that experienced users. But it’s maybe just my opinion.

[nyalldawson]

Heatmap plugin is now ported across to processing and the c++ plugin has been removed.

[mj10777]

I am actively working on a 'renovation' of the georeferencer.

I hope to have the major portion finished in the next few weeks, afterwitch I was planing to write a summery of the:

• reasons for some changes in the existing logic
• reason for the enhancements being worked on

as a QEP (which I assume the the right place to do this) at https://github.com/qgis/QGIS-Enhancement-Proposals

It would remain an extra Window Application that will still interact with the main Application window

• but will be using core/app classes such as
  • QgsVectorLayer
  • QgsLayerTreeGroup
  • QgsMapTool

Since the major change will be the reverting from '.points' file to a Spatialite Database

• together with the implementation of spatialite GCP-logic (Ground Control Points) https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Ground+Control+Points
• importing existing '.points' files when found

there will be direct use of the spatialite api for Database creation

• these (static) functions have been placed in a extra class called QgsSpatiaLiteProviderUtils
  • with the idea that they should be placed inside 'QgsSpatiaLiteProvider'

So the placement of georeferencer as an extra directory inside 'app' would seem to me the best solution.

At the moment the work is being done in a release-2_18 branch

• with a LegacyMode to insure that both versions bring the same results

When completed a QGIS 3 version could then be prepaired

• without the LegacyMode
  • but retaining the importing of '.points' files when found

[mewoch]

(as a user) The two core plugins I find myself using the most are the Georeferencer and the GPSImporter.

Georeferencer

• I appreciate other comments I've heard that it feels a bit old, but I'm kind of used to the feel of it.
• I would like it very much if it didn't convert a 7 digit number int exponential notation. This length of number is very common in UTM coordinates, and it's just a pain trying to remember that 6.834091e6 is 6834091.
• I would like it if it was more consistent in it's behaviour if you modify a coordinate manually. (For instance when I've stupidly mixed my X and Y coords and I'm swaping them around). Usually if I press enter after typing the number it stays - but not always. Sometimes if I move (tab or arrow keys) from the cell it remembers, but not often. I have been known to get annoyed enough as to edit the points file and reimport. I'd like it if the number that was in there stayed put.

gps importer I still use this, despite it's flaws, for when I'm importing more than one GPX file or I want to edit the file.

• Oh! Just rechecked on 2.18 (on Jessie), and my main reason is no longer an issue. Thank you to the helpful person that rejigged the Open Vector method to prepend the the file name to the layer!
• I can edit GPX files brought in through the plugin. I can't edit GPX files brought in through Open Vector. (Yes, I know this is a gdal limitation)
• To me it seems that Open Vector GPX files are more likely to disappear at different zoom levels, which is annoying. Although maybe that's improved too.

[alexbruy]

qgis/QGIS@ce342b0 removes the Road Graph plugin

[alexbruy]

qgis/QGIS@c3e3ba6b removes the Raster Terrain Analysis plugin

[alexbruy]

qgis/QGIS@37d82bb7 removes the Interpolation plugin

[alexbruy]

qgis/QGIS@77ae8a2 removes the Oracle GeoRaster plugin

[nyalldawson]

https://github.com/qgis/QGIS/pull/5170 drops the spatial query plugin.

@karl-magnus

I know that you can choose to use selected features in the processing options. But it's not there in the tool as in the old one. And can you choose to use selected features in one layer and all in the other (intersection layer)?

That's now possible in processing 3.0. The option to use selected features is present for EACH input individually, and is shown in the parameter dialog (i.e. it's no longer a semi-hidden global setting)

[staciekoslovsky-noaa]

I just found this comment string and am curious about the future of functionality encapsulated in the current eVis tool in the upcoming release of QGIS 3.0. We use the eVis tool extensively for reviewing geo-tagged images and want to make sure we are well-prepared for potential changes.

[nyalldawson]

There's been no changes to Evis yet, and I'm not aware of anyone working on them.

We won't drop this plugin without a viable alternative

[nyalldawson]

Evis and globe are now removed

[uclaros]

Coordinate capture is also removed and ported to python

[nyalldawson]

@uclaros thanks, updated

[nyalldawson]

https://github.com/qgis/QGIS/pull/44508 removes the GPS tools plugin