Re: [QGIS-Developer] Running grass algorithms in threads

[Vaclav Petras]

On Tue, Aug 14, 2018 at 8:52 PM, Vaclav Petras  wrote:

>
> # and delete the rest
> rm ~/grassdata/nc_spm/par1
> rm ~/grassdata/nc_spm/par2
> rm ~/grassdata/nc_spm/par3
> rm ~/grassdata/nc_spm/par4
>


Of course `rm -r` here.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Running grass algorithms in threads

[Vaclav Petras]

On Tue, Aug 14, 2018 at 7:10 PM, Nyall Dawson 
wrote:

> On Tue, 14 Aug 2018 at 21:43, Rudi von Staden  wrote:
> >
> > Hi all,
> >
> > The bottleneck in my script at the moment is the calculation of zonal
> stats using 'grass7:r.stats.zonal'. I thought I might speed things up by
> using QgsTask.fromFunction() or QgsProcessingAlgRunnerTask() to run these
> calculations in parallel. In my tests of both approaches the tasks seem to
> complete (task.status() == QgsTask.Complete), but the output file is only
> generated for 1 of 4 parallel tasks (the task that finishes first).
> >
> > I'm assuming this is because grass algorithms are not thread safe? Or am
> I missing something in my implementation that could make this work?
>
> I strongly suspect that grass algorithms cannot be run in parallel.
> This is why they cannot run in the background in QGIS like the
> native/GDAL algorithms can. But I'd love for confirmation about this
> and whether there's any way to make GRASS multi-thread safe.
>


In general, it works. You can run GRASS modules in parallel if you set
things right which is best achieved by running the parallel processes in
separate GRASS mapsets.

GRASS modules are separate processes, so we are talking about parallel
processes, rather than threads, so there are pretty separated. You can run
for example (assuming GRASS GIS session in NC SPM location, new/empty
mapset, and Linux command line, so that & starts process in the background):

r.neighbors input=elevation output=elevation_1 size=21 &
r.neighbors input=elevation output=elevation_2 size=21 &
r.neighbors input=elevation output=elevation_3 size=21 &
r.neighbors input=elevation output=elevation_4 size=21 &

However, conflicts may arise if you are changing computational region at
the same time as doing calculations or if you are writing vectors using the
default settings for attribute table, i.e. one SQLite db for all vector
maps in a mapset. You can make these things work, e.g. by passing a
computational region through environment rather than by g.region or by
using different backend for attributes. However, the safest way are the
separate mapsets, for example (assuming Linux for & and an existing
location called nc_spm):

# create the mapsets
grass -e -c ~/grassdata/nc_spm/par1
grass -e -c ~/grassdata/nc_spm/par2
grass -e -c ~/grassdata/nc_spm/par3
grass -e -c ~/grassdata/nc_spm/par4
# run v.random (just an example which creates vector with attributes)
grass ~/grassdata/nc_spm/par1 --exec v.random output=points_1 column=value
npoints=100 &
grass ~/grassdata/nc_spm/par2 --exec v.random output=points_2 column=value
npoints=100 &
grass ~/grassdata/nc_spm/par3 --exec v.random output=points_3 column=value
npoints=100 &
grass ~/grassdata/nc_spm/par4 --exec v.random output=points_4 column=value
npoints=100 &
# just to finish the example, let's merge the vectors in a new mapset
grass -e -c ~/grassdata/nc_spm/par
grass ~/grassdata/nc_spm/par --exec v.patch input=points_1@par1
,points_2@par2,points_3@par3,points_4@par4 output=points
grass ~/grassdata/nc_spm/par --exec v.info map=points -t
# and delete the rest
rm ~/grassdata/nc_spm/par1
rm ~/grassdata/nc_spm/par2
rm ~/grassdata/nc_spm/par3
rm ~/grassdata/nc_spm/par4

I'm assuming that we are talking about running algorithms in parallel in
QGIS, not parallelism inside the algorithms. Other considerations apply to
that (parallelization is controlled by the modules themselves, see e.g.
nprocs option for r.sun or v.surf.rst in G 7.4). Note that I'm talking
about (pure) GRASS, so it depends how QGIS is handling it (I recall it is
using --exec, but I don't know what it is doing with locations and
mapsets). Please also note that I didn't measure if the v.random example
would be actually more advantageous the a single process.

Best,
Vaclav


> Because this is grass related (and not QGIS specific) I'd suggest
> asking on the grass mailing list, and relaying any responses back
> here.
>

