[GRASS-dev] d.rast.multi ?
I am dealing with hourly Microwave data that are not covering the whole World in each layer. To have a decent presentation map of the data, I'd like to get a set (say 30-50 layers) displayed in one go. OK I could do it with the png driver in a script (which is what it may eventually become), but for the sake of knowledge, is there a GUI option to load a (rather large) set of images in one block without having to struggle with a cluttered GIS Manager? Thanks Yann -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.rast.multi ?
OK found Ctrl+Shift+L in wxGUI Thanks ! Yann On 19 March 2013 13:56, Yann Chemin yann.che...@gmail.com wrote: I am dealing with hourly Microwave data that are not covering the whole World in each layer. To have a decent presentation map of the data, I'd like to get a set (say 30-50 layers) displayed in one go. OK I could do it with the png driver in a script (which is what it may eventually become), but for the sake of knowledge, is there a GUI option to load a (rather large) set of images in one block without having to struggle with a cluttered GIS Manager? Thanks Yann -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.rast.multi ?
On 19 March 2013 09:31, Yann Chemin yann.che...@gmail.com wrote: OK found Ctrl+Shift+L in wxGUI Yes, it is my favorite feature. I use it even to find and add one map. However, there is some issue with many layers in layer manager. If you load more than 20 (?) layers (maps) only some of them will be rendered. There were no investigations; maybe it applies only to vectors. And, of course, it is slow. Thanks ! Yann On 19 March 2013 13:56, Yann Chemin yann.che...@gmail.com wrote: I am dealing with hourly Microwave data that are not covering the whole World in each layer. To have a decent presentation map of the data, I'd like to get a set (say 30-50 layers) displayed in one go. OK I could do it with the png driver in a script (which is what it may eventually become), but for the sake of knowledge, is there a GUI option to load a (rather large) set of images in one block without having to struggle with a cluttered GIS Manager? Thanks Yann -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
On 18/03/13 23:04, Markus Neteler wrote: On Fri, Jan 11, 2013 at 9:53 AM, Rainer M Krugr.m.k...@gmail.com wrote: ... Following the discussion, I would like to install GRASS 7 weekly snapshot. I relized the Binary link (http://grass.osgeo.org/download/software/) but it points back to the Linux Download page, but I could not find any binaries there for GRASS 7? Maybe this link should be removed? Just wondering, but not a problem, as I am going to install from source anyway. In the past days I have cleaned up several of the Web pages. I hope they are much clearer now. GRASS 7 downloads are now properly mentioned as well. Much clearer now ! I would like to take this debate as an opportunity to touch upon the question of a possible tech-preview release of GRASS7. Several reasons for that: - More and more people are using it (and we are pushing more and more people toward using it). Binaries are available for windows and mac, but not for most Linux distributions. A preview release might make it easier for these distributions to package grass7 and make it available to a larger audience. - In many institutions it is (understandably) not easy to convince IT-managers to install development snapshots instead of released software. Having an official release (even if it is only a tech-preview release) should make it easier to install grass7 in institutional settings. - I think that grass7 is in a form where we can start advertising it more widely and more officially. In terms of timing, it would be great to be able to get this out before FOSS4G. - From my own egotistical viewpoint, I would love to be able to use grass7 in my classes next school year, and having a release would make it much easier for me to do that. Concretely, I see the following type of procedure to make it possible: - Freeze the svn repository for any direct new commits for a short period (I'd say max 1-2 weeks). Only a few release managers should still have direct commit access at this point. (Another way to do it would be to keep commit rights open to anyone, and the role of the release managers would be to control all commits and revert those that aren't simple bug fixes during the freeze). - Publish the state of the code at the beginning of the freeze as RC1 with a wide call for testing. - Only bug fix* commits. - Publish RC2 after some bug fixing (possibly after one week). - Continue bug fixing*. - Release tech-preview (possibly at the end of week 2) with a huge disclaimer that this is a tech-preview release and not considered final and stable. - Open repository again for more general development. I don't think we should create a release branch as this would just be a tech-preview snaphot of the ongoing development. This obviously implies that we plan ahead and that all developers know when this freeze will happen, thus avoiding to commit any large and fundamental changes just before the freeze. And that we all put aside time during that freeze for testing and bug fixing. What do you think ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] minimal wxPython version
Hi all, I would like to change minimal required version of wxPython [1]. Currently we support (theoretically) version 2.8.1.1 (released 2007). I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited by this requirement. Even the 2.8.10.1 version is pretty old so I think this won't hurt anybody. Any objections? [1] http://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html PS - There is a similar problem with Python version (required 2.4). Some interesting features start with 2.5 but usually we can live without it. Any opinions? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1759: Selecting maps in dropdown menu: slider to move up/down maps does not work
#1759: Selecting maps in dropdown menu: slider to move up/down maps does not
work
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: major | Milestone: 6.4.3
Component: wxGUI | Version: svn-trunk
Resolution: |Keywords: map selection
Platform: Linux | Cpu: x86-64
-+--
Changes (by isaacullah):
* status: closed = reopened
* resolution: wontfix =
Comment:
I know this is marked as closed, but I do want to just chime in to say
that this a problem on ANY linux windowing system using overlay
scrollbars. That includes both Unity and Xfce, and perhaps several others.
Thus, anyone trying to use GRASS on these systems is going to run intot
this problem, and it is a BIG problem, as it renders GRASS basically
unuseable. This may be related to other, more deeper problems with GRASS
menus, but since there is such an easy, very non-invasive way to fix this
for most by adding the line:
{{{
export LIBOVERLAY_SCROLLBAR=0
}}}
to the grass startup script, why not just do that by default?
~Isaac
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1759#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] minimal wxPython version
Ciao Anna, On Tue, Mar 19, 2013 at 2:39 PM, Anna Kratochvílová kratocha...@gmail.comwrote: Hi all, I would like to change minimal required version of wxPython [1]. Currently we support (theoretically) version 2.8.1.1 (released 2007). I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was shipped with Ubuntu 10.04 LTS. Same for debian stable. From my point of view it's pretty safe to switch version as you suggest. The reason is obvious: wxGUI is limited by this requirement. Even the 2.8.10.1 version is pretty old so I think this won't hurt anybody. Any objections? [1] http://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html PS - There is a similar problem with Python version (required 2.4). Some interesting features start with 2.5 but usually we can live without it. Any opinions? Personally I don't know anyone still using 2.4. Thank you -- Best regards, Margherita DI LEO Postdoctoral Researcher European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] minimal wxPython version
Hi Anna, 2013/3/19 Anna Kratochvílová kratocha...@gmail.com: I would like to change minimal required version of wxPython [1]. Currently we support (theoretically) version 2.8.1.1 (released 2007). I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited by this requirement. Even the 2.8.10.1 version is pretty old so I think this won't hurt anybody. Any objections? [1] http://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html no objections. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
I think this is a good idea. At the moment, GRASS 7 seems stable and everything or almost everything is working for Mac. There are a few issues, but not major ones. One thing I remember is a problem with the display of north arrows. Volume display is still unstable, but that is a problem with both ver. 6 and 7. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Mar 19, 2013, at 2:25 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 18/03/13 23:04, Markus Neteler wrote: On Fri, Jan 11, 2013 at 9:53 AM, Rainer M Krugr.m.k...@gmail.com wrote: ... Following the discussion, I would like to install GRASS 7 weekly snapshot. I relized the Binary link (http://grass.osgeo.org/download/software/) but it points back to the Linux Download page, but I could not find any binaries there for GRASS 7? Maybe this link should be removed? Just wondering, but not a problem, as I am going to install from source anyway. In the past days I have cleaned up several of the Web pages. I hope they are much clearer now. GRASS 7 downloads are now properly mentioned as well. Much clearer now ! I would like to take this debate as an opportunity to touch upon the question of a possible tech-preview release of GRASS7. Several reasons for that: - More and more people are using it (and we are pushing more and more people toward using it). Binaries are available for windows and mac, but not for most Linux distributions. A preview release might make it easier for these distributions to package grass7 and make it available to a larger audience. - In many institutions it is (understandably) not easy to convince IT-managers to install development snapshots instead of released software. Having an official release (even if it is only a tech-preview release) should make it easier to install grass7 in institutional settings. - I think that grass7 is in a form where we can start advertising it more widely and more officially. In terms of timing, it would be great to be able to get this out before FOSS4G. - From my own egotistical viewpoint, I would love to be able to use grass7 in my classes next school year, and having a release would make it much easier for me to do that. Concretely, I see the following type of procedure to make it possible: - Freeze the svn repository for any direct new commits for a short period (I'd say max 1-2 weeks). Only a few release managers should still have direct commit access at this point. (Another way to do it would be to keep commit rights open to anyone, and the role of the release managers would be to control all commits and revert those that aren't simple bug fixes during the freeze). - Publish the state of the code at the beginning of the freeze as RC1 with a wide call for testing. - Only bug fix* commits. - Publish RC2 after some bug fixing (possibly after one week). - Continue bug fixing*. - Release tech-preview (possibly at the end of week 2) with a huge disclaimer that this is a tech-preview release and not considered final and stable. - Open repository again for more general development. I don't think we should create a release branch as this would just be a tech-preview snaphot of the ongoing development. This obviously implies that we plan ahead and that all developers know when this freeze will happen, thus avoiding to commit any large and fundamental changes just before the freeze. And that we all put aside time during that freeze for testing and bug fixing. What do you think ? Moritz ___ grass-psc mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] minimal wxPython version
On Tue, Mar 19, 2013 at 02:39:33PM +0100, Anna Kratochvílová wrote: Hi all, I would like to change minimal required version of wxPython [1]. Currently we support (theoretically) version 2.8.1.1 (released 2007). I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited by this requirement. Even the 2.8.10.1 version is pretty old so I think this won't hurt anybody. Any objections? epel 5 (add-on repository for rhel 5, the oldest still maintained rhel distribution) has 2.8.12. I am not sure that more conservative repositories have this version, but at least it is available in one repository with a sufficiently high version. -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] minimal wxPython version
I think that this is a good idea for GRASS 7. We shouldn't really do it with GRASS 6. I like going to at least Python 2.5 also. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Mar 19, 2013, at 10:58 AM, grass-user-requ...@lists.osgeo.orgmailto:grass-user-requ...@lists.osgeo.org wrote: From: Anna Kratochvílová kratocha...@gmail.commailto:kratocha...@gmail.com Subject: [GRASS-user] minimal wxPython version Date: March 19, 2013 6:39:33 AM MST To: GRASS-dev grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org, GRASS user list grass-u...@lists.osgeo.orgmailto:grass-u...@lists.osgeo.org Hi all, I would like to change minimal required version of wxPython [1]. Currently we support (theoretically) version 2.8.1.1 (released 2007). I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited by this requirement. Even the 2.8.10.1 version is pretty old so I think this won't hurt anybody. Any objections? [1] http://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html PS - There is a similar problem with Python version (required 2.4). Some interesting features start with 2.5 but usually we can live without it. Any opinions? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
I like the idea of a tech-preview release of GRASS7! I think that no more (or at least not many) major changes will go into GRASS 7, apart from the wxGUI code base. Therefore it would IMHO be very beneficial to get more feedback on GRASS 7 in order to detect and fix remaining bugs. I also like your proposed release schedule of max 1-2 weeks. Markus M On Tue, Mar 19, 2013 at 10:25 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 18/03/13 23:04, Markus Neteler wrote: On Fri, Jan 11, 2013 at 9:53 AM, Rainer M Krugr.m.k...@gmail.com wrote: ... Following the discussion, I would like to install GRASS 7 weekly snapshot. I relized the Binary link (http://grass.osgeo.org/download/software/) but it points back to the Linux Download page, but I could not find any binaries there for GRASS 7? Maybe this link should be removed? Just wondering, but not a problem, as I am going to install from source anyway. In the past days I have cleaned up several of the Web pages. I hope they are much clearer now. GRASS 7 downloads are now properly mentioned as well. Much clearer now ! I would like to take this debate as an opportunity to touch upon the question of a possible tech-preview release of GRASS7. Several reasons for that: - More and more people are using it (and we are pushing more and more people toward using it). Binaries are available for windows and mac, but not for most Linux distributions. A preview release might make it easier for these distributions to package grass7 and make it available to a larger audience. - In many institutions it is (understandably) not easy to convince IT-managers to install development snapshots instead of released software. Having an official release (even if it is only a tech-preview release) should make it easier to install grass7 in institutional settings. - I think that grass7 is in a form where we can start advertising it more widely and more officially. In terms of timing, it would be great to be able to get this out before FOSS4G. - From my own egotistical viewpoint, I would love to be able to use grass7 in my classes next school year, and having a release would make it much easier for me to do that. Concretely, I see the following type of procedure to make it possible: - Freeze the svn repository for any direct new commits for a short period (I'd say max 1-2 weeks). Only a few release managers should still have direct commit access at this point. (Another way to do it would be to keep commit rights open to anyone, and the role of the release managers would be to control all commits and revert those that aren't simple bug fixes during the freeze). - Publish the state of the code at the beginning of the freeze as RC1 with a wide call for testing. - Only bug fix* commits. - Publish RC2 after some bug fixing (possibly after one week). - Continue bug fixing*. - Release tech-preview (possibly at the end of week 2) with a huge disclaimer that this is a tech-preview release and not considered final and stable. - Open repository again for more general development. I don't think we should create a release branch as this would just be a tech-preview snaphot of the ongoing development. This obviously implies that we plan ahead and that all developers know when this freeze will happen, thus avoiding to commit any large and fundamental changes just before the freeze. And that we all put aside time during that freeze for testing and bug fixing. What do you think ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] minimal wxPython version
On Tue, Mar 19, 2013 at 6:24 PM, Patrice Dumas pertu...@free.fr wrote: On Tue, Mar 19, 2013 at 02:39:33PM +0100, Anna Kratochvílová wrote: Hi all, I would like to change minimal required version of wxPython [1]. Currently we support (theoretically) version 2.8.1.1 (released 2007). I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited by this requirement. Even the 2.8.10.1 version is pretty old so I think this won't hurt anybody. Any objections? epel 5 (add-on repository for rhel 5, the oldest still maintained rhel distribution) has 2.8.12. I am not sure that more conservative repositories have this version, but at least it is available in one repository with a sufficiently high version. Another old but still maintained repository, ports for FreeBSD 8.3, has python 2.7 and wxpython 2.8.12. No objections. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
On Tue, Mar 19, 2013 at 7:55 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: I like the idea of a tech-preview release of GRASS7! Me, too. I think that no more (or at least not many) major changes will go into GRASS 7, apart from the wxGUI code base. We should also remember that this will go towards 7.0 and then a nice 7.1 and so forth are expecting us. (At the FOSS4G Lausanne 2006 we even had a GRASS 8 (grassotto, Italian word joke) logo :-) - maybe I can get the file from Alessandro Frigeri who draw it.) Therefore it would IMHO be very beneficial to get more feedback on GRASS 7 in order to detect and fix remaining bugs. I also like your proposed release schedule of max 1-2 weeks. If you accept me to manage the release and related stuff, I am happy to prepare things as needed with your help. markusN PS: Who cannot resist: http://trac.osgeo.org/grass/query?status=assignedstatus=newstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalcol=idcol=summarycol=milestonecol=prioritycol=statuscol=ownercol=componentmilestone=7.0.0 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
The 2 biggest issues I've run into teaching with GRASS 7 has been 1) the difficulty of getting a Linux version and 2) the common 'missing dll' problem for Windows. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Mar 19, 2013, at 12:57 PM, Markus Neteler nete...@osgeo.org wrote: On Tue, Mar 19, 2013 at 7:55 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: I like the idea of a tech-preview release of GRASS7! Me, too. I think that no more (or at least not many) major changes will go into GRASS 7, apart from the wxGUI code base. We should also remember that this will go towards 7.0 and then a nice 7.1 and so forth are expecting us. (At the FOSS4G Lausanne 2006 we even had a GRASS 8 (grassotto, Italian word joke) logo :-) - maybe I can get the file from Alessandro Frigeri who draw it.) Therefore it would IMHO be very beneficial to get more feedback on GRASS 7 in order to detect and fix remaining bugs. I also like your proposed release schedule of max 1-2 weeks. If you accept me to manage the release and related stuff, I am happy to prepare things as needed with your help. markusN PS: Who cannot resist: http://trac.osgeo.org/grass/query?status=assignedstatus=newstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalcol=idcol=summarycol=milestonecol=prioritycol=statuscol=ownercol=componentmilestone=7.0.0 ___ grass-psc mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] KR functions in GRASS 7
Hi, we still have KR style functions in C code? They work the same but I though that they were rewritten. Doxygen warns about this in these files: /home/vasek/dev/grass/trunk/lib/raster3d/volume.c /home/vasek/dev/grass/trunk/lib/external/shapelib/dbfopen.c /home/vasek/dev/grass/trunk/lib/external/shapelib/shpopen.c /home/vasek/dev/grass/trunk/lib/db/sqlp/sqlp.tab.c In some files KR style is in #ifs but in others KR is the only style. I just want to make it public. Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
It seems to be a good idea. However, i have to apply the 3D raster patch[1] then as soon as possible to get the voxel stuff working with large data. But this will bring the risk of losing backward compatibility . Please exclude the temporal GIS stuff in the tech-preview 7.0 release, since so many manual pages are still missing. Best Soeren [1] http://trac.osgeo.org/grass/ticket/1752 2013/3/19 Markus Neteler nete...@osgeo.org: On Tue, Mar 19, 2013 at 7:55 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: I like the idea of a tech-preview release of GRASS7! Me, too. I think that no more (or at least not many) major changes will go into GRASS 7, apart from the wxGUI code base. We should also remember that this will go towards 7.0 and then a nice 7.1 and so forth are expecting us. (At the FOSS4G Lausanne 2006 we even had a GRASS 8 (grassotto, Italian word joke) logo :-) - maybe I can get the file from Alessandro Frigeri who draw it.) Therefore it would IMHO be very beneficial to get more feedback on GRASS 7 in order to detect and fix remaining bugs. I also like your proposed release schedule of max 1-2 weeks. If you accept me to manage the release and related stuff, I am happy to prepare things as needed with your help. markusN PS: Who cannot resist: http://trac.osgeo.org/grass/query?status=assignedstatus=newstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalcol=idcol=summarycol=milestonecol=prioritycol=statuscol=ownercol=componentmilestone=7.0.0 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
Hi, 2013/3/19 Sören Gebbert soerengebb...@googlemail.com: It seems to be a good idea. However, i have to apply the 3D raster patch[1] then as soon as possible to get the voxel stuff working with large data. But this will bring the risk of losing backward compatibility . this will happen time by time... We have two options: 1) start releasing tech-previews later 2) start releasing tech-previews earlier with risk of breaking whatever you can imagine Please exclude the temporal GIS stuff in the tech-preview 7.0 release, since so many manual pages are still missing. Hm, there will be more unstable or non-documented areas in GRASS 7. Excluding them from tech-previewes will be extra work for packagers and the benefit will be debatable. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Programming manual updated
Hi, recently programming manual for vector library was updated. The main addition is FAQ page [1]. Questions were answered by MarkusM. Thank you Markus. I hope that more questions will be added and answered in the future. The smaller changes includes removing of last Doxygen entries from dglib and rtree directories which were considered as confusing and not helpful because they are not part of the GRASS API. The number of Doxygen warnings was reduced by a small clean up. Feel free to continue. There are many warnings which can be fixed easily if you know the code or documentation. The reduced number of warnings will help to catch the new ones. However, contributing the documentation itself is even more welcome. Sometimes, Doxygen can be complex. If you are unsure with Doxygen syntax or rearing Doxygen warnings feel free to contact me on mailing list or personally. I will try to help. Thanks also MarkusN for managing programming manual on the sever. Vaclav [1] http://grass.osgeo.org/programming7/vlibFAQ.html [2] r55439 - r55460 You can generate documentation yourself and save the error messages to a file: PATH=/home/vasek/app/doxygen-svn/bin/:$PATH make htmldox-single stddox.log 2 errordox.log I usually filter some warnings not related to my files or so: grep -v are not documented errordox.log | grep -v ^ parameter '.*'$ | grep -v is not found in the argument list | grep -v tag Layer found |grep -v Found unknown command .*mapset | grep -v Found unknown command .*PERMANENT errordox-filtered.log ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
2013/3/19 Markus Metz markus.metz.gisw...@gmail.com: I like the idea of a tech-preview release of GRASS7! +1 I think that no more (or at least not many) major changes will go into GRASS 7, apart from the wxGUI code base. Therefore it would IMHO be very beneficial to get more feedback on GRASS 7 in order to detect and fix remaining bugs. Also in pygrass there is some work to do yet Markus M -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] KR functions in GRASS 7
On Tue, Mar 19, 2013 at 9:31 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi, we still have KR style functions in C code? Officially no. We made the migration to ANSI C in 2002 or so (would have to look it up). They work the same but I though that they were rewritten. Doxygen warns about this in these files: /home/vasek/dev/grass/trunk/lib/raster3d/volume.c /home/vasek/dev/grass/trunk/lib/db/sqlp/sqlp.tab.c - should probably be changed. /home/vasek/dev/grass/trunk/lib/external/shapelib/dbfopen.c /home/vasek/dev/grass/trunk/lib/external/shapelib/shpopen.c - are external files from Frank Warmerdam. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
On Tue, Mar 19, 2013 at 9:32 PM, Sören Gebbert soerengebb...@googlemail.com wrote: Please exclude the temporal GIS stuff in the tech-preview 7.0 release, since so many manual pages are still missing. This reason is too weak :) I think that excluding it is way more work that writing draft manual pages. I can assist with that (we can discuss offlist). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.rast.multi ?
Yann, If I have a large number of layers, I usually do it from a command line or with a script. I done r.patch with over 100 layers in one command ( before I discovered gdalbuildvirt :-)) Doug On Tue, Mar 19, 2013 at 4:36 AM, Vaclav Petras wenzesl...@gmail.com wrote: On 19 March 2013 09:31, Yann Chemin yann.che...@gmail.com wrote: OK found Ctrl+Shift+L in wxGUI Yes, it is my favorite feature. I use it even to find and add one map. However, there is some issue with many layers in layer manager. If you load more than 20 (?) layers (maps) only some of them will be rendered. There were no investigations; maybe it applies only to vectors. And, of course, it is slow. Thanks ! Yann On 19 March 2013 13:56, Yann Chemin yann.che...@gmail.com wrote: I am dealing with hourly Microwave data that are not covering the whole World in each layer. To have a decent presentation map of the data, I'd like to get a set (say 30-50 layers) displayed in one go. OK I could do it with the png driver in a script (which is what it may eventually become), but for the sake of knowledge, is there a GUI option to load a (rather large) set of images in one block without having to struggle with a cluttered GIS Manager? Thanks Yann -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]
Hi, 2013/3/19 Sören Gebbert soerengebb...@googlemail.com: It seems to be a good idea. However, i have to apply the 3D raster patch[1] then as soon as possible to get the voxel stuff working with large data. But this will bring the risk of losing backward compatibility . Patch that removes the buggy LRE compression has been applied to trunk #55462. Tests for 3D raster modules and the library passed successfully. The patch should assure backward compatibility. I hope i did not break anything. :) Best regards Soeren Please exclude the temporal GIS stuff in the tech-preview 7.0 release, since so many manual pages are still missing. Best Soeren [1] http://trac.osgeo.org/grass/ticket/1752 2013/3/19 Markus Neteler nete...@osgeo.org: On Tue, Mar 19, 2013 at 7:55 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: I like the idea of a tech-preview release of GRASS7! Me, too. I think that no more (or at least not many) major changes will go into GRASS 7, apart from the wxGUI code base. We should also remember that this will go towards 7.0 and then a nice 7.1 and so forth are expecting us. (At the FOSS4G Lausanne 2006 we even had a GRASS 8 (grassotto, Italian word joke) logo :-) - maybe I can get the file from Alessandro Frigeri who draw it.) Therefore it would IMHO be very beneficial to get more feedback on GRASS 7 in order to detect and fix remaining bugs. I also like your proposed release schedule of max 1-2 weeks. If you accept me to manage the release and related stuff, I am happy to prepare things as needed with your help. markusN PS: Who cannot resist: http://trac.osgeo.org/grass/query?status=assignedstatus=newstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalcol=idcol=summarycol=milestonecol=prioritycol=statuscol=ownercol=componentmilestone=7.0.0 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.rast.multi ?
Thank you Doug, yes r.patch is a good alternative, but it means writing to disk etc. Was more thinking of a display memory thingy. Been thinking about the virtual rasters indeed, maybe will have a look, any C code page you could direct me to? Cheers, Yann On 20 March 2013 05:39, Newcomb, Doug doug_newc...@fws.gov wrote: Yann, If I have a large number of layers, I usually do it from a command line or with a script. I done r.patch with over 100 layers in one command ( before I discovered gdalbuildvirt :-)) Doug On Tue, Mar 19, 2013 at 4:36 AM, Vaclav Petras wenzesl...@gmail.com wrote: On 19 March 2013 09:31, Yann Chemin yann.che...@gmail.com wrote: OK found Ctrl+Shift+L in wxGUI Yes, it is my favorite feature. I use it even to find and add one map. However, there is some issue with many layers in layer manager. If you load more than 20 (?) layers (maps) only some of them will be rendered. There were no investigations; maybe it applies only to vectors. And, of course, it is slow. Thanks ! Yann On 19 March 2013 13:56, Yann Chemin yann.che...@gmail.com wrote: I am dealing with hourly Microwave data that are not covering the whole World in each layer. To have a decent presentation map of the data, I'd like to get a set (say 30-50 layers) displayed in one go. OK I could do it with the png driver in a script (which is what it may eventually become), but for the sake of knowledge, is there a GUI option to load a (rather large) set of images in one block without having to struggle with a cluttered GIS Manager? Thanks Yann -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -- Yann Chemin Researcher@IWMI Skype/FB: yann.chemin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] KR functions in GRASS 7
Vaclav Petras wrote: we still have KR style functions in C code? They work the same but I though that they were rewritten. Doxygen warns about this in these files: /home/vasek/dev/grass/trunk/lib/raster3d/volume.c Fixed in r55463. /home/vasek/dev/grass/trunk/lib/external/shapelib/dbfopen.c /home/vasek/dev/grass/trunk/lib/external/shapelib/shpopen.c I can't see any KR style declarations in these files. It's possible that the SHPAPI_CALL macro is confusing Doxygen. /home/vasek/dev/grass/trunk/lib/db/sqlp/sqlp.tab.c This isn't a source file, it's an intermediate file generated from sqlp.y using yacc or bison. FWIW, the file which bison generates uses ANSI C syntax if __STDC__ is defined (which is the case for any ANSI C compiler). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
