Re: [GRASS-dev] RFC: variations of statistics in r.neighbors (and the stats lib)
On Tue, Jan 31, 2023 at 07:47:49PM +0100, Markus Metz wrote: Hi Francesco, Hi Markus, the proposed change to r.neighbors is interesting, but maybe too specific: you have introduced two new functions, and many more functions would be needed to e.g. get the filtered standard deviation or median. Indeed, that was the reason of my doubt on that approach. The changes introduced were simple enough and workerd properly for my specific case, but it is neither elegant nor general at all. Therefore I suggest adding some filtering option to r.neighbors consisting of a filtering function and a comparison operator. The filtering function would be any of the currently supported neighborhood functions returning some value. The comparison operator would be one of gt, ge, le, lt (>, >=, <=, <). r.neighbors would then first get the result value of the filtering function, then set all values in the neighborhood to NULL that do not fulfil the condition "value , then call the actual neighborhood operation with the filtered values. This would be more flexible, because the user can freely combine a neighborhood filter function with a neighborhood operation. This seems reasonable to me. The same approach could be used for at least a pair of different population selection filter, i.e. by-quantile and by-quartile. filter ::= by-quantile | by-quartile filter-cmp-op ::= ge | le | gt | lt | range with target value taken from quantile or quartile arguments. Eventually, one could use a range too and specify a pair of new cmd line arguments: quantile_low | quantile_high quartile_low | quartile_high or change quantile and quartile into a list of 1..2 comma separated values. Much better, isn't it? On Wed, Jan 25, 2023 at 10:55 AM Francesco P. Lovergine wrote: Hi, for some specific needs of a research project, I had to make a little change to r.neighbors (the target version was 7.8.5 but that's not essential). Essentially, the idea behind is computing first order statistics on partial populations as identified by selected quantiles (samples >= or <= of a threshold value of quantile). For that, I introduced average_ge_quantile and average_le_quantile operators modes. https://github.com/fpl/grass/commit/6b83795b037c6645a32d6a525cfdee3cc65d521c (the html file is still not updated) I'm not persuaded this is the most elegant way of doing this kind of things, maybe it would be better using an option (as in the case of -w for weighted operations) to compute average and possibly other statistics. Even, one could think in general to other multiple ways of selecting population on the base of quantiles/percentiles of population in a window. Any hint/opinion/alternative/critic about that? All this in the remote hypothesis that a pull request could have sense for such a kind of features. Thanks -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Future of external Processing providers in QGIS
Il 27/02/2018 19:59, Markus Neteler ha scritto: > Hi Paolo, > > (reducing to grass-dev) > > thanks for your detailed summary! I have just added a related agenda item to > https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Bonn_2018#Agenda_-_What_we_plan_to_do Glad you appreciated it - I think it was an excellent example of how things can go, democratically, in GFOSS community. Looking forward for further progress on this. Of course I'm available for help. All the best. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Future of external Processing providers in QGIS
Hi all, video link here: https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira2018#future-of-processing-providers All the best. === * If you want to watch the complete discussion, please be patient; video is being uploaded. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Future of external Processing providers in QGIS
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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Zoom meeting
Please see https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira2018 for connection details. Thanks. === Now on a meeting about the future of QGIS providers. Anyone wants to join? Thanks. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Zoom meeting
Now on a meeting about the future of QGIS providers. Anyone wants to join? Thanks. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [saga-gis-developer] [QGIS-Developer] External providers in QGIS
e about Mac. However, on Linux, the decision is > up to the packagers, so in any case, the QGIS part needs to be able to > work with different versions. Regardless of QGIS packaging efforts, I > have seen many users with old GRASS who installed new standalone GRASS > on the side, even recently. > > On the other hand, many users benefit from the one package, because they > need to get software approved, if they get QGIS packaged with GRASS > approve, they got GRASS as well. Getting approval for each individual > provider is likely more paperwork. > > I hope this will help and let me know what I'm missing. > > Best, > Vaclav > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > saga-gis-developer mailing list > saga-gis-develo...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/saga-gis-developer > -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
Il 10/02/2018 14:38, Anita Graser ha scritto: > On Fri, Feb 9, 2018 at 11:01 AM, Richard > Duivenvoorde <rdmaili...@duif.net <mailto:rdmaili...@duif.net>> wrote: > > Maybe at a hackfest, foss4g or other meeting it is good to come together > face to face so it is easier to actually SHOW each other the > bears/problems we see? > > > Since Madeira is just around the corner, let's organize a round table > discussion on this issue. I've started a section here: > > https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira2018#future-of-processing-providers > > Please add yourself to the list if you are interested in participating > on-site or remotely. We'll then try to find a time slot that works for > everyone. thanks Anita for setting it up. Please all interested parties add your name to the list. All the best. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
Il 09/02/2018 09:34, Rashad Kanavath ha scritto: > I am giving up on this contribution as it seems impossible to get small > changes like this. > Thanks for all your time. Hi Rashad, please be patient: bear with us, and we'll find the most efficient solution. In QGIS we have a very friendly environment, even when tech discussion may seem harsh and lengthy. I'm sure there is ample room for profitable cooperation. All the best, and thanks for your work. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] External providers in QGIS
Il 08/02/2018 15:49, Nikos Alexandris ha scritto: > * Moritz Lennert <mlenn...@club.worldonline.be> [2018-02-08 15:20:14 > +0100]: > >> On 08/02/18 15:08, Nikos Alexandris wrote: >>> I guess, there are numerous cases like this one. What would, >>> effectively, mean a removal of external providers (in this case GRASS >>> GIS)? >> >> Let's make it clear once and for all: noone is speaking about the >> complete removal of external providers. The issue is where, how and by >> whom they should be maintained, i.e. within the QGIS core code base, >> or as plugins. > > > Thank you the heads-up Moritz. true, but removal from core would mean the external plugin has to be created, maintained, tested, and documented by someone. If this is missing, the external plugin simply wil not appear. This is what happened with R. Once a provider is out and unmaintained, it becomes less visible, and less likely to attract attention. The work to bring it back to life, with all the above, will be much higher than when in core, and increasing over time. All the best. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
Il 08/02/2018 13:43, Rashad Kanavath ha scritto: > But aside all decision making stuff, can you check what is to be done in > this PR? > https://github.com/qgis/QGIS/pull/6272 > It is something worthy a discussion and not a plugin or not. I was > asking because QGIS 3 is near and diff is not that big. > If there is something extra need to be done to get this merged, I would > happy to hear about it. agreed, this is an important and urgent point. please some qgis dev could check this? thanks. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] External providers in QGIS
Il 08/02/2018 10:31, Rashad Kanavath ha scritto: > I don't know what these developers are going to do with a bugfix after a > new release. That's some kind of mystery unsolved to me. we are doing regular point releases, an approach which has proven very successful IMHO > I hope there will be zero bugs after releases. I hope you are joking :) All the best. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
Hi all, I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable for serious, comprehensive GIS analysis work. Full stop. Missing one specific alg, even if not used daily, means having to switch to other software. We have already removed R provider: even if used by a tiny minority, and certainly not perfect, the previous situation was better than the current one, without the option of using R from QGIS. I think we have to be extra cautious on this ground. All the best. Il 07/02/2018 19:07, G. Allegri ha scritto: > - from my experience - comprising years of feedbacks from the courses I > teach - the most frequently used algs are available within the GDAL and > QGIS algs list > > - a few generic and widely used algs are from GRASS and SAGA. We would > miss them - out of the box - but it could also be an opportunity to port > them. For examples v.to.points, transects, profiles. > Anyway we would have the plugins for GRASS and SAGA, in case... > > - specific algs are for specialized users. Here I think plugins are best > suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the > list, consistently with the others approach. > > I appreciate a lot the work from Richard, I hope this discussion is not > understood as to belittle its effort! -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] External providers in QGIS
Il 07/02/2018 11:18, Victor Olaya ha scritto: > I dont see the advantage in having providers in core. I see the following: * tests (already available in our infrastructure) * translations * more exposure * documentation > And if there is an > advantage, it's clearly not in how easy it is going to be to maintain > the plugin. until now it has been maintained somehow; if more resources are needed, we can find a way > If the people responsible of a given backend (like OTB) are > going to maintain it (which makes sense), why putting it in core where > they don't have write access? why not granting them write access? > Better in a separate repo. Also, they can > release whenever there are changes, without having to wait for a new > release. That way, the plugin will always be in sync with new releases > of the backend app. this is certainly true; AFAICT OTB people has proposed a solution > If we put them in core...why putting only this big ones (which in some > cases require installing external apps manually by the user), and not > put other plugins that exist and contain Processing providers? I'd be in favour of adding anything important for users. Thanks for your thoughts. When in Madeira we can have a discussion about this. It would be good if all interested parties could meet, locally and remotely. All the best. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] External providers in QGIS
Hi all, following the discussion on qgis-dev ML: https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html it has been proposed to remove all external providers (namely OTB, already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will remain as QGIS cannot be built without). This raised a number of concerns, so PSC decided not to rush removing them from the upcoming 3.0 release, and to open a wider discussions about this, involving all the interested parties, to find an optimal solution. If volunteers outside QGIS core team, ideally from the respective backends, could take the maintenance of these providers, not much would change for the end user. If not, this will mean effectively missing hundreds of algs from QGIS. I personally propose to reinstate the OTB plugin with Rashad (from OTB) as maintainer. QGIS.ORG will seek to support any decision made with funding where possible. Looking forward for your feedback. All the best. -- 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-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS help translation
Il 16/01/2017 09:13, Luca Delucchi ha scritto: > yes, your help is really appreciate. Maybe could we work on this in > Genova during the community sprint? sure, we can try > As Glynn wrote in the ticket, the main problem is to understand how to > fix the building procedure unclear to me; IMHO better to prepare all the po we intend to start translation on, at every compile. All the best. -- 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-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS help translation
Hi all, it would be good to translate the help. A long standing issue is here: https://trac.osgeo.org/grass/ticket/846 May I suggest to move translation files to Transifex, so it will be easier to involve and motivate more users to contribute? I can help if necessary. Thanks. -- 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-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] New GRASS plugin: a test drive
Il 06/10/2015 13:29, Radim Blazek ha scritto: > I have added qgis.v.upgrade.py which runs fine, I like that. > but v.db.reconnect.all fails with -d even from GRASS shell: here it worked well for a couple of locations. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] QGIS and GRASS 7.0.0
Il 09/03/2015 00:38, Pedro Venâncio ha scritto: It looks really really great! Awesome, chapeau! Looking forward to see the crowdfunding. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Il 23/04/2014 15:12, Radim Blazek ha scritto: I am not even trying to ask that question. As long as there are GRASS users using the QGIS plugin, it should not be thrown away. agreed fully, of course. The issue is: how much work is required for this? and: who is goig to invest on it? There is the GRASS Direct lib which allows GRASS raster modules to read/write data through QGIS providers. I is currently disabled, needs some fixes but it was mostly working. If fixed, it can be easily used in Processing, I think. I think rasters are not a big issue (AFAIK they are read through v.external, so no import); vectors seem more diffucult to handle though. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Il 22/04/2014 15:55, Radim Blazek ha scritto: Thanks for this. If I understand well, this means: * we can load GRASS7 vectors through QGIS browser * we cannot load GRASS7 rasters * the qgis-grass-plugin is not functional with GRASS7 Yes. We are talking about current master, not about intended final implementation. BTW, GRASS6 vectors apparently cannot be loaded from QGIS browser as a whole. This, coupled with several serious regressions I found, may mean that GRASS support in QGIS is essentially broken, You are talking about GRASS 6 support? What are serious regressions? * creating a new location is partly broken (cannot take the extent from the canvas, at least for some projections); a minor issue, but a serious concern for new users * the region resolution cannot be changed interactively. The Processing plugin may substitute GRASS Tools part of the plugin (i.e. modules GUI), it cannot help with: - mapset creation - vector/raster maps visualization - vector digitizing - region visualization and editing The Processing plugin is good for users who don't want to use GRASS data format at all. The GRASS plugin is GRASS GUI alternative for true GRASS users. Yes, got it. The question is: what is the real advantage to use grass alone, instead of jointly with other tols in Processing? I see two major ones: * Processing is blocking the main QGIS canvas, which for very long analyses is unacceptable * import-export overhead is a serious issue for complex vectors. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Hi Radim, Il 18/04/2014 11:31, Radim Blazek ha scritto: I have upgraded the vector provider to GRASS 7, layers may be added by drag from browser. The raster and the plugin are disabled. Be careful about multiple versions on the same system (LD_LIBRARY_PATH..., check with ldd if does not work). Thanks for this. If I understand well, this means: * we can load GRASS7 vectors through QGIS browser * we cannot load GRASS7 rasters * the qgis-grass-plugin is not functional with GRASS7 BTW, GRASS6 vectors apparently cannot be loaded from QGIS browser as a whole. This, coupled with several serious regressions I found, may mean that GRASS support in QGIS is essentially broken, and things may only get worse with the arrival of GRASS7, if nobody works to fix it. Am I too pessimistic? 1) add a requirement that GRASS 7 used with QGIS must be compiled with -fexceptions this IMVHO does not seem feasible for all OS and distros. 2) add a requirement that a patch (it is a single line comment in fact) must be applied to GRASS 7 to make it usable with QGIS same as above 3) use setjmp()/longjmp() 4) let QGIS crash whenever GRASS lib function fails this is obviously unacceptable. The most likely solution seems to use GRASS only through Processing. This also has a number of major limitations, however. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Il 28/03/2014 15:51, Markus Neteler ha scritto: I have submitted the Processing for GRASS GIS 7 to Pirmin and Victor for git upload. Now the user has GRASS 6 and 7 both supported in Processing. good news, thanks. are you referring to the upgraded and new modules? all the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
Il 28/03/2014 15:16, Paolo Cavallini ha scritto: Il 28/03/2014 15:04, Martin Dobias ha scritto: The support for GRASS is already in the browser - if you enter a directory that is a GRASS database, it will detect it and show locations/mapsets/maps/layers. In the GRASS plugin there are a few more features, i.e.: * showing history (important) * copy/rename/delete. If we can add these, I think the corresponding section of the plugin would be rather useless. Am I missing something? What about writing down the minumum set of requirements to be preserved? Please add it to this thread, we can note it on a wiki page once bolied down. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS QGIS: the future
Hi all. I learned during dinner that GRASS7 RC1 is due very soon. This opens the issue of its functioning in QGIS. IMHO: * the qgis-grass-plugin might stop working (this has to be tested) * some of the module options will be different * new modules will not be available in QGIS. I think we can deal with this in several ways: * dropping the plugin, and concentrate the work on Processing * upgrading both the plugin and Processing. In the first case, we have two major issues: * upgrading Processing GRASS modules * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. While the first issue can be solved easily by a couple of people in a few days, the second one is more tricky, and requires hard coding skills. In addition, we'll no longer be able to edit GRASS vectors directly. In the second case, we'll have more work, and a not-so-nice duplication. I would like to have an open discussion on this, avoiding things to just happen, with the possible negative consequences. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Il 27/03/2014 12:18, Markus Neteler ha scritto: * upgrading Processing GRASS modules I'll do that. I already started with Pirmin and Victor to discuss it. good news * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. ... this would not be a good idea. could you please explain why? all the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
Il 27/03/2014 12:33, Nathan Woodrow ha scritto: I would vote for dropping the plugin and just updating the processing plugin. Having both ways is bad for us and bad for users, even worse when some functions are missing from one but not in the other. I understand well the point; however, the plugin has additional functions, e.g.: * a grass shell * a grass data browser * a grass digitizing environment. Whether these are important or not, it's a matter of users. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.latlong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 17/07/2013 15:21, Markus Neteler ha scritto: On Wed, Jul 17, 2013 at 12:06 PM, Paolo Cavallini cavall...@faunalia.it wrote: Just seen the very nice i.latlong (BTW: why not r.latlong?): any hope of having it backported to grass6? Done in r57191. You can test it with: g.extension i.latlong I agree that r.latlong would be more appropriate. If there are no objections, I would rename it in both G6 Addons and G7. Thanks a lot. So it will be in the addons, not in main? BTW: if I can have a list of the new or changed packages in the new release, I can update qgis and sextante modules. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHnirQACgkQ/NedwLUzIr4eNACeI0LC+HD2HWzHRB/a61x7AezS GUAAoKCmfsD3A8O3f0TQ/ixgAfG+eT+C =MUNk -END PGP SIGNATURE- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.latlong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 18/07/2013 12:24, Markus Neteler ha scritto: For now yes since we don't know if it works for anyone else than me. Did you try? not You mean for GRASS 7? not: G7 is not (yet) supported by QGIS GRASS 6 will remain the same with the user interface. just a very few new modules were added over the past years: http://trac.osgeo.org/grass/wiki/Release/6.4.3RC1-News#Newmodules http://trac.osgeo.org/grass/wiki/Release/6.4.3RC3-News#Newmodules http://trac.osgeo.org/grass/wiki/Release/6.4.2-News#Newmodules http://trac.osgeo.org/grass/wiki/Release/6.4.1-News#Newmodules thanks a lot for this. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHnx5wACgkQ/NedwLUzIr6upACffR/VRNzWbJD4ahSoW7osDw/v rMYAnRyKeC1mgH5KlHwcPXp8okviAQC6 =rden -END PGP SIGNATURE- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] i.latlong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. Just seen the very nice i.latlong (BTW: why not r.latlong?): any hope of having it backported to grass6? Thanks a lot. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlHmbL0ACgkQ/NedwLUzIr5cawCeMnmcysj7GHV1FsS4aTjDV96Y LhEAn3o3xp/tlC1OCwgTodsvCanRDnrO =HZCQ -END PGP SIGNATURE- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Strange import of .asc
Il 18/01/2013 11:55, Radim Blazek ha scritto: GRASS GUI? Could you try with pure GRASS d.mon, d.rast, d.vect? The problem could be the same as in QGIS, lost window precision. It was in fact a QGIS bug, beautifully fixed by Radim. Thanks, and sorry for the noise. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Strange import of .asc
Il 14/01/2013 20:17, Helmut Kudrnovsky ha scritto: yes - have you tired displaying it under the vector? yes, the newly imported raster and also your raster delivered with the location are aligned with the vector. I've also tested a raster link with r.external, this linked is also aligned to the vector. I get this strange artifact (both on GRASS and on QGIS GUIs), see attached (in red the vector derived from the imported raster, on the background the imported raster; the original one is perfectly aligned with the vector). I suppose as a consequence of this, querying values gives wrong results. Thanks a lot. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario attachment: shot2013-01-15 10:24:33.png___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Strange import of .asc
Il 14/01/2013 20:17, Helmut Kudrnovsky ha scritto: yes - have you tired displaying it under the vector? yes, the newly imported raster and also your raster delivered with the location are aligned with the vector. I've also tested a raster link with r.external, this linked is also aligned to the vector. at other zoom levels, I get different misaligment, see attached -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario attachment: shot2.png___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Strange import of .asc
Il 15/01/2013 14:42, Paulo van Breugel ha scritto: Hi Paolo I have imported your layers in grass 6.4 and the vector and both the rasters (original and the asci after import) align perfectly well. I tried the same in grass 7.0, with the same result. Thanks a lot to both of you for checking. I have this issue both with 6.4.2 on Debian and (I suppose) 6.4.3RC2 from osgeo4w. Really puzzling. Ideas on wht to test? All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Strange import of .asc
Hi all. Importing an .asc file (with -o) results in a raster which is not aligend with the original. When vectorizing it, the vector is aligned with the original, not with the imported one. Original file and GRASS Location, with imported raster and resulting vector, here: https://www.dropbox.com/s/w60ywwddl3aj03h/cavallini.zip Anyone confirms? If so I'll open a ticket. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Strange import of .asc
Il 14/01/2013 15:51, Helmut Kudrnovsky ha scritto: Hi Paolo, the extent seems to be the same? yes - have you tired displaying it under the vector? additionally, in qgis-dev I get errors querying the raster: 168 bytes expected but 320 byte were read from qgis.d.rast thanks a lot for your help. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: Re: [Qgis-developer] again on encoding problems
Hi all. I assume grass-dev are aware of the problem. Has this been solved in wxPy GUI? How? Looks as a serious issue, as it is keeping lots of people away from grass in qgis at least. If you have a solution, we'll be happy of implementing in qgis, workload permitting. Thanks. Messaggio originale Oggetto:Re: [Qgis-developer] again on encoding problems Data: Thu, 25 Oct 2012 15:16:38 +0900 Mittente: Paolo Cavallini cavall...@faunalia.it A: Maris Nartiss maris@gmail.com CC: qgis-developer qgis-develo...@lists.osgeo.org Thanks maris. Are grass dev aware of the problem? Could we then display grass in English when on windows, for these languages? It seems important. All the best. Maris Nartiss maris@gmail.com ha scritto: Hello Paolo, I haven't seen how QGIS GRASS plug in is built, still my 0.02 from GRASS side. Some time a go I investigated encoding problems in native GRASS on Windows (WinGRASS) and my conclusion was - it is not possible to fix it for GRASS 6 due to character encoding handling in Windows. Reason was simple - there's no single coding to cover all use cases in Windows (CLI has one system (OEM), GUI has it's legacy system (ANSI) and add to all also Unicode in more recent code). As GRASS strings might come in all three encodings, unless the source of string is known, it's impossible to convert/display string correctly. Somebody with greater QGIS part can correct me, if I'm wrong (as I would like to be :) ). Maris. PS. http://lists.osgeo.org/pipermail/grass-dev/2011-March/053874.html 2012/10/24 Paolo Cavallini cavall...@faunalia.it: Hi all. Here in the Far East the encoding is a serious problem hampering the use of QGIS. I was just pointed out a problem with the GRASS plugin on Win: http://hub.qgis.org/issues/4547 and the solution the use: http://osgeo-org.1560.n6.nabble.com/Qgis1-5-Grass-tt3730164.html#a3730165 basically they set up the entire environment in EN, but this is not optimal, as the translation is actually there, as we can see e.g. on osx and of course on Linux. It looks a very simpl e problem, anybody has an idea on how to solve it more elegantly? All the best, and thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu http://www.faunalia.eu Full contact details at www.faunalia.eu/pc http://www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario Qgis-developer mailing list qgis-develo...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://faunalia.it/pc ___ Qgis-developer mailing list qgis-develo...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: Re: [Qgis-developer] again on encoding problems
Il 26/10/2012 06:32, Glynn Clements ha scritto: Paolo Cavallini wrote: I assume grass-dev are aware of the problem. Yes. Has this been solved in wxPy GUI? How? No. Thanks a lot Glynn for the explanation. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] IRC?
Hi all. Has the IRC channel been moved? I noticed a drastic drop in participation and activity these days. Thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS and sextante
Hi all. Now working on sextante interface to grass. One problem I'm finding is: - GRASS raster can have labels (very convenient, e.g. r.param.scale saves feature names along with categories) - when saving to TIFF, these are stripped - as a consequence, the flow DTMFeatures rasterFeature vector strips the categories, and data are lost. Any way of keeping them? Of course we can Use raster values as categories, but keeping the labels would be much better. One way would be to pipe directly the two GRASS commands, without exporting in between, but this is not implemented yet. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] on the subject of toolboxes ...
Thanks Hamish for this discussion. Il 20/05/2012 03:51, Hamish ha scritto: before any work begins on this in earnest at the code sprint, I'd just like to reiterate my take on the toolbox idea. i.e., (and insofar as I understand the proposal as it exists!) any move towards splitting up GRASS's build system and distribution package(s) would be a really really huge mistake. I think there are two issues here: - development cycle - distribution. I agree warmly that distribution should make life as easy as possible for users, so a single package (standalone installer) is the main way to go. As for development, I think splitting the release cycle of GUI and CLI would be advisable, as they have different cycles, speed of development, and dependencies. More clearly: if a [new|fixed|improved] command is ready, and its native GUI is not, are we sure we want to keep this away form users that can profit form this using the CLI or a different GUI? Namely, implement views in the wxGUI preferences section, with tick boxes where you can hide or show groups of modules as desired. A core set of common modules would always be ticked in a greyed-out box, and an enable all button would be present. Beyond that you can pick and choose. I find filtering (as done in QGIS and in Sextante) quite simple and useful. Adding tagging would be enough IMHO. Views could be interesting. One of the major benefits of GRASS compared to other kitchen-sink GIS is that you DON'T have to mess around with installing toolboxes. Every- thing you need is there already. Agreed - that's why I'm still uncomfortable with addons (even though I understand its rationale). In short, the disk space / download-time argument is a non-issue. Agreed fully. Modularity, however, is always a Good Thing (e.g., I appreciated very much your splitting because I do not want to install GUI stuff on a server, etc.). One final concern is that by relegating modules seldom used by the dev team into what would essentially be second class toolboxes, those modules will wither and die, and our more outside-of-the-mainstream users will suffer for it. Agreed. comments? criticisms! both most welcome.. Hoe this mine will be useful. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass plugin: new password option?
Hi all. Recently in the interface of the following modules: v.in.ogr.qgis v.in.ogr.qgis.loc r.in.gdal.qgis r.in.gdal.qgis.loc a new option, grayed out (Password) has appeared. The only difference I see is: file key=input / [no password] --- gdal key=input / [password] so it could be due to a change in gdal/ogr (I have 1.9 here). Anybody has a hint on what can be happened, and how to fix it? Thanks a lot. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.centroid: on boundaries only?
Hi all. The current command for v.centroid in the grass qgis plugin is: qgisgrassmodule label=Add missing centroids to closed boundaries module=v.centroids option key=input layermask=0 typemask=area/ option key=output/ option key=option answer=add hidden=yes/ option key=cat answer=1/ option key=step answer=1/ /qgisgrassmodule Am I right saying that it should be typemask=boundary ? Thanks for the advice. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.centroid: on boundaries only?
Il 27/01/2012 13:37, Moritz Lennert ha scritto: typemask is not an option for v.centroid, but a grass-plugin specific parameter. What does it do ? it filters out the type of maps that appears on the list. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.centroid: on boundaries only?
Il 27/01/2012 13:42, Martin Landa ha scritto: AFAIU, it's related to `type` parameter. `typemask` filters vector maps which contains given type, ie. in this case only vector maps which contains at least one area (closed set of boundaries) are shown in combo box. ok, so the current set of options seem right. thanks a lot. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] possible bug - more coordination needed
Hi all. All py grass commands in QGIS stopped working a while ago: http://hub.qgis.org/issues/4667 now we are fixing them from the QGIS side, but apparently this is due to a change in behaviour from the GRASS side. We at Faunalia are ready to invest to keep the plugin working, and will greatly appreciate if someone from the GRASS side could let us know when something potentially harmful for it is done, so we can fix it sooner. In general, a better coordination between the two projects is necessary, if we want to keep the plugin working over the long term. Thanks in advance. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] possible bug - more coordination needed
Il 17/01/2012 14:19, Hamish ha scritto: It seems from that bug report that you are building against grass trunk? not: 6.4.1 and will change all the time, without warning, guaranteed. The stable branch will hopefully remain stable/backwards compatible for a long long time, specifically so things like the qgis plugin will continue to work with a minimum about of maintenance. Unfortunately, this is not the case. A number of issues have arisen in the past. completely agree. - would a dedicated inter-project qgis-grass-plugin osgeo ML help? not sure, don't think so - what are the biggest issues with it to work on right now? My main concern is that occasionally interfaces are changed, without letting us know, so we have to spot the problems after they occur, and with the large number of modules, this is painful; many errors risk to go unnoticed for long, especially among less popular packages. All the best, and thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] possible bug - more coordination needed
Il 17/01/2012 14:54, Hamish ha scritto: so those are GRASS python scripts in qgis svn written by Radim which use the GRASS python libraries. exactly. my thinking was that many grass devs probably can not keep up with the qgis-dev mailing list traffic, and many qgis devs probably can not keep up with the grass-dev ML traffic. so if there was a low volume ML for interested parties from both dev teams it would be easier to keep up to date. My fear, on the other side, is that nobody will realy subscribe to this one. I would do, who else? command line interfaces should not have changed at all since GRASS 6.0.0 it is hard to predict unintended consequences, but we do our best.. It should not be too difficult: we need to know if the syntax of a command (as it happened e.g. for v.buffer), or if the interfaces changes. In general, the coupling of QGIS and GRASS is not too tight, so it should be reasonably easy to predict when something can go wrong. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] possible bug - more coordination needed
Il 18/01/2012 05:00, Hamish ha scritto: well, at least I would. well, me and you is not really much :) in that case when we switched out the modules we didn't fully realize it was missing either until it was too late. IIRC it was just a debug option that was removed? if we had noticed it in time the option would have become a no-op which just produced a warning or error message. (e.g. see 'r.sun lat=') bugs happen... Yes, but in other cases the changes were more obvious (change of module options). The problem is that there is no direct connection between the two projects. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Raster history: why not reclass
Hi all. The history of rasters is one of the very nice features of grass. I noticed that in reclassified rasters, however, the rules are not saved, so the user does not have a clue of how the raster have been reclassified. Is there any special reason for this? Any plan to implement it? Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Raster history: why not reclass
Il giorno sab, 24/09/2011 alle 11.05 +0200, Markus Neteler ha scritto: Ideas - improve this in GRASS 7 - store the reclass file in the metadata space in the mapset and display it with r.info if file present (should be backward compatible like this) I think having an extended history would be good. Would you open a ticket on this, or should I? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.generalize: flag -r removed?
Hi all. Apparently the flag -r has been recently removed. May I know the reason in a few lines? I have to adjust the QGIS the plugin, and I prefer to understand before doing. Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.generalize: flag -r removed?
Il giorno sab, 24/09/2011 alle 15.48 +0200, Markus Metz ha scritto: Until recently, v.generalize did not work with boundaries, more generally, did not fully adhere to the grass vector topology model. The -r flag was one of the components causing damage, further on it duplicated functionality covered be v.clean and made the interface even more complex. Therefore it was removed while overhauling the module. Thanks a lot Markus for the clarification. Fixed in QGIS plugin. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Status of the qgis-grass plugin, esp. on Windows
Hi all. As qgis-grass-windows user know, we had a couple of nasty bugs [0],[1] preventing a proper use of GRASS within QGIS on Windows. One of the bugs seemed fixed upstream, but we still missed an osgeo4w package for it. We (Faunalia) do not use Windows, but we do a lot of courses, and many users have Windows machines, so we had the choice of either removing GRASS from our courses or get our hands dirty and debug GRASS and its QGIS plugin on Win. Of course we did the latter. We believe now everything should be solved, so all well. However, we would like to point out that: - a grass-dev package, built overnight, is missing from osgeo4w; we think this is quite bad, as testing on win lags very much behind in this way; of course grass-only users can install the standalone, but we think a complete environment is better; IOHO this should not be hard to set up, so we encourage GRASS maintainers to do so (AFAIK Martin Landa is working on this); of course we're ready to help if necessary - the qgis-grass plugin is receiving very little, if any, care; I think we (Faunalia) did most of the work on it in the last few years; we're happy to do it, but we miss the resource to do it on a regular basis (e.g. there is a number of bugs to be fixed). Are we the only users, or there are more around? If so, please stand up and help us, either patching the code or providing some resources, or even better becoming the maintainer of the plugin, otherwise we're afraid the maintenance will become more and more difficult. All the best. [Giuseppe | Giovanni | Paolo] @ Faunalia -- Paolo Cavallini - Faunalia www.faunalia.eu See details at: www.faunalia.eu/pc [0] http://trac.osgeo.org/grass/ticket/1158 [1] http://hub.qgis.org/issues/3646 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [Qgis-user] Status of the qgis-grass plugin, esp. on Windows
Il 10/09/2011 02:07, William Kyngesburye ha scritto: Don't forget OS X - the grass plugin is currently broken for OS X as a result of a fix for Windows: http://hub.qgis.org/issues/3999 Sorry, I missed that one. One more reason to find urgently a maintainer. I'm afraid the only other option is to drop support for this important plugin, which IMHO would be a major problem. Keeping it broken is a bad thing for the reputation of the project. Please users help, if this plugin is useful for your work. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu See details at: www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [Qgis-developer] Status of the qgis-grass plugin, esp. on Windows
Il 09/09/2011 23:37, Martin Landa ha scritto: I am going to provide daily build packages for GRASS 6.4, 6.5 and 7.0 for OSGeo4W within few next days. Great news, thanks; please do not hesitate asking for help if needed. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu See details at: www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [Qgis-developer] qgis-grass poll
Il 21/05/2011 19:27, Mars Sjoden ha scritto: On Sat, May 21, 2011 at 9:56 AM, Charlie Sharpsteen ch...@sharpsteen.net mailto:ch...@sharpsteen.net wrote: On Sat, May 21, 2011 at 9:15 AM, Paolo Cavallini cavall...@faunalia.it mailto:cavall...@faunalia.it wrote: Hi all. I would like to do a poll on qgis-grass usage: which would be the best web tool to use? Probably better not to use qgis or grass pages; does osgeo provides polling facilities? Hi all. OSGeo is currently unable to provide polling facilities. I would like to avoid qgis and grass websites, not to bias the results, and woldn't like too much to use an external service: any better idea? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] qgis-grass poll
Hi all. I would like to do a poll on qgis-grass usage: which would be the best web tool to use? Probably better not to use qgis or grass pages; does osgeo provides polling facilities? Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] QGIS processing framework
Hi all. At the hackfest in Lisbon we started discussing the development of a QGIS processing framework, to unify the addition of OTB, SAGA, and possibly other external analytical sw. This is very exciting because it will allow, if developed properly, the creation of analytical pipelines even across different sw. The project has started well, because OTB has resources for development, and the SAGA plugin has been funded by GSoC. I think it is important that GRASS will join the bandwagon, so that the framework will accommodate also GRASS needs. See the thread at: http://lists.osgeo.org/pipermail/qgis-developer/2011-April/014057.html I'll be glad of knowing your feelings about this. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Il 27/11/2010 23:40, Hamish ha scritto: for the record I regularly build grass 6.5svn on an old debian/etch machine which has no wx2.8 avail. ie just for the CLI. It copies python files into a gui/ dir at install but never uses them. C++ wx modules are not build (cleanly). no problems at all... zero. please think of normal users: believe it or not, people does not compile their packages, and rely on executables. as per dual packages, I'd say not necessary, extra work for very little gain. it would just save a megabyte or two on the install. this is not the point: it will save unnecessary dependencies. That's why in sane OSs packages are split in several independent subpackages. the gui development is very good at exposing limitations in the CLI versions of everything, so it's natural that they both grow together. and it is already very well separated at the code level. the only thing that aren't are interactive apps which are not relevant to the CLI-only crowd. if they are well separated, why not separating them, giving more freedom to users? I agree that GUI and CLI will grow together, but why waiting in the release of one part just because the other is still to be fixed? The rationale is: decoupling CLI and GUI will make the release cycle smoother, and allows a greater freedom, especially for 3rd party applications, either desktop or web. I would like to see GRASS spreading further in the freeGIS arena, and I'm suggesting this could be a way. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Il 28/11/2010 02:51, Glynn Clements ha scritto: If the only available packages (RPM, .deb, etc) insist upon installing GUI libraries, complain to the people who make the packages. OK, so, now I'm complaining ;) : packagers, please have your saying here. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Il 21/11/2010 21:36, Michael Barton ha scritto: Like Martin said, because GRASS is modular, anyone can compile it or use it with or without the GUI. I use it heavily with the GUI for some things. For others, I use it completely scripted, without any GUI, and called from a completely different environment. This kind of flexibility is a real value for this piece of software. AFAIK this is not true: compiling (better: packaging - believe it or not, not *anyone* is capable of compiling) without the GUI requires changes in the source code. Sorry to insist, I realize my position is not popular among GRASS devs, but there is a number of situations where having a pure CLI package would bring great advantages. E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS can be used for WPS? Please, help us poor users: separate the two packages, and we'll all be happier. I do not think it's a major work, and packagers can probably give a hand. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: db.* icons for GRASS
Hi all. Please have a look to this new set of icons. Tey'll be used for the QGIS_GRASS toolbox, but of course are available for other uses. Comments welcome. Thanks a lot to Robert! Messaggio originale Mittente: Robert Szczepanek db.* icons are ready http://grass.osgeo.org/wiki/GRASS-QGIS_relevant_module_list#Database_modules also available in svn. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Il 21/11/2010 21:36, Michael Barton ha scritto: There is nothing inherently wrong with releasing different parts of GRASS at different times.But trying to manage a single release cycle for GRASS has been pretty complicated and my hat is off to Markus. Trying to manage multiple release cycles would be more complicated. My suggestion is that decoupling CLI and GUI will make the release cycle simpler, not more complicated. We do not need additional complexity. All the best. -- http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] CLI!=GUI
Hi all. I know it's an old thread, and that not everybody agrees, but I still think, after talking with people more knowledgeable than me, that separating the core of GRASS (libraries+CLI) from the GUI(s) will make the release and packaging process faster and smoother, and the integration with other software, both desktop and web, easier and cleaner. Can we revive the discussion about this? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] edit region
Hi all. Final take of current cleanup of QGIS GRASS toolbox: the Edit Current Grass Region has been improved. Now it is compliant with the QGIS graphical guidelines, and the code has been cleaned, updating to current Qt functions. Hope you'll like it. Now we only miss clean icons. All the best. -- http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] on the fly grass location
Hi all. As it has been discussed earlier, having location generated (and destroyed) on the fly would help a lot the casual qgis grass user to approach grass. The idea is to run an analysis by loading (r.external, v.external, v.in.ogr) data, generating a location from it, run, save the results as tif or shp, and destroy the location at the end, all without users noticing it (but explaining for future reuse). The good news is that here at the hackfest we got a voulnteer willing to help with the coding (preferably in Python). Welcome Peter Loewe! Anybody willing to help him with the first steps? All the best. -- http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] refreshing GRASS toolbox
Hi all. We have been doing a number of improvements on the QGIS GRASS Toolbox, mainly polishing the interface and making it more compliant with general GUI rules of QGIS. Hope you'll like it. More work is to be done. Robert Szczepanek kindly volunteered to prepare new icons, with a style uniform with the newgis icon set. You can see a sample done for db.* commands. It is a major task, so let's hope he'll be able to carry on speedy ;) I would like to have a peer review of the new icons as they come out, to be sure they are easy to understand for everybody (at least as understandable than current ones, surely more beautiful). So please follow the process, and send your comments. Probably the best thing would be if Robert can pload the new icons to http://grass.osgeo.org/wiki/GRASS-QGIS_relevant_module_list, where we can collect qualified comments before adding them to the toolbox. Looking forward for your collaboration. All the best. -- http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] current state of r.li
Il 12/11/2010 22:35, Hamish ha scritto: there is no reason to only do qgis or wxPython, we should do both! So you are volunteering for both? Great news! ;) the bigger issue for r.li was r.li.daemon et al using UNIXisms which didn't work on MS Windows.. but IIRC Glynn already fixed that in grass7? AFAIK it works also on win. All the best. -- http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] current state of r.li
Hi all. Sorry for crossposting. As some of you know, the r.li suite of GRASS commands allows landscape analyses[0]. Its interface is rather complex, and is still in TclTk, not ported to either wxpython or qgis. As such, it is now more difficult to use than it should be, and it will become unusable when TclTk support will be dropped. The possible solution (thanks Radim) is to rewrite the interface as a qgis python plugin. It should not be a huge work (we provisionally estimate 2-3 weeks). The question is: is there anybody willing to invest either his/her time, or some money, to write such a plugin? We (Faunalia) would be happy to help if necessary. All the best. -- http://www.faunalia.it/pc [0]http://grass.fbk.eu/gdp/html_grass64/r.li.setup.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] qgis grass modules
Hi all. From the hackfest: we started working on the modules as listed in [0], and added comments to them. Please check them and add your own. All the best. -- http://www.faunalia.it/pc [0] http://grass.osgeo.org/wiki/GRASS-QGIS_relevant_module_list ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.in.wfs
Hi all. The module apparently requires curl, but this is not a requirement of the package. I have the QGIS module ready, but before committing it we should add this dependency, otherwise in many systems it will not work. Any thoughts? Furthermore, I get frequent errors: Unable to open data source WFS-XML file not readable. Check if xerces-c support is compiled into GDAL/OGR library. using the advertised v.in.wfs wfs=http://webgis.regione.sardegna.it/geoserver/ows?service=WFSrequest=GetCapabilitiesversion=1.0.0; output=sard but not with the maunal example v.in.wfs \ wfs=http://mapserver.gdf-hannover.de/cgi-bin/grassuserwfs?REQUEST=GetFeatureSERVICE=WFSVERSION=1.0.0; out=grass_users All the best. -- http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.wfs
Il 11/11/2010 18:31, Markus Neteler ha scritto: In the script there is a test if curl is installed. I have now added this requirement also to the manual. Yes, but this makes the module unsuitable as a QGIS module, IMHO. What do you mean with adding? Or do you refer to the manual? I mean, if curl is a dependency of GRASS, then it's ok. The end user should have everything installed before running a program, not being asked to install it during normal usage. ogrinfo --formats show the format on your system? MMh, strange: apparently not, but http://mapserver.gdf-hannover.de is read. All the best. -- http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [Qgis-developer] Re: [GRASS-dev] new GRASS 6.4 modules
Il 25/09/2010 21:02, Micha Silver ha scritto: Two questions about the table - Do you think it's necessary/desirable to have a separate column for each release of QGIS? Hi all. I'm not authoritative here, but I believe we should target only current QGIS trunk. There has not been any backporting until now, so any fix will go on trunk only. How about color coding the rows like the DebianGIS thermometer. (If this idea is acceptable, I'm willing to do the wiki formatting.) Yes, I think a rating crucial - important - minor or similar would be very good to help focusing our efforts. Thanks a lot. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] new GRASS 6.4 modules
Il 23/09/2010 07:32, Hamish ha scritto: http://www.qgis.org/wiki/Adding_New_Tools_to_the_GRASS_Toolbox see at the end of the page. to help I made a wiki table with all grass 6.4 modules: http://grass.osgeo.org/wiki/GRASS-QGIS_relevant_module_list BTW: if we can have a well-thought list, before the upcoming hackfest[0], we'll do our best to implement the suggestions. BTW2: if any grass-dev or grass power user would like to join us at the hackfest, they'll be most useful, and this can result in a greatly improved GRASS toolbox. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc [0] http://www.qgis.org/wiki/4._QGIS_Hackfest_in_Wroclaw_2010 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] new GRASS 6.4 modules
Il 23/09/2010 07:32, Hamish ha scritto: to help I made a wiki table with all grass 6.4 modules: http://grass.osgeo.org/wiki/GRASS-QGIS_relevant_module_list note some dead qgis wiki urls at http://grass.osgeo.org/wiki/Development#GRASS_and_QGIS needs to be improved, you can sort by columns by clicking on the bowties Thanks a lot Hamish. Anyone willing to carry on the work? For instance, I assume all d.* modules are not relevant for QGIS, right? If we can come out with a clean list, we'll do our best to implement the missing, important modules. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Possible to update to 6.4 stable on UbuntuGIS ppa repo?
On Wed, Sep 08, 2010 at 04:39:04PM -0700, Isaac Ullah wrote: I'm not sure who maintains the compiled binaries on the ubuntugis ppa repository, so I'm addressing this request to the whole list. Currently, the version of GRASS64 on the ppa is RC6-2. Given that 64 stable has just been released, it would be nice to have the stable version put up to the PPA. For whatever reason the weekly snapshot does not install correctly on Ubuntu (hasn't for some time now). Generally speaking, Ubuntu takes a snapshot of DebianGis packages from sid/testing. Currently in DebianGis we have a post RC6 snapshot in use and incidentally we are near freezing of next stable version (6.0 aka Squeeze). That implies that we will not release the final 6.4.0, but a patched version which integrates almost all final fixes. ATM the only change that will be dropped for sure is the default GUI switching (Tk-Wx). More information could be asked on the DebianGis development list. Cheers -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] new GRASS 6.4 modules
Il 10/09/2010 18:28, Markus Neteler ha scritto: Paolo - agreed, an important issue. Please suggest a wiki page where we can collect responses. Done (I think I annuonced it earlier): http://www.qgis.org/wiki/Adding_New_Tools_to_the_GRASS_Toolbox see at the end of the page. We definitely need help. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] new GRASS 6.4 modules
Hi all. In the occasion of the release of GRASS 6.4, I think it would be good to revise the current QGIS-GRASS modules. Specifically: - there are modules that IMHO are of no use, and potentially confusing (e.g. several of those who manage projections, etc.) - there are new and useful modules to add to the toolbox - not all modules have been thoroughly tested. I encourage therefore GRASS users to help us defining both a wishlist for modules to be included ad a deprecated list, and to let us know if there are non-functional modules, so they can be fixed. Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [Qgis-developer] new GRASS 6.4 modules
Il 10/09/2010 20:02, MORREALE Jean Roc ha scritto: Paolo, if it is not of a too high level, could it be possible to write a wiki page explaining how to wrote and update the grass modules in qgis ? I would like to help on this point but I don't know how. Simple: http://www.qgis.org/wiki/Adding_New_Tools_to_the_GRASS_Toolbox See also: http://www.qgis.org/wiki/Adding_New_Tools_to_the_GRASS_Toolbox#Modules_which_can_be_added and following. (and yes, Markus, this replies to your other suggestion too; see and below). All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] admin question
Markus Neteler ha scritto: isn't it that you manage that in your user settings? did you check if they are identical? You are right: the option was: Get MIME or Plain Text Digests? Text is the good one for me. Sorry for bothering. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] admin question
Hi all. The grass-users ML is sending the mails in digest form as inline messages, whereas the grass-dev ML is sending it as attachments. While reading through my cell phone, the former is much easier to read than the second. May I ask the list admin to set the dev ML in the same way as the user one? Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.external fails on RasterLite
Hi all. Recent GDAL (1.7) support rasterLite smoothly (wow!). I can load it on QGIS, for instance. So I was tempted of using: r.external input=/home/paolo/Desktop/TrueMarble-2km.sqlite output=marble title=marble but it fails: ERROR 4: `/home/paolo/Desktop/TrueMarble-2km.sqlite' not recognised as a supported file format. The file is here: http://download.gfoss.it/TrueMarble/ Any explanation? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GDAL configuration for GRASS
On Fri, Apr 23, 2010 at 03:14:58PM +0200, Markus Neteler wrote: OK, if all worked why do you want to change it? ... due to ORFEO ToolBox Restrictions is not very clear to me. Because of known problems of libgeotiff + gdal linking in OTB, I think. The right solution would be inverting the linking order in OTB, anyway. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [SoC] Interested in GPU-based processing
On Thu, Apr 01, 2010 at 12:50:12AM -0700, Hamish wrote: As I understand it, CUDA is 100% dependent on the closed-source binary driver from nVidia and works on their video cards alone. Which is fine for today for people with nVidia hardware using their binary video card driver. If nVidia decides in a couple of years to stop supporting CUDA, your old card, your specific OS or distro, your OS or distro version+cpu type, or if they go out of business or are bought/sold to another company who is not interested, any code based on it becomes useless. For this reason code written for an open platform such as OpenCL, even if less advanced, seems to have a brighter long-term future. +1 Don't feed the lockers -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass from osgeo4w gets caught from antivirus
Hi all. The grass that is currently in osgeo4w gets caught by some antivirus, presumably because many executables have a further . in file name (eg r.out.png.exe). I guess this is more or less impossible to overcome, I send it here just for the record. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass from osgeo4w gets caught from antivirus
Markus Neteler ha scritto: Not sure but it is unlikely that you just need better antivirus software :) Not me! :) Just enterprise stuff, you know... All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-user] 6.4 vs 7.0
2010/1/18 Glynn Clements gl...@gclements.plus.com: Paolo Craveri wrote: If you use GRASS_OVERWRITE=1 \ r.mapcalc result = map * 4 it will work on both versions. In grass 6.4: GRASS_OVERWRITE=1 r.mapcalc result = rand(1,100) 100% r.mapcalc result = rand(1,200) ##ok, raster result has been overwritten 100% In grass7.0: GRASS_OVERWRITE=1 r.mapcalc result = rand(1,100) 100% r.mapcalc result = rand(1,200) ### raster 'result' hasn't been overwritten I have to setting GRASS_OVERWRITE variable and r.mapcalc command in the same line as you suggest: GRASS_OVERWRITE=1 r.mapcalc r = rand(12,24) in this case it works in both version. Strange behaviour IMHO. This indicates a difference in the state of the shell between the two cases, not a difference in GRASS. Entering GRASS_OVERWRITE=1 as a command sets the shell variable GRASS_OVERWRITE. It doesn't necessarily cause it to be exported to the environment used for child processes. If the command export GRASS_OVERWRITE has been executed in the current shell, the variable has been exported to the environment, and any changes to the variable will affect the environment used for child processes. OTOH, the command GRASS_OVERWRITE=1 r.mapcalc ... executes r.mapcalc with GRASS_OVERWRITE=1 in the environment for that specific process. See the bash manual page for more information. -- Glynn Clements gl...@gclements.plus.com Yes, I forgot export ...; my fault. Thanks -- -- Paolo C. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-user] 6.4 vs 7.0
Hi, 2010/1/17 Hamish hamis...@yahoo.com: If you use GRASS_OVERWRITE=1 \ r.mapcalc result = map * 4 it will work on both versions. In grass 6.4: GRASS_OVERWRITE=1 r.mapcalc result = rand(1,100) 100% r.mapcalc result = rand(1,200) ##ok, raster result has been overwritten 100% In grass7.0: GRASS_OVERWRITE=1 r.mapcalc result = rand(1,100) 100% r.mapcalc result = rand(1,200) ### raster 'result' hasn't been overwritten I have to setting GRASS_OVERWRITE variable and r.mapcalc command in the same line as you suggest: GRASS_OVERWRITE=1 r.mapcalc r = rand(12,24) in this case it works in both version. Strange behaviour IMHO. here input=- has been set to be a required input. AFAIU this is so the option appears on the first tab of the module GUI window (Required). I've complained about that before, so won't repeat myself, but what is really needed IMO is a new item added somewhere to help order the GUI sections so these GUI-at-the-expense-of-the-CLI hacks can be avoided. +1 thanks to all Paolo C. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass is a monad?
Hi all. Reading the recent post of Glynn: Right now, I'm actively trying to think of ways to make life harder for anyone trying to use the GRASS libraries for anything except GRASS modules. http://trac.osgeo.org/grass/ticket/869#comment:1 I wonder if this is somehow a view shared by GRASS-PSC, and I ask myself what would be the advantage of having GRASS as an isolate piece of software. I would greatly appreciate devs opinions on this. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.generalize
Markus Metz ha scritto: Also type=boundary instead of type=area would help. That was it. Now fixed on QGIS trunk. Thanks a lot. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.generalize
On Tue, 03 Nov 2009 11:59:34 +0100, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. I'm studying v.generalize; in the past I obtained good results, but now I keep on getting either 100% or 0% of the original vertices, no matter of which algorhitm and parameters I select: could this be a bug, or am I doing something wrong? Testing on debian testing, grass64-5 from deb unstable, through qgis interface. Thanks. E.g.: v.generalize input=sou...@butta type=area layer=1 method=douglas_reduction threshold=1000.0 look_ahead=7 reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0 closeness_thresh=0 betweeness_thresh=0 alpha=5 beta=5 iterations=1 layer=1 output=snake_simpl Generalization (douglas_reduction)... Building topology for vector map snake_simpl... Registering primitives... 1000 1488 primitives registered 31776 vertices registered Building areas... 713 areas built 618 isles built Attaching islands... Attaching centroids... Number of nodes: 1393 Number of primitives: 1488 Number of points: 0 Number of lines: 0 Number of boundaries: 775 Number of centroids: 713 Number of areas: 713 Number of isles: 618 Number of vertices was reduced from 31776 to 31776 [100%] Finalizado com sucesso -- http://faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.generalize
Hi Daniel. Thanks for your reply. I'm trying to generalize (and smooth) polygons, not lines, so your suggestion do not apply. Any other hint? All the best. On Tue, 3 Nov 2009 18:20:39 +, Daniel Bundala bund...@gmail.com wrote: Try v.build.polylines. This was discussed couple of times before. So you might want to have a look at some older discussions. -- http://faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] typo in r.random.cells
s/Name of indepent cells map/Name of independent cells map All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.generalize tutorial
Hi all. Would it be possible to move the very useful v.generalize tutorial: http://users.ox.ac.uk/~orie1848/tutorial.html to core documentation? Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.generalize tutorial
Hamish ha scritto: Paolo wrote: Would it be possible to move the very useful v.generalize tutorial: http://users.ox.ac.uk/~orie1848/tutorial.html to core documentation? it's already there my friend, http://grass.osgeo.org/wiki/V.generalize_tutorial Thanks. However, in the manpage the old link is mentioned: http://grass.itc.it/grass64/manuals/html64_user/v.generalize.html All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] libgrass+grass-gui?
Markus Neteler ha scritto: ... you can configure GRASS to deactivate Tcl or WxPython. I am doing so on my cluster installation which is CLI only. In which sense does the py-gui or tk-gui break QGIS? It does not, but splitting development in 3 branches would allow easier release of each. For instance there is a critical bug in one of the GUIs, but CLI is not affected, then libgrass can be released, and other apps (including QGIS) can rely on a stable release. The basic idea is that CLI and GUI have different speed of development and diffwerent stability issues and requirement, so when it is possible to allow different speed of release, this *seems* to me a good option. Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] libgrass+grass-gui?
Hi Hamish. Thanks for your thoughts. I think we agree more than it may seem. Hamish ha scritto: As the GUIs have developed in tandem we've added little library and module functions along the way when some variable needed to be exposed or some function deineractivated (if that word makes sense). Development is not completely independent, especially if you consder the mixed components like wxVdigit and wxNviz. I think modularity is the base of happiness: keeping things as separated as possible is good. As I mentioned, anything dubious should go to the GUI. Currently we have pretty much a max of 2 people working on the GUI at any one time. With the current release stalled primarily due to GUI on Windows issues it forces me to at least look at that code, even though I usually don't use either the GUIs or Windows myself. If it were separate that incentive wouldn't be there and the gui devels might get lonely and discouraged. I acknowledge this problem, but on the other hand I do not think it is very good to delay the release of stable libs because of a problem in the GUI: why not releasing the libs now, and the GUI as soon as it will be ready? ? AFAIK they can and do rely on the releasebranch_6_4, which should be stable enough not to be sensitive to this issue. This is not very good for packagers though. I worry that with a multi-tier system the lesser developed components would be further neglected by the other devels. Yes, this is a risk, very much present in GRASS since ages (as we all know, there are still unported tcltk menus, the nviz issue, etc.). However, delaying what many people see as the main strength of GRASS, its analytical power (this is not meant to offend GUI devs, sorry) is a symmetrical risk. The GUI is not-scriptable so the UI parts of it can change quite a bit within a stable release cycle without being limited by the preserve-backwards compatibility rule. Yes, I think GUI can have a different release cycle for this, as I mentioned earlier. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] libgrass+grass-gui?
Hi all. Would it be feasible to split grass into several branches: - libgrass, with all CLI modules - grass-py-gui - grass-tk-gui and release them separately? I guess this would make the release process easier, and integration with other sw smoother. Any major technical problem? I know there is some mixed code (nviz, imagery etc.), but this could go into the gui package, leaving in the lib only the CLI stuff. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Some doubts about GRASS topology
Benjamin Ducke ha scritto: Well, that clarifies it (finally)! Thanks very much for taking the time to write up all this detail. It's much appreciated. Ben Hi Ben. Would you mind documenting this a bit? It would be good to have in the official grass-doc. Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