> Nyall
>
> >
> > Thanks,
> > Rudi
> >
> >
> >
> > My code for the QgsTask approach is as below:
> >
> > def getZonal(task, habitatModelFile, cover):
> > tempFile = QgsProcessingUtils.generateTempFilename("output.tif")
> > processing.run("grass7:r.stats.zonal", {
> > 'base':habitatModelFile,
> > 'cover':cover,
> > 'method':5,
> > '-c':False,
> > '-r':False,
> > 'output':tempFile,
> > 'GRASS_REGION_PARAMETER':None,
> > 'GRASS_REGION_CELLSIZE_PARAMETER':0,
> > 'GRASS_RASTER_FORMAT_OPT':'',
> > 'GRASS_RASTER_FORMAT_META':''},context=context,feedback=
> algFeedback)
> >
> > if task.isCanceled():
> > deleteFile(tempFile)
> > return
> >
> > return tempFile
> >
> > ls90Task = QgsTask.fromFunction('LS90', getZonal, habitatModelFile=hm1,
> cover=ls90Layer)
> > QgsApplication.taskManager().addTask(ls90Task)
> > feedback.pushInfo("Calculating LS14 mean...")
> > ls14Task = QgsTask.fromFunction('LS14 ', getZonal, 

Re: [QGIS-Developer] [Qgis-user] Mac QGIS 3 GRASS fix

[Vaclav Petras]

On Thu, Mar 22, 2018 at 6:56 PM, Nyall Dawson 
wrote:

> On 23 March 2018 at 08:47, William Kyngesburye 
> wrote:
> > Well, it seems that running any GRASS Processing coughs up this error.
> > Mystery to me, permissions are correct for the app, nothing should be
> > writing to the app, and if it is trying that's wrong.
> >
> > The error doesn't help me try to figure out what's going on.  Help would
> be
> > appreciated.
>
>
> I believe it's this bug:
>
> https://issues.qgis.org/issues/17555
>
> The permission errors is caused because it's actually trying to
> execute /Applications/QGIS3.app/Contents/MacOS/grass/etc/colors/grass
> instead of the correct grass binary.
>
> The bug is caused by this function:
>
> https://github.com/qgis/QGIS/blob/master/python/plugins/proc
> essing/algs/grass7/Grass7Utils.py#L130
>
> It's trying to automatically generate the grass executable path, but
> it's incorrectly finding the colors/grass folder and deciding that
> it's the grass executable. I think inserting a os.path.isfile check
> somewhere around line 145 should fix this, but not having access to an
> osx install I haven't been able to test this.
>


I'm not sure what exactly you want to use os.path.isfile() for, but
etc/colors/grass is a file in GRASS GIS since 7.2, so os.path.isfile() will
return True. In unix, you can see if the file is executable with
os.access(name, os.X_OK) (not sure if instead or in addtion to
os.path.isfile()). On Windows, testing for .bat or some other extension
might be the right test.

Best,
Vaclav


>
> Hope that helps -- would be great to have this one sorted for 3.0.1 if
> you can confirm a fix!
>
> Nyall
>
> >
> > On Mar 22, 2018, at 1:10 PM, William Kyngesburye 
> > wrote:
> >
> > What are you doing?  GRASS plugin tools or Processing GRASS algorithms?
> >
> > Nothing should be trying to write to the GRASS dir.  There should not be
> > permissions problem reading from the GRASS dir.
> >
> > On Mar 22, 2018, at 11:00 AM, jehduke...@gmail.com wrote:
> >
> > Thanks William.  I'm still getting some sort of error using grass.  Not
> sure
> > if this is still related.
> >
> > /var/folders/d3/q41sw4cj5_s479lpjf1z3hwcgn/T/processing_
> 7fd31b05f63f437c84dee066f864d9f9/grassdata/temp_location/PERMANENT:
> > /Applications/QGIS3.app/Contents/MacOS/grass/etc/colors/grass:
> Permission
> > denied
> > /var/folders/d3/q41sw4cj5_s479lpjf1z3hwcgn/T/processing_
> 7fd31b05f63f437c84dee066f864d9f9/grassdata/temp_location/PERMANENT:
> > /Applications/QGIS3.app/Contents/MacOS/grass/etc/colors/grass:
> Permission
> > denied
> >
> >
> >
> >
> > On Thu, Mar 22, 2018 at 8:36 AM, William Kyngesburye <
> wokl...@kyngchaos.com>
> > wrote:
> >>
> >> The non-working GRASS in the Mac QGIS 3 should be fixed now.  It appears
> >> the GRASS internals still don't like spaces in the path to GRASS -- this
> >> came from my adding "3" to the QGIS app name with a space.  The app is
> now
> >> without a space, "QGIS3.app".
> >>
> >> It looks like the missing SAGA is also fixed by the rebuild (don't know
> >> why, it just happened).
> >>
> >> REMINDER: My QGIS 3 package requires the python.org Python 3.  Other
> >> distributions/installations of Python are not supported (ie Homebrew,
> >> Macports, Anaconda...).
> >>
> >> -
> >> William Kyngesburye 
> >> http://www.kyngchaos.com/
> >>
> >> [Trillian]  What are you supposed to do WITH a maniacally depressed
> robot?
> >>
> >> [Marvin]  You think you have problems?  What are you supposed to do if
> you
> >> ARE a maniacally depressed robot?  No, don't try and answer, I'm 50,000
> >> times more intelligent than you and even I don't know the answer...
> >>
> >> - HitchHiker's Guide to the Galaxy
> >>
> >>
> >> ___
> >> Qgis-user mailing list
> >> qgis-u...@lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> >
> >
> >
> > -
> > William Kyngesburye 
> > http://www.kyngchaos.com/
> >
> > All generalizations are dangerous, even this one.
> >
> >
> > ___
> > Qgis-user mailing list
> > qgis-u...@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> >
> >
> > -
> > William Kyngesburye 
> > http://www.kyngchaos.com/
> >
> > "We are at war with them. Neither in hatred nor revenge and with no
> > particular pleasure I shall kill every ___ I can until the war is over.
> That
> > is my duty."
> >
> > "Don't you even hate 'em?"
> >
> > "What good would it do if I did? If all the many millions of people of
> the
> > allied nations devoted an entire year exclusively to hating the  it
> > wouldn't kill one ___ nor shorten the 

Re: [QGIS-Developer] [GRASS-dev] Future of external Processing providers in QGIS

[Vaclav Petras]

Thank you, Paolo, for the summary. It was great to be part of the meeting!

On Fri, Feb 23, 2018 at 9:26 AM, Paolo Cavallini 
wrote:

> Hi all,
> meeting has just ended. I must say it was a very interesting and
> productive discussion. We are really grateful for the developers from
> GRASS, SAGA and OTB for their contributions to our discussion.
> I recap briefly here what I believe are the most important outcomes:
> * we'll keep SAGA and GRASS Processing providers
> * we'll try to update SAGA provider to the next LTR when this will be
> available
> * we invite OTB team to add their work to QGIS core, granting them write
> access if they wish
> * for OTB provider, considering that OTB binaries are not part of the
> installer on Windows, we suggest this approach: OTB provider checks
> whether OTB is installed, if not it suggests the user to install it, if
> the user does not the provider hides itself
> * While we have granted an exception to the ‘processing providers should
> not be in core’ for the short term, our longer term plan is to put in
> place mechanisms to ‘side load’ the dependencies (GRASS, OTB, SAGA).
> When this capability is implemented, we will mandate that all providers
> will be provided as plugins and then fetch these plugins on demand if an
> algorithm references them
> * we will not accept new providers, unless some very strict and
> exceptional conditions apply (TBD; e.g. new backend of high quality and
> general usage)
> * for future versions we will consider moving providers to the XML
> approach where appropriate, as it appears more maintainable, even at the
> expense of flexibility in interface tuning; GRASS is the next candidate,
> noting that this might require some modifications in GRASS core
> * as a first step in we ask anybody to test thoroughly the new SAGA
> provider by Alex Bruy
> https://github.com/alexbruy/processing-saga
> also a check from SAGA, GRASS, and OTB devs would be important, to check
> whether this approach is the preferred one from all sides.
> Please add if I missed something.
> Overall, I think we have now a brighter future for Processing, and as a
> consequence for QGIS, SAGA, GRASS and OTB altogether.
> * If you want to watch the complete discussion, please be patient; video
> is being uploaded.
> All the best, and thanks again.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Vaclav Petras]

