Create a GMT QGIS plugin about gmt HOT 18 CLOSED

👋 Thanks for opening your first issue here! Please make sure you filled out the template with as much detail as possible. We appreciate that you took the time to contribute!

from gmt.

Hi,

Having a GMT plugin in QGIS would nice (and useful) but how to write it? From my little knowledge the QGIS plugins are written either in python or C++. But our python wrapper is still under development and is not yet ready for the job. Regarding the C++ way, I don't know but suspect it would be a substantial amount of work (and none of the GMT developers is C++ knowledgeable or even inclined)

from gmt.

Hi Joaquim,
glad you like the idea. Fortunately things are much easier. C++ is a no-go, the way is Pyhton, but we do not need a Python wrapper around GMT. From Processing we can call executables directly. We do this with GRASS, SAGA and other backends. In fact I think it should be an easy work.
I see two ways to proceed:

• either in GMT you have some resources for this, and we can provide guidance, or
• we can search for some funding (I think we don't need much at least for an initial prototype)

from gmt.

Paolo,

We have no resources to fund this work. The GMT development is all based on voluntary work (though we have some funding via NSF projects). If you say that calling the executables directly is easy, that's OK but it seems a bit poor as a plugin. We have experience with Matlab and Julia plugins and that's a full other story in terms of interoperability with other tools. Maybe @leouieda can give us an update but last time he mentioned it he was expecting to have an advanced prototype of the python wrapper at the beginning of next year.

from gmt.

From our experience this is not a bad solution. We implemented GDALTools years ago with this approach, and it proved a huge success, being incorporated into core. The Processing framework is quite powerful at this.
We'll look for funding, suggestions welcome.
Thanks.

from gmt.

OK, you know it.

from gmt.

Hi @pcav, as Joaquim mentioned my plan to have a subset of the core features ready by January next year. You can follow along at https://github.com/GenericMappingTools/gmt-python and I welcome feature requests that you might want from a Python wrapper. I never used QGIS or made plugins so I'm not sure what your requirements would be. Is QGIS Python 3 friendly?

from gmt.

Hi @leouieda , yes QGIS 3.x is 100% Py3. Certainly a Python wrapper around GMT would be useful, but a simple plugin can call executables directly, so no need to wait for this. I believe that once in place such a plugin could attract attention and lead to a better direct support for Python. IMHO it is crucial to put in place a simple prototype to facilitate funding requests.

from gmt.

Paolo, a marginal issue to this subject. How will it be expected that GMT is available when the plugin runs? I mean, is it left to users responsibility to install GMT or will the plugin installation try to take care of it?

from gmt.

IMHO better let the user install it. Having an automated way would be nice, but I guess too difficult to do it in a consistent way in all major OSs we support.

from gmt.

Fine. That is my opinion too.

from gmt.

Can you give a mini example code snippet on how to make such a small plugin @pcav?

from gmt.

@ghtmtt can be more e3fficient than me here, but you can have a look to SAGA provider:
https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/saga
and a sample alg description, e.g.
https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/saga/description/AccumulatedCost.txt

from gmt.

hi all.. sorry for the delay. As @pcav said, building a prototype should be quite smooth. This is basically the structure to call GRASS within Processing:

https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/grass7

that could be an option. Same for SAGA here:

https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/saga

and for a framework of R (old QGIS 2 with python2), here:

https://github.com/qgis/QGIS/tree/release-2_18/python/plugins/processing/algs/r

all these 3 software have a separated installation from QGIS, so the framework of the prototype could follow that lines

from gmt.

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.

from gmt.

Time to close this, I guess

from gmt.

Shouldn't be closed as wontfix?

from gmt.

Well, it was not us who proposed to do it.

from gmt.