Re: [QGIS-Developer] Running grass algorithms in threads
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
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
On Thu, Mar 22, 2018 at 6:56 PM, Nyall Dawsonwrote: > 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
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 Cavalliniwrote: > 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
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 Dawsonwrote: > > 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
Please, keep the discussion on mailing list(s). On Wed, Dec 9, 2015 at 9:14 AM, Giovanni Manghiwrote: > > > > 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
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
On Thu, Nov 26, 2015 at 3:40 AM, Radim Blazekwrote: > 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
On Thu, Nov 26, 2015 at 4:33 AM, Eugenio Trumpywrote: > 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
On Wed, Nov 25, 2015 at 3:35 PM, Giovanni Manghiwrote: > > 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
On Mon, Oct 5, 2015 at 1:16 PM, Radim Blazekwrote: > >> 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
On Thu, Oct 1, 2015 at 3:59 AM, Victor Olayawrote: > 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?
On Thu, Sep 10, 2015 at 11:39 AM, Crispin Cooperwrote: > 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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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