Dear Nyall and all,

here are some of my thoughts mostly relating to GRASS GIS (although it may
not express views of the whole GRASS GIS developer team).

On Thu, Feb 8, 2018 at 8:55 PM, Nyall Dawson  wrote:
>
> Here's the situation as I see it:
>
> 
> The past
> ---
>
> We (the QGIS project) have struggled to keep a bunch of providers
> stable and available with the base QGIS install, and the current
> maintainers (Alex and Victor, others) have (understandably) struggled
> with the burden of maintaining these alone and the time commitment
> required to do so. Users have been frustrated by breakage which occurs
> when the algorithms they depend on break due to changes in underlying
> libraries for which the processing providers have not been adapted.
>
> Despite this, I'd say overall it's worked OK-ish up to now, but
> definitely with lots of room for improvement.
>
> -
> The goals
> -
>
> I think everyone involved is in agreement that processing's strength
> comes when there's many providers available and it's able to tie
> together processes regardless of which provider or library they come
> from. So I'd say our common goals are:
>
> 1. Encourage development of as many processing providers as possible
> 2. Make it easy for developers to create and maintain these providers
> 3. Make it easy for users to be able to use the providers
> 4. Make everything stable and painfree for users
>
> Any disagreements? No? Good ;)
>
> So if we agree that those are the end goals, we should be using them
> to drive this discussion.
>
> ---
> The questions
> ---
>
> The open, debatable questions are:
>
> - Which is the best approach for allowing easy maintenance of
> providers (*regardless* of whether the provider is maintained by the
> core QGIS team or a 3rd party)? Is it keeping the code in the master
> codebase and locking to QGIS releases, or publishing via plugins and
> having independent release schedules? Which approach will encourage
> more active maintenance of these providers and share the burden of
> this maintenance?

One thing is where to keep the code, however I'm not sure what code are we
talking about and I would like to talk about this first. I think that
recent post by Moritz is bringing this up as well:

https://lists.osgeo.org/pipermail/grass-dev/2018-February/087420.html

As far as I know, QGIS Processing has a text file for each GRASS module
describing its interface and maintenance of these takes time. However,
every GRASS module can tell about itself when called with
--interface-description parameter. If this is used, individual parameters
don't need to be maintained and any, even user provided module can be
executed in processing.

The --interface-description parameter gives XML which would need to be
converted or a new parameter, let's say --qgis-description, would need to
be added for a QGIS-specific format, there is for example --script for
GRASS GIS interface description for scripts. --qgis-description would need
to be in GRASS GIS code base while the conversion can be anywhere. See
emails from Rashad discussing a possible implementation with the
--qgis-description way and the OTB way:

https://lists.osgeo.org/pipermail/grass-dev/2018-February/087362.html
https://lists.osgeo.org/pipermail/grass-dev/2018-February/087390.html

The was discussed in the past and in fact, it is used in the QGIS GRASS
plugin as Radim explains in this older email:

https://lists.osgeo.org/pipermail/grass-dev/2015-March/074629.html

However, it is not using the --interface-description XML only, but it is
also using the qgm files to supply some additional information which means
that this system still requires updates which are separate from the updates
of GRASS modules. This can be avoided if the necessary information is
updated upstream or sometimes even GRASS --interface-description format or
the individual module descriptions are extended to include that what is
needed by QGIS Processing. Here is a thread which disuses this issues
although diverges into the following:

https://lists.osgeo.org/pipermail/grass-dev/2015-September/076138.html

One issue which is creating differences between QGIS Processing
representation of the module and the GRASS one is the issue of advanced
parameters. GRASS itself has mechanism to organize the parameters into
groups and marks the required ones. This is of course something which is
constantly being refined and it can be used and changed also for QGIS
Processing as discussed in this 2015 post:

https://lists.osgeo.org/pipermail/grass-dev/2015-December/078000.html

Other issues besides the interface include list of GRASS modules usable and
unusable in QGIS Processing, thematic tree of these modules, splitting
modules and more. Many of these are discussed in this recent post:

https://lists.osgeo.org/pipermail/grass-dev/2018-February/087388.html

One of the issues is issue of formats 

Re: [Qgis-developer] grass module don't appear

[Vaclav Petras]

Please, keep the discussion on mailing list(s).

On Wed, Dec 9, 2015 at 9:14 AM, Giovanni Manghi 
wrote:
> >
> > I was wrong, here is the necessary update for r.mapcalc:
> >
> > https://trac.osgeo.org/grass/changeset/67000
>
>
> I may have misunderstand the meaning of this new flag in the first
> place. In fact now I'm looking at it on GRASS svn I can't see on how
> it can help to get r.mapcalc in QGIS/Processing.

As far as I remember, the issue was that Processing didn't know the names
of the rasters user want to use in the calculation. r.mapcalculator was
working around this issue by separating the expression and raster names. -l
flag now tells the names to the caller without actually performing the
operation. There will be some special code needed in Processing (which
makes sense as r.mapcalc is special).

> The problem is that when using GRASS/Processing the layers are
> imported in a temporary location/mapset, and given temporary
> filenames, that are used as map names for input parameters.

I don't really follow you here but it seems to me that the issue might be
that -l still requires the rasters to exist. If this is the case please,
continue the discussion in GRASS ticket #2592.

https://trac.osgeo.org/grass/ticket/2592

> One question, why r.mapcalculator is not available in GRASS 7? I

I guess that simply nobody contributed a Python version of it. Bash scripts
are not guaranteed to work with G7 on MS Win, so the old script cannot be
used.

> haven't fiund any note about its removal in the changelog.

My impression is that it was never officially added in the first place, so
maybe that's the reason. Discussing this on the grass-dev mailing list or
in a ticket might be a good idea.

