[GRASS-dev] RFC: variations of statistics in r.neighbors (and the stats lib)
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
Re: [GRASS-dev] grass70 package name
On Sat, Feb 21, 2015 at 05:47:19PM +0100, Sebastiaan Couwenberg wrote: > > What changes do you propose for the official Debian package to allow the > co-existence with the GRASS upstream packages? > [...] > The /usr/bin/grass to grass70 & grass71 executable in grass-core would > conflict between these packages. But IIRC the upstream GRASS packages > don't contain that symlink. The same may apply to the x-grass script, > but thank may get fixed when I address the issue raised by Martin [1]. > > [1] https://lists.debian.org/debian-gis/2015/02/msg00047.html > Adopting alternatives mechanism for grass, x-grass.sh and manpages would probably suffices. I'm not sure if that would really solve a true user's need, or it is only superfluous trick. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass70 package name
> I think it makes sense for GRASS upstream to use separate source > packages to allow co-installation, but this makes less sense for the > official Debian package. I would note that the need to allow multiple version to cohexist still applies, people will always need to run branche/svn versions on their computers. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] status of grass6.4.4 debian packaging ?
On Mon, Jul 28, 2014 at 10:53:25PM +1200, Hamish wrote: > Moritz wrote: > > Hamish and Frankie, > > > > What is the current status of packaging 6.4.4 for debian ? > > Hi, sorry for the delay, I've been largely out of the office for the > last couple of weeks. > > > Mainly notes to Frankie, but may as well cc everyone to keep y'all in > the loop: > > > As far as updates needed to the packaging files it's just dch to bump > the version number, and as far as I can tell the barscale_ui and > svn-any-version patches have been incorporated and are no longer needed. > > I've been building test packages since before release and AFAICT all > seems well. We might need to keep an eye on the grass64.desktop file to > make sure it gets included, but I think that's perhaps ok since the > debian package does is not using 'make install'. > > > The unpacked tarball lives in DebianGIS's git repo, > http://anonscm.debian.org/cgit/pkg-grass/grass.git/ > > (with the notable addition of a debian/ dir) > > generally for this I think it is better for one person to drive the car > at a time, so I let Frankie do the tarball swap-out part and then do > any of my extra edits to the debain/ dir once the foundation is in > solidly place. > > Others are threatening to commit over the top of our work on alioth > right now and I'd rather pull in their patches than have to revert > them, so we should perhaps get onto this soon... :-) > > @Frankie, a dependency on libgdal-dev (>= 1.10.0-0~) snuck into the > control file recently, can we just remove the versioning? AFAIK it's > not actually needed and it makes backports to wheezy and the ubuntu > LTSs that much more of a pain. Also if there isn't a hard API reason > for needing the new version, explicitly stating it there can be > deceptive since it indicates that there is. (even friendlier for > backports: "libgdal-dev | libgdal1-dev,") > Those changes can be easily added to allow easy backports. > > > Anything we can do to help ? > > The highly time critical thing right now is to get the new package in > ubuntugis's unstable repo in the next few days so the osgeo live dvd > can ship the right version for the Portland OR FOSS4G conference. We > need to send the final to the printers soon. If it comes down to it, I > can manually override with my self-built packages but I worry that the > qgis 2.4 grass-plugin package would then need to be rebuilt too. So it's > better to do it in the common ubuntugis PPA where those things will > automatically resolve themselves. In general I feel it better to > let the changes flow downstream from debian/unstable instead of letting > things get the order of progression get mixed up downstream and all the > splintering confusion and lost edits that go along with that, but the > timing might necessitate an exception to that.. > Seb has a package, to avoid stepping on toes I think that might be the > first upload to ubuntugis's PPA. > I just have a very short personal time window to complete the grass upgrade, else that and other things willbe done in the second half of August. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Mon, Nov 29, 2010 at 10:20:52PM +, Glynn Clements wrote: > > Francesco P. Lovergine wrote: > > > As said in another mail of mine, it is not a problem brute-splitting GUI > > dependencies (e.g. current squeeze release for 6.4 only *suggests* > > wxpython dependencies). Moving GUI-related binaries in different > > packages is a pain to maintain, but theoretically it can also be done. > > > > It remains a brute hack anyway, which is a symptom of > > a fundamental design problem: the whole system is theoretically > > layered and modular, but in fact it cannot be really componentized > > in a *clean* way. Something I find basically disturbing and not > > elegant, sorry my purism. > > You are really going to have to explain what you are talking about, > otherwise I (and possibly others) are going to conclude that you don't > have a clue and should just be ignored. > > GRASS' structure is about as layered and modular as you can get. If > you install it on a system without GUI libraries, the only portions > which won't work are those which inherently cannot function without > those libraries (i.e. the GUI, digitiser, XDRIVER). > Something like: make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui would be more modular and clean. Of course, one can always now install the whole beast, use only what is of interest and avoid installing all dependencies. As said, it works too. But I - as packager - would prefer avoiding tons of silly reports about 'command X is not working because Y is missing' and installing most required dependencies for all commands provided. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Sun, Nov 28, 2010 at 09:29:28PM +, Glynn Clements wrote: > > Hamish wrote: > > > > > If the only available packages (RPM, .deb, etc) insist > > > > upon installing GUI libraries, complain to the people who > > > > make the packages. > > > > Paolo: > > > OK, so, now I'm complaining ;) : packagers, please have > > > your saying here. > > > > disk space is very cheap. package maintaining time is not. IMHO > > unused libraries & a couple extra packages do no real harm > > It isn't "a couple". Once you link against wx, you're looking at ~60 > extra libraries. > > I'd suggest that the core GRASS package shouldn't list X, wxWidgets or > (in 6.x) Python as dependencies. > > It shouldn't be necessary to split the actual GRASS distribution into > GUI and non-GUI components. Put everything in the non-GUI package, and > have a separate GUI package which is empty (or contains a single dummy > file if the packaging system doesn't allow empty packages) and exists > solely to hold the GUI-specific dependencies. > As said in another mail of mine, it is not a problem brute-splitting GUI dependencies (e.g. current squeeze release for 6.4 only *suggests* wxpython dependencies). Moving GUI-related binaries in different packages is a pain to maintain, but theoretically it can also be done. It remains a brute hack anyway, which is a symptom of a fundamental design problem: the whole system is theoretically layered and modular, but in fact it cannot be really componentized in a *clean* way. Something I find basically disturbing and not elegant, sorry my purism. BTW, I tend to disagree about considering GUI maintainance not influent in the releasing cycle. It *is* influent and caused many of the past/present windows/macos delays. Having a sort of grass-toolbox and grass-gui sub-projects could help a lot (like CNES does with OTB and Monteverdi). And like it or not, there are people that do not use the default GUI or a GUI at all. Splitting would gain consensus about the core, which is IMVHO the true value of GRASS. Of course, my 2 cents, as always. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Sat, Nov 27, 2010 at 11:43:02AM +0100, Martin Landa wrote: > Hi, > > 2010/11/27 Markus Neteler : > > On Sat, Nov 27, 2010 at 6:51 AM, Paolo Cavallini > > wrote: > >> E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS > >> can be used > >> for WPS? > > > > Likely not, but --without-wxwidgets should help. > > it will just disable wxGUI digitizer (wxNviz has been rewritten to python). > > We could add new flag --without-gui which would disable compiling (and > installing selected components). > > martin > That would be the very first step, indeed. Of course IMHO a full solution would imply also: - having a componentized GUI which could be added to the core without rebuilding the whole beast (possibly componentizing 2d/3d would be also a good idea). - decoupling gui/core releases: my impression is that the core could evolve much fastly than the gui. That's based on counting the current number of GUI related bugs in comparison with core ones. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Sat, Nov 20, 2010 at 10:49:05PM +0100, Martin Landa wrote: > Hi, > > 2010/11/20 Paolo Cavallini : > > > 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? > > well, my option is very subjective - wxGUI is going to be a solid GUI > for GRASS. Anyone can build it's own GRASS distribution without any > GUI (libraries and subset of the GRASS modules). But it's not task for > the core GRASS developers. They are creating solid environment --- > GRASS libraries + modules (CLI) and also the GUI. Feel free to take > what you what from this composition. > > Martin > What Paolo is probably trying (also?) to say is that GUIs and core could have completely different release cycles. The GUI should be a component like any other, to be released when ready, but that should not become a permanent blocker of the release process, like did happen in the 6.4 release. Many people (like me and many other) use Grass as a scripting language and are completely uninterested in having a stable GUI at all, but are interested in having a working stable core in reasonable times. Of course, IMHO applies. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] buffer horribly slow?
On Mon, Oct 12, 2009 at 07:59:09PM +0200, Helmut Kudrnovsky wrote: > hi paolo, > > >Hi all. > >v.buffer input=fiumi at paolo type=line layer=1 distance=5000 > >output=fiumi_buf > >takes *ages* to process. You can find the location, with only the vector > >fiumi at: > >http://int.faunalia.it/~paolo/sample.tar.gz . Tested on debian testing > >(6.4.0~rc5-3). > >All the best. > > tested on self compiled Grass64svn (rev39464) on WinVista > Paolo, I would check against current sid version which is r39438. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass/wx 6.4 problems on Debian sid.
On Thu, Oct 08, 2009 at 02:13:46AM +0100, Glynn Clements wrote: > > Yep, indeed it works with current testing swig. And it also fixes the > > problem > > issued for 3d view by other users. As said, it would be a good idea adding > > known working swig stuff to the source tarball, as gdal does. It is almost > > impossible having the same swig version installed on all systems and swig > > is a know source of problems... > > The other option is to abandon SWIG in favour of Python's ctypes > module. This is more work, but it's also more flexible, and will > produce a better result in the end. > > It may even be possible to automate the wrapper generation. While this > won't be perfect, neither is SWIG; any automatic approach has the > problem that a C prototype doesn't contain enough information. > I opened a ticket #782 about that, just to leave trace of the problem. BTW, the wrapper generation _is_ automated by means of swig currently: that's exactly the problem here :) -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass/wx 6.4 problems on Debian sid.
On Wed, Oct 07, 2009 at 03:46:40PM +0200, Martin Landa wrote: > Hi, > > 2009/10/7 Francesco P. Lovergine : > > [...] > > > swig 1.3.39 instead of 1.3.36 > > wxpython 2.8.7 instead of 2.8.10 > > > > I suspect the main problem is swig, due to past experiences. What are > > the reference versions suggested currently? I would suggest to > > distribute swig generated stuff by default and allowing re-building > > on demand. That solved various swig-related problems in the past. > > yes, downgrade to swig 1.3.36 helps. I hope to have more time to dig > into the problem. > > Martin > Yep, indeed it works with current testing swig. And it also fixes the problem issued for 3d view by other users. As said, it would be a good idea adding known working swig stuff to the source tarball, as gdal does. It is almost impossible having the same swig version installed on all systems and swig is a know source of problems... -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass/wx 6.4 problems on Debian sid.
The wxpython interface is still seriously unusable in grass RC5 on unstable. I found the same result using current 6.4.0 branch r39426. Trying to edit any vector files this is the result: Traceback (most recent call last): File "/usr/lib/grass64/etc/wxpython/gui_modules/vdigit.py", line 233, in __init__ mapwindow) File "/usr/lib/grass64/etc/wxpython/vdigit/grass6_wxvdigit.py", line 334, in __init__ this = _grass6_wxvdigit.new_Digit(*args) TypeError: in method 'new_Digit', argument 2 of type 'wxWindow *' Currently there are at least a couple of differences among sid and e.g. Ubuntu karamic (where it seems working): swig 1.3.39 instead of 1.3.36 wxpython 2.8.7 instead of 2.8.10 I suspect the main problem is swig, due to past experiences. What are the reference versions suggested currently? I would suggest to distribute swig generated stuff by default and allowing re-building on demand. That solved various swig-related problems in the past. I'm doing some other trials to discover if my guess is true. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RFC: providing parameters to a new i.ortho module
Hi folks while working to a Rational Functions Model implementation for grass I wondered if the most a-la-grass approach to pass a long list of per-image parameters (about 90 floating coefficients) is adding a suitable 'RPC' text file in a group. That file should be created by parsing per-sensor meta files generally distributed along with level 1 images by vendors (or eventually generating it by GCPs). -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0RC5 tagging
On Tue, Jun 09, 2009 at 09:51:10AM -0700, Hamish wrote: > > ps- how to symlink grass64.1 man page to grass.1 as is done for the main > startup script? > I'm going to use the alternatives mechanism to complete the what-ever-version-you-wish support. As is the symlink use still would prevent packaging and supporting a grass65 or grass70 version for personal/group use along with the 'official' packaged version. To do that, I will move 'grass' package into 'grass64' and provide a grass migration package and a couple of alternatives for the binary and the manpage. In the meantime the binary link is provided in debian/grass.links, you could add an additional link for that. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Nearest neighbour
I noted that both r.proj/r.proj.seg use floor() in the NN method (at least in 6.4). Should not be a proper rounding to the nearest integer more appropriate? -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [DebianGIS] is this license GPL2 compatible?
On Wed, Sep 24, 2008 at 08:17:00PM +1200, Hamish wrote: > [sorry for the cross-posting, I'm casting the idea net wide] > > is this license GPL2 compatible? > is this license DFSG compatible? * > No to both. > "There is no warranty whatsoever. Use at your own risk. > > This code may be freely redistributed under the condition that the copyright > notices are not removed. You may distribute modified versions of this code > UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT IN THE > SAME FILE REMAIN UNDER COPYRIGHT OF FOOCORP, BOTH SOURCE AND OBJECT CODE ARE > MADE FREELY AVAILABLE WITHOUT CHARGE, AND CLEAR NOTICE IS GIVEN OF THE > MODIFICATIONS." > > > the bit I am concerned about is the effect of "all your modifications are > copyright us". (which is fine with me, but is it fine with the GPL?) > GPL does not deal with the copyright ownership. Indeed some companies/foundations require that the owner of the code yields ownership to them in order to include contribution, but that is not enforced in the license per se. See for instance how many MySql patches are maintained off mainstream due to that: developers of those patches are not inclined to assign copyright to MySQL AB, that does not imply they cannot distribute autonomously their derivative work. > I seem to recall seeing something very similar in the past, is this a known > standard BSD/MIT/X variant? > No, the old BSD clause was about _citation_ of the copyright older in derivative/including works. I seriously doubt that could even be considered for non-free due to limitation on distribution. -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [grass-code I][566] g.rename fails to rename maps
On Fri, Dec 21, 2007 at 04:30:35PM +0100, Moritz Lennert wrote: > > where strcmp was replaced with G_strcasecmp, thus making the compare > case independent. So, the line should not be removed, but it should > either be reverted to strcmp, or we need G_strcmp, which doesn't exist > at this stage AFAICT. > Just curious, what's the point in having wrappers for two POSIX functions like them? -- Francesco P. Lovergine ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