Best,
Vaclav
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] grass module don't appear

[Vaclav Petras]

On Thu, Nov 26, 2015 at 10:09 AM, Vaclav Petras <wenzesl...@gmail.com>
wrote:

> On Thu, Nov 26, 2015 at 4:33 AM, Eugenio Trumpy <frippe12...@hotmail.com>
> wrote:
>
>> We hope r.mapcalc will be added in the toolbox, soon.
>
>
>
> As far as I know, nobody is working on that now. But it is certainly a
> topic open for contributions.
>

I was wrong, here is the necessary update for r.mapcalc:

https://trac.osgeo.org/grass/changeset/67000
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] grass module don't appear

[Vaclav Petras]

On Thu, Nov 26, 2015 at 3:40 AM, Radim Blazek 
wrote:

> Just a note, r.mapcalc including visual editor is present in the GRASS
> Plugin
> http://www.gissula.eu/qgis-grass-plugin-crowdfunding/images/r.mapcalc.png
>

This looks pretty cool, Radim. It might be really helpful to some people.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] grass module don't appear

[Vaclav Petras]

On Thu, Nov 26, 2015 at 4:33 AM, Eugenio Trumpy 
wrote:

> We hope r.mapcalc will be added in the toolbox, soon.



As far as I know, nobody is working on that now. But it is certainly a
topic open for contributions.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] grass module don't appear

[Vaclav Petras]

On Wed, Nov 25, 2015 at 3:35 PM, Giovanni Manghi 
wrote:

> > Then I searched for r.mapcalculator, which was present in the old
> processing toolbox. I didn't find it
> > in the grass7 processing modules list. Although the grass7 stand alone
> has r.mapcalc (not r.mapcalculator),
> > in the grass7 processing toolbox neither r.mapcalculator nor r.mapcalc
> are present.
> >
> > I wonder if is it possible to add grass7 module thus I can insert
> r.null, then I would like to know if
> > I can put in r.mapcalculator or r.mapcalc at least.
> >
>
> In Processing GRASS r.mapcalc can't be added, unless doing some work,


Yes, please see and contribute to:

https://trac.osgeo.org/grass/ticket/2592

see
>
> http://hub.qgis.org/issues/6894
>
> on the other hand in GRASS 7 r.mapcalculator is not available, so it
> is not also in Processing.
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] New GRASS plugin: a test drive

[Vaclav Petras]

On Mon, Oct 5, 2015 at 1:16 PM, Radim Blazek  wrote:

> >> There is v.build.all in modules.
> >
> > yes, but the user has no hint about its necessity; further steps:
> > db.connect -d
> > v.db.reconnect.all -cd
> > are not available among modules (BTW, maybe these options could be added
> > to existing modules?).
>
> Building broken topology from browser can be always useful, but I
> don't think that browser/plugin must have UI for upgrading GRASS data
> from 6 to 7, something which has to be rarely done and which should be
> done with understanding (upgrade from dbf to sqlite).


Perhaps a special plugin. Do you think it would be a good idea to have
plugins based on the GRASS plugin? (They would probably just call modules
but in the way GRASS plugin does.)
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Problem with GRASS 7 and Processing

[Vaclav Petras]

On Thu, Oct 1, 2015 at 3:59 AM, Victor Olaya  wrote:

> Not sure what's the rationale for that line, since I am no GRASS
> expert,


There is no need to have GISBASE variable set (path to directory where
GRASS binaries live) when GRASS GIS is started explicitly as a 'grass'
command later on. If you have GISBASE, grass command will end with error as
GISBASE says that you are already in GRASS session.

Why GISBASE is set, or if deleting it is just a precaution, I have no idea.

Best,
Vaclav

but this commit should fix it
>
>
> https://github.com/qgis/QGIS/commit/87d8a12e79a4c889d72245fb2b3ba22100aab59f
>
> Please, try and confirm that it fixes the issue
>
> Regards
>
> 2015-10-01 9:36 GMT+02:00 matteo :
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > HI all,
> > QGIS fresh compiled and Grass7 installed (works as standalone).
> > I'm not able to run any of GRASS7 algorithm with Processing, this is
> > the error:
> >
> > 2015-10-01T09:34:21 2   Could not load model model_PCA.model
> > Error in algorithm name: r:acpcercle
> > 2015-10-01T09:34:30 2   Uncaught error while executing algorithm
> > Traceback (most recent call last):
> > Traceback (most recent call last):|  File
> > "/home/ma7730/.qgis2/python/plugins/processing/core/GeoAlgorithm.py",
> > line 227, in execute|self.processAlgorithm(progress)|  File
> > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Algorit
> > hm.py",
> > line 425, in processAlgorithm|Grass7Utils.executeGrass7(commands,
> > progress, outputCommands)|  File
> > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Utils.p
> > y",
> > line 270, in executeGrass7|command, grassenv =
> > Grass7Utils.prepareGrass7Execution(commands)|  File
> > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Utils.p
> > y",
> > line 252, in prepareGrass7Execution|del env['GISBASE']|KeyError:
> > 'GISBASE'|
> > 2015-10-01T09:34:30 1   There were errors executing the
> algorithm.
> >
> >
> > Any idea?
> >
> > Thanks!
> >
> > Matteo
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQEcBAEBCAAGBQJWDOKYAAoJEBy7UYf0gaEO9NcH/imnsNoRR9cgRIysh5tu5QWX
> > HiOQIbAJcDjehJRr3+yDYLs7dMYPbaRkI4LlptuPsr+oB3p67KQkcXaFV2CKyNP5
> > x6QhKSHjrY7QTRXOnvGXgHfjeliQuLiB9G62j1JclbLy/o2XIZ9Rmq8D8yq9jB3W
> > j6WwS22+78GKQUpDiK3dUfCEpQCTL3UoqpcxRPs39vwq2+WGO3D7NpW/tL623jNr
> > G5oLNL6f6zl9L5R1zzXRjlS6cW9O+JhuwDiIot6q53nD9qyyCACz6GackdTLmbDB
> > emRJNeU7Xor1ej1YzxMKH78jryZ9XHyWH4lpKQq6sOI7Nnanzy+YwSUSxyGsQro=
> > =loCw
> > -END PGP SIGNATURE-
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] What's your view on QGIS plugins that connect to non-GPL software?

[Vaclav Petras]

On Thu, Sep 10, 2015 at 11:39 AM, Crispin Cooper 
wrote:

> The QGIS plugin would not be essential to the external process as sDNA
> works on its own anyway.  The external process would however be essential
> to the QGIS plugin.
>

Just thinking aloud here: If the plugin would support analysis with sDNA
and let's say GRASS GIS network analysis tools then sDNA would be just one
of the options, thus not essential, so thing might be ok. But you should
consider the full GPL way. There are reasons why people are using it :)
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] G_OPT_V_TYPE cannot be recognized in --interface-description in GRASS GIS

[Vaclav Petras]

On Tue, Sep 1, 2015 at 5:14 AM, Radim Blazek <radim.bla...@gmail.com> wrote:
>
> On Tue, Aug 25, 2015 at 3:31 AM, Vaclav Petras <wenzesl...@gmail.com>
wrote:
> > Was: [Qgis-developer] QGIS GRASS plugin - modules upgrade
> >> >> 2) define relations between options (e.g. type or column option
> >> >> relation with input vector) or special options which has dedicated
> >> >> widget in UI (e.g. GDAL/OGR input).
> >> >
> >> > This should be defined in GRASS GIS. If it is missing in GRASS or in
the
> >> > --interface-description then it is a bug which should be solved.
> >>
> >> How can I recognize G_OPT_V_TYPE in  --interface-description? It does
> >> not have gisprompt.
> >
> >
> > Right [1]. I think this is a bug. No gisprompt is there. I think wxGUI
> > doesn't need it because the values for the combo box are defined there
> > already.
>
> How does the wxGUI know that the option should be placed in Selection tab?

It is defined using guisection:

https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.distance/main.c#L97

In the XML it looks like:



Layer number or name (from)

...

From



It is not defined what should happen with the ones which do not have
guisection, i.e. it is up to you to decide and it doesn't make sense for
GRASS GIS to enforce one representation or the other. The old behavior in
wxGUI was that all required options/parameters were in the Required tab and
all with non defined guisection were in Optional tab together with all
flags without guisection specified. The current (and better) behavior is
that wxGUI respects the guisection specified for required
options/parameters and (if it is actually specified) includes a red star to
a field description. In this case, it is up to the module to have it
defined nicely which means that module should specify guisection for every
required parameter if it is defining it for at least one (i.e. define all
or nothing). The Optional tab still behaves the same and contains all
not-required options/parameters without guisection. So now Required and
Optional behave the same -- as fallbacks.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS GRASS plugin - modules upgrade

[Vaclav Petras]

On Tue, Aug 18, 2015 at 8:09 AM, Radim Blazek radim.bla...@gmail.com
wrote:

 On Tue, Aug 18, 2015 at 9:14 AM, Martin Landa landa.mar...@gmail.com
wrote:
  Hi,
 
  2015-08-18 9:11 GMT+02:00 Radim Blazek radim.bla...@gmail.com:
  BTW, as Markus Neteler pointed out, there is a list differences
  between GRASS 6 and 7:
 
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Replacedandremovedmodules
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Renamedmodules
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Optionschanges
  and a table used by the commands to advertise new parameters in case
  the user used the old style:
 
https://svn.osgeo.org/grass/grass/branches/releasebranch_7_0/lib/gis/renamed_options
 
  If you upgrade a module definition in QGIS, please update also its
status on
  https://grasswiki.osgeo.org/wiki/GRASS-QGIS_relevant_module_list
 
  I wonder why UI is not generated on the fly or during compilation? To
  maintain manually UI in QGIS is complicated and the result will be
  always out-of-date. Just 2 my cents, Martin

 UI is generated on the fly when a module UI is opened. It is using
 options description printed by GRASS module (--interface-description)
 combined with options definition for the module in QGIS (.qgm file).
 The additional options definition in QGIS is mainly for two purposes:

 1) limit number of options not to frighten users, some GRASS modules
 are also represented as multiple items with predefined options

Hi Radim and Martin,

I guess that one of the reasons for QGIS interface for GRASS. Anyway, is
there a option of not using .qgm file and using --interface-description
only? This would not only enable some of the hidden features but more
importantly, it would enable to use of modules from GRASS GIS Addons
repository.

 2) define relations between options (e.g. type or column option
 relation with input vector) or special options which has dedicated
 widget in UI (e.g. GDAL/OGR input).

This should be defined in GRASS GIS. If it is missing in GRASS or in the
--interface-description then it is a bug which should be solved.

Here are examples of guidependency option attribute:

https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.distance/main.c#L222
https://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.what.vect/v.what.vect.py#L15

 It was surely difficult to keep options in sync with GRASS modules,
 but with the new debugging tool (in master), it is possible to check
 all options/modules with just one click.

This sounds really good.

Best,
Vaclav
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [GRASS-dev] Debugging QGIS with GRASS provider on Windows

[Vaclav Petras]

On Tue, Jun 16, 2015 at 2:01 PM, Radim Blazek radim.bla...@gmail.com
wrote:

 Hi,
 I need to debug QGIS GRASS provider on Windows. I have successfully
 compiled GRASS 7 using MinGW [1] and QGIS using MSVC [2]. The problem
 is that MSVC does not support GCC debugging symbols and vice versa. Do
 you have any idea how to debug both QGIS and GRASS code at the same
 time, preferably in MSVC or Qt Creator?

 Is there any recent effort to compile GRASS with MSVC? I have only
 found quite an old mail about MSVC port [3].


There is an exploratory effort to use CMake for GRASS GIS [1] but there is
a lack of CMake experts with free time. In theory this is one of the steps
to compile GRASS with MSVC. Isn't it possible to easily compile QGIS with
MinGW thanks to CMake (since GCC is used on other platforms)?

Vaclav

[1] https://github.com/starseeker/grass



 Radim

 [1] https://trac.osgeo.org/grass/wiki/CompileOnWindows
 [2]
 https://htmlpreview.github.io/?https://github.com/qgis/QGIS/blob/master/doc/INSTALL.html#toc12
 [3] http://lists.osgeo.org/pipermail/grass-dev/2007-November/034108.html
 ___
 grass-dev mailing list
 grass-...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin to synchronize an attribute table between QGIS and LibreOffice?

[Vaclav Petras]

On Sat, Apr 25, 2015 at 11:49 AM, Stefan Keller sfkel...@gmail.com wrote:

 What about a plugin to open and synchronize an attribute table between
 QGIS and LibreOffice?

There was a talk at FOSS4G PDX 2014 which described combination of
PostGIS/PostgreSQL+QGIS+LibreOffice:

Geodesign: An Introduction to Design with Geography — Matthew Baker, Denver
Public Schools, Critter Thompson, Placematters
https://vimeo.com/106233274
5:00-15:00

 This would also require to write a LibreOffice extension.
 As an inspiration see this ArcGIS extension called gisconnector [1]

 --S.

 [1]
http://www.gislounge.com/gisconnector-excel-synchronize-data-selections-filters-arcgis-excel/
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Vaclav Petras]

On Tue, Mar 24, 2015 at 5:56 AM, Radim Blazek radim.bla...@gmail.com
wrote:

  Are there functions in time series implementation which need to be
  called directly from the plugin or everything may be done just calling
  t.rast.* modules?
 
  Most of the temporal functionality is available through the temporal
  modules. However some important algorithms (temporal re-sampling) are
  available only in the Python framework. This is needed for time series
  animation creation. Using the framework directly will speed things up,
  because the module calls, the parsing and interpretation of the module
  outputs can be avoided.

 If it should be used for dynamic animation in QGIS canvas you could
 consider the possibility to subclass raster renderer in Python and
 insert it into raster layer pipe from Python plugin.


Speaking about animations, some things from GRASS GIS GUI could be perhaps
used directly in the same was as Tcl/Tk NVIZ is used in processing for
GRASS 6. Animation tool is one of them. This would be great since we would
get al least some functionality/code sharing between GRASS and QGIS GUIs
which is otherwise not possible due to Python/wxPython and C++/Qt (and
would be only possible if both things would be at least in the same
language).

This is of course not fulfilling the requirement to be general, i.e. work
with other data providers in QGIS, but surely some things just have to be
like that if they are using GRASS-specific formats (temporal data) or
algorithms (e.g. algorithms to work with temporal data, their topology,
...).

Vaclav
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Vaclav Petras]

On Tue, Mar 24, 2015 at 2:00 AM, Pietro peter.z...@gmail.com wrote:

 Hi Radim,

 together with Francesco Geri, last week we started to write a first
 draft that generate the GUI for the GRASS module dynamically (based on
 the xml generated with: --interface-description), so far it is based
 on grass7 but should work also on grass6 (not tested, should be enough
 to backport the pygrass.modules.Module class).

 Hi Pietro and Francesco,

this sounds good. Are you speaking about QGIS GUI (in Python) generated
from --interface-description? Do you think it would be possible to write it
in a way which would be GUI framework independent so that it is usable in
both GRASS and QGIS? The GUIs for modules in GRASS are quite good now but
the code should be rewritten and this would be a great way how to get this
new implementation.

Vaclav


 Best regards

 Pietro

 On Mon, Mar 23, 2015 at 7:56 PM, Radim Blazek radim.bla...@gmail.com
 wrote:
  Hi all,
 
  I have finally launched the crowdfunding campaign to support the GRASS
  plugin upgrade. Briefly, it covers upgrade to GRASS 7, browser
  integration, drag-and-drop import and new vector editing. All the
  details are available here:
 
  http://www.gissula.eu/qgis-grass-plugin-crowdfunding/
 
  Please propagate this info to all relevant channels, national mailing
 lists etc.
 
  Radim
  ___
  grass-dev mailing list
  grass-...@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-dev
 ___
 grass-dev mailing list
 grass-...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Vaclav Petras]

On Tue, Mar 24, 2015 at 1:30 PM, Pietro peter.z...@gmail.com wrote:

 Hi Vaclav,

 On Tue, Mar 24, 2015 at 3:54 PM, Vaclav Petras wenzesl...@gmail.com
 wrote:
  On Tue, Mar 24, 2015 at 2:00 AM, Pietro peter.z...@gmail.com wrote:
  together with Francesco Geri, last week we started to write a first
  draft that generate the GUI for the GRASS module dynamically (based on
  the xml generated with: --interface-description), so far it is based
  on grass7 but should work also on grass6 (not tested, should be enough
  to backport the pygrass.modules.Module class).
 
  Hi Pietro and Francesco,
 
  this sounds good. Are you speaking about QGIS GUI (in Python) generated
 from
  --interface-description? Do you think it would be possible to write it
 in a
  way which would be GUI framework independent so that it is usable in both
  GRASS and QGIS? The GUIs for modules in GRASS are quite good now but the
  code should be rewritten and this would be a great way how to get this
 new
  implementation.

 yes, actually what I wrote it is completely independent from QGIS, it
 is compatible with pyqt/pyside and with python2/python3,
 It is just a proof of concept. Now Francesco it is working to better
 integrate this draft with QGIS stuff.

 That's good to hear.


 The idea was heavily based on formlayout code:

 https://code.google.com/p/formlayout/

 Basically each parameter is a GUI field that it is add to the main
 window, therefore based on the parameter type the field could be:

 if raster/vector = a combo box with the rasters/vectors available
 if integer = a spinbox
 if string/double = a text field
 if file = a file dialog

 based on the guisection parameter all the options are organized in tabs.


Both QGIS and GRASS are adding different extra features like setting region
according to a selected raster or dependent fields for vector GRASS layers
and attributes. That's why it gets complicated at the end. And of course
then there is the extra information which is not stored in XML such as
GRASS standard options.

Anyway, skipping qgm is quite important feature for QGIS since it is
necessary for GRASS addons as you say.


 The code is under 500 lines of code.

 I guess should be possible to follow the same approach using the wxpython.
 I think that with a bit more effort should be possible to make it
 general enough to make it independent from the GUI framework (Qt/Wx)
 that we want to use.

 I have not link to share at this stage because we are still working on it.
 But I guess we can share the code as soon as we have something that it
 is able to cover the basic needs.

 I'm looking forward to that.


 Pietro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS and GRASS 7.0.0

[Vaclav Petras]

On Wed, Feb 25, 2015 at 2:45 AM, Radim Blazek radim.bla...@gmail.com
wrote:

  it would be good if you can include GRASS Addons, too. There is a lot of
  requests for installing/running GRASS Addons from QGIS, e.g. at
  gis.stackexchange.com.

 How can I get list of installed GRASS Addons?


For basic list you can just use `g.extension -a` [1]. wxGUI is using more
complex approach implemented in UpdateGRASSAddOnCommands function [2]. One
reason for higher complexity is handling calls of Python scripts on MS
Windows (which would use some code review).

[1]
https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/toolboxes.py?rev=64678#L475
[2]
https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/globalvar.py?rev=64678#L136
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Fwd: Re: Re: QGIS and GRASS 7.0.0

[Vaclav Petras]

On Tue, Feb 24, 2015 at 6:19 AM, Paolo Cavallini cavall...@faunalia.it
wrote:

    Messaggio Inoltrato 
  Oggetto: Re: [Qgis-developer] QGIS and GRASS 7.0.0
  Data: Tue, 24 Feb 2015 08:08:18 +0100
  Mittente: Paolo Cavallini cavall...@faunalia.it
  Organizzazione: Faunalia
  A: Pedro Venâncio pedrongvenan...@gmail.com
  CC: qgis-developer qgis-developer@lists.osgeo.org
 
  Olá Pedro,
 
  Il 23/02/2015 22:06, Pedro Venâncio ha scritto:
 
  Despite the great advantages of GRASS commands in Processing, I think
  that the GRASS plugin still plays an important role and is an excellent
  interface for GRASS. For those who still like to use the paradigm of
  locations, mapsets and the GRASS topological model, GRASS plugin is very
  important, because then it allows to use all QGIS tools, for example, to
  create layouts using the Composer, etc.
 
  Agreed. Moreover, the overhead of importing/exporting data for each step
  of a complex analysis puts GRASS algs to a disadvantage for Processing
  users.

 The overhead is not necessarily needed in case of raster maps:

  Workflow example:
 # register GeoTIFF file in GRASS GIS database (no import but direct link):
 r.external input=tempmap1.tif output=modis_celsius

 # define output directory for files resulting from GRASS calculation:
 # i.e. GRASS GIS writes directly a GeoTIFF file here, no GRASS DB storage
 r.external.out directory=$HOME/gisoutput/ format=GTiff

 # perform calculation (here: extract pixels  20 deg C) and
 # write output directly as GeoTIFF:
 r.mapcalc warm.tif = if(modis_celsius  20.0, modis_celsius, null() )

 # cease GDAL output connection and turn back to write GRASS raster files:
 r.external.out -r

 # use the result elsewhere
 qgis $HOME/gisoutput/warm.tif
  END Workflow example:

 This approach could be used in Processing as well. Or in a WPS context
 etc.


Hi,

see also GRASS GIS (+QGIS?) GSoC 2015 idea for further discussion on that
topic:

http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS

From the QGIS Processing source code, I actually got an impression that
this approach is already used for rasters.

Vaclav
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS and GRASS 7.0.0

[Vaclav Petras]

On Tue, Feb 24, 2015 at 3:28 AM, Radim Blazek radim.bla...@gmail.com
wrote:

 - modules GUI - my idea is to throw away the qgm and qgc definitions
 and auto generate GUI for modules with all options based on
 --interface-description only, also the list of modules would be auto
 generated for all modules.


Hi Radim,

it would be good if you can include GRASS Addons, too. There is a lot of
requests for installing/running GRASS Addons from QGIS, e.g. at
gis.stackexchange.com.

Also, there are some files in GRASS GIS which might be quite useful [1].
toolboxes.xml [2] contains GRASS GIS modules sorted into different
tooboxes. They are currently not part of the official API but it is just a
matter of declaring them as part of API I guess [3]. GRASS wxGUI is using
these files to create a menu and module tree in Search module tab. It is
also a way to customize wxGUI [4] but that's not related to QGIS use case.

Loading Addons dynamically to menu or module tree including their
descriptions seems to be a bit challenging but if nothing else wxGUI can
always run a module installed using g.extension (or custom user script) if
it can run and give --interface-description.

Best,
Vaclav

[1] http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/xml
[2]
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/xml/toolboxes.xml
[3]
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/docs/wxgui_sphinx/src/wxgui_toolboxes.rst
[4] http://grass.osgeo.org/grass70/manuals/wxGUI.toolboxes.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [GRASS-dev] GRASS QGIS: the future

[Vaclav Petras]

   G_fatal_error() is too low level not only for messages but in general,
 for
  Python libraries wrapping GRASS library, it does not allow to throw an
  exception in case of an error. And the same applies for C++ wrappers.

 If you want to turn fatal errors into exceptions, the correct way to
 do it is to use setjmp/longjmp (and contribute patches to make any
 intervening code exception-safe).


As I wrote before, I hope that RPC approach suggested here by Soeren will
work for languages with exceptions and for persistent applications while
GRASS modules will benefit from the advantages of GRASS library with
G_fatal_error() with exit().

Vaclav
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] r.series in Processing

[Vaclav Petras]

On Fri, Apr 18, 2014 at 3:32 AM, Paolo Cavallini cavall...@faunalia.itwrote:

 Il 18/04/2014 05:48, Vaclav Petras ha scritto:

  I was using r.series directly in GRASS recently (both 6 and 7) and it
  worked as expected. But perhaps you have some specific data.

 Thanks Vaclav. I do not see anything special in my data (tried different
 sets).
 May I ask you a favour? Could you please try your data through
 Processing, and report here?
 I wish to debug this.
 Thanks for your help.

 I would like to but I don't have Processing working. I have qgis from
qgis.org/ubuntugis-nigthly and I installed grass package but Processing
report messing dependency. When I start grass from command line, it is in
`/tmp/processing/grassdata` location. I'm not sure if I ever actually used
Processing, so I can miss something essential. Do you have some pointers?

By the way, the error dialog main message is:

  Missing dependency.This algorithm cannot be run :-(

where a space after comma is missing. Also the dialog has a link to QGIS
doc for more details, but it is a general link to main page, it does not
tell much, I expected some configuration section.

You can try in directly in GRASS. I wanted to try with data available here
(NagsHead time series):

http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_grgeomorph2.html
http://courses.ncsu.edu/mea582/common/media/01/NagsHead_series.zip

Also, the version of GRASS installed from packages is 6.4.1 which is quite
old, so I tried that one and the result looks OK.

Vaclav

 --
 Paolo Cavallini - www.faunalia.eu
 QGIS  PostGIS courses: http://www.faunalia.eu/training.html

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [GRASS-dev] GRASS QGIS: the future

[Vaclav Petras]

On Fri, Apr 18, 2014 at 6:59 PM, Glynn Clements gl...@gclements.plus.comwrote:

 The key feature of G_fatal_error() isn't printing error messages. The
 key feature is that it doesn't return.


This is one of the problems of G_fatal_error(), it does not gives good
error messages to the user. User gets G_malloc: unable to allocate %lu
bytes of memory at %s:%d but does not have any idea when and why this
happened and what to do about it. If the module calling G_malloc() had the
chance to report error by itself, it could suggest to user to change some
parameter or use a smaller map. With G_fatal_error() user has only the
possibility to try to guess from debug messages, ask on mailing list or
keep trying with random changes in input parameters. I don't believe that
this is efficient.

G_fatal_error() is too low level not only for messages but in general, for
Python libraries wrapping GRASS library, it does not allow to throw an
exception in case of an error. And the same applies for C++ wrappers.

As far as I understand, the RPC wrapper suggested earlier by Soeren, would
hopefully allow to have exceptions (and no exit()) in Python and C++ and
thus potentially higher level error messages and also general error
handling would be possible (for those not using the original library).
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [GRASS-dev] GRASS QGIS: the future

[Vaclav Petras]

On Fri, Apr 18, 2014 at 6:43 PM, Glynn Clements gl...@gclements.plus.comwrote:

  Unfortunately GRASS 7 moved ahead towards its aim to make life harder
  for anyone trying to use the GRASS libraries [1].

 That isn't actually the reason why various functions have had status
 returns changed to fatal errors. The reason is to avoid pushing the
 burden of error handling onto their callers.


The fact is that no library should use exit() or similar things if it wants
to be general. GRASS library is intended to be used only for building GRASS
modules, thus it is specialized for them, thus it uses G_fatal_error() with
exit(). (At least there is a believe that exit makes it easier.)

As a result using GRASS functions outside the scope of GRASS modules
requires another library. It would be nice to have two libraries, one for
GRASS modules (with exit()) and one for everybody else. Hopefully, it would
be possible to share the same code to some extent. Alternative is to use
the RPC wrapper as suggested earlier by Soeren, as far as I understand this
has the same result. The questions are what is less work, less duplication,
what has easier maintenance and what is easier to do for all the platforms.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] r.series in Processing

[Vaclav Petras]

On Thu, Apr 17, 2014 at 6:49 AM, Paolo Cavallini cavall...@faunalia.itwrote:

 Is anyone getting reasonable results? Could it be an upstream issue?


I was using r.series directly in GRASS recently (both 6 and 7) and it
worked as expected. But perhaps you have some specific data.

Vaclav
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] cmake variable WITH_GRASS broken?

[Vaclav Petras]

On 8 October 2012 09:07, Martin Dobias wonder...@gmail.com wrote:
 Hi Vaclav

 On Sat, Oct 6, 2012 at 5:20 PM, Vaclav Petras wenzesl...@gmail.com wrote:
 Hi,

 I'm compiling QGIS without GRASS. So I set cmake variable WITH_GRASS
 to OFF. But qgis grass code is still running.

 [...]

 This is after make and running QGIS from build/output/bin.

 I'm compiling QGIS with latest GDAL so I cannot link to my GRASS
 system installation and I don't want to compile GRASS now.

 I had similar problem on some other computer with WITH_GRASS set to
 OFF. The compilation was broken because it was still linking to grass.
 But in this case I thought that it is my problem with some configure
 and clean combinations.

 Most likely you have leftover provider and plugin .so files in
 build/output/lib/qgis


Thanks, meanwhile I tried two things. First, I renamed
/usr/lib/grass64 to something else and then run configure. It helped.
Second, I created completely fresh build directory and run
configuration (with not renamed /usr/lib/grass64). It worked too. My
impression is that problem was in CMakeCache.txt. So simple removing
of CMakeCache.txt could probably help too.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] cmake variable WITH_GRASS broken?

[Vaclav Petras]

Hi,

I'm compiling QGIS without GRASS. So I set cmake variable WITH_GRASS
to OFF. But qgis grass code is still running.

When I start QGIS I get this output:
...
Debug: src/providers/grass/qgsgrass.cpp: 128: (init) GRASS gisBase
from GISBASE env var is:
Debug: src/providers/grass/qgsgrass.cpp: 289: (isValidGrassBaseDir)
isValidGrassBaseDir()
Debug: src/providers/grass/qgsgrass.cpp: 133: (init) GRASS gisBase
from QSettings is:
Debug: src/providers/grass/qgsgrass.cpp: 289: (isValidGrassBaseDir)
isValidGrassBaseDir()
Debug: src/providers/grass/qgsgrass.cpp: 148: (init) GRASS gisBase
from configure is: /usr/lib64/grass64
Debug: src/providers/grass/qgsgrass.cpp: 289: (isValidGrassBaseDir)
isValidGrassBaseDir()
Debug: src/providers/grass/qgsgrass.cpp: 199: (init) Valid GRASS
gisBase is: /usr/lib64/grass64
Debug: src/providers/grass/qgsgrass.cpp: 230: (init) set PATH:
/usr/lib64/grass64/bin:/usr/lib64/grass64/scripts:MY_QGIS_SRC_PATH/grass/scripts/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Debug: src/providers/grass/qgsgrass.cpp: 237: (init) set PYTHONPATH:
/usr/lib64/grass64/etc/python:
Segmentation fault

This is after make and running QGIS from build/output/bin.

I'm compiling QGIS with latest GDAL so I cannot link to my GRASS
system installation and I don't want to compile GRASS now.

I had similar problem on some other computer with WITH_GRASS set to
OFF. The compilation was broken because it was still linking to grass.
But in this case I thought that it is my problem with some configure
and clean combinations.

Vaclav
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer