Re: [GRASS-dev] 6.4.4 planning
hi all, I would be able to tag RC1 tomorrow (Friday) if there are no objections. Are there any pending backports? I have some uncommitted fixes for r.pack and v.external but will not commit them to avoid another flamewar. :) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] os.environ['GRASS_REGION'] Error
Hello all, trying to create a temporary region within a python GRASS script using: os.environ['GRASS_REGION'] = grass.region_env(res=150) I get the following errors on a CentOS server: ERROR: Syntax error in cell header ERROR: Field projection missing GRASS version: GRASS 7.1.svn (2014) libgis Revision: 60707 libgis Date: 2014-06-05 00:58:35 +0200 (Thu, 05 Jun 2014) Doing it on my Ubuntu installation works fine! Any idea about what could be the problem? Thank you very much! Cheers, Javier ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] os.environ['GRASS_REGION'] Error
On Thu, Jun 5, 2014 at 10:27 AM, Javier Martínez-López javi.martinez.lo...@gmail.com wrote: Hello all, trying to create a temporary region within a python GRASS script using: os.environ['GRASS_REGION'] = grass.region_env(res=150) I get the following errors on a CentOS server: ERROR: Syntax error in cell header ERROR: Field projection missing What does g.region -p say in that location? best, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.4 planning
Hi Markus, 2014-06-05 9:56 GMT+02:00 Markus Neteler nete...@osgeo.org: I would be able to tag RC1 tomorrow (Friday) if there are no objections. Are there any pending backports? I have some uncommitted fixes for r.pack and v.external but will not commit them to avoid another flamewar. :) no objection for my side. From other project (GDAL for example) I got feeling that RC period must be short. So e.g. RC2 or final one/two weeks after RC1 Also reporting bunch of blockers during RC stage can be interpreted as attempt to block release. I hope that for GRASS 7 will defined fixed time-based release policy with freeze stage (one/two months - ideal time for reporting blockers), than simply release and go on... Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On 04/06/14 22:35, Markus Neteler wrote: On Wed, Jun 4, 2014 at 7:56 PM, Glynn Clements gl...@gclements.plus.com wrote: ... So either: 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That has the same issues as using shell=True, but at least it only applies in the case where we're executing a script. ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. I had the feeling that this was the consensus (or at least with lack of clear dissension) we had reached: http://lists.osgeo.org/pipermail/grass-dev/2014-April/068519.html Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Enhancement request: print name(s) of generated map(s) upon completion
On 02/06/14 20:15, Markus Neteler wrote: Hi, as general improvement I would like to see that each map generating GRASS command prints the name(s) of the generated maps. This is especially relevant when multiple maps can generated (e.g. r.watershed). I have today added such support in v.vol.rst but wondered if a more generic possibility exists at library level. For raster maps, this ugly hack works: Index: lib/raster/history.c === --- lib/raster/history.c (revision 60664) +++ lib/raster/history.c (working copy) @@ -162,6 +162,7 @@ G_fatal_error(_(Unable to write history information for %s), name); Rast__write_history(hist, fp); +G_done_msg(_(Raster map %s created), name); } Interestingly, it gets printed twice then: # using GRASS 7.1.svn (nc_spm_08_grass7):~ r.mapcalc result = if(landclass96 == 5, 1, null() ) 100% r.mapcalc complete. Raster map result created r.mapcalc complete. Raster map result created Likewise another example: # using GRASS 7.1.svn (nc_spm_08_grass7):~ g.region rast=elev_lid792_1m r.watershed elevation=elev_lid792_1m accumulation=elev_lid792_1m.acc2 \ basin=elev_lid792_1m.basin2 stream=elev_lid792_1m.stream2 \ tci=elev_lid792_1m.tci2 threshold=1000 SECTION 1a (of 5): Initiating Memory. SECTION 1b (of 5): Determining Offmap Flow. 100% ... SECTION 5: Closing Maps. 100% ram complete. Raster map elev_lid792_1m.stream2 created ram complete. Raster map elev_lid792_1m.basin2 created ram complete. Raster map elev_lid792_1m.acc2 created ram complete. Raster map elev_lid792_1m.tci2 created r.watershed complete. Raster map elev_lid792_1m.acc2 created r.watershed complete. Raster map elev_lid792_1m.tci2 created r.watershed complete. Raster map elev_lid792_1m.basin2 created r.watershed complete. Raster map elev_lid792_1m.stream2 created For vector maps, a similar mechanism would be ideal. Ideas? Sounds quite verbose to me. Why do we need this ? Maybe make this conditional to --verbose ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Enhancement request: print name(s) of generated map(s) upon completion
On Thu, Jun 5, 2014 at 5:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 02/06/14 20:15, Markus Neteler wrote: Hi, as general improvement I would like to see that each map generating GRASS command prints the name(s) of the generated maps. This is especially relevant when multiple maps can generated (e.g. r.watershed). ... wondered if a more generic possibility exists at library level. ... [as written, that example was *ugly*] Sounds quite verbose to me. Why do we need this ? Maybe make this conditional to --verbose ? Dunno. Example - this I got from a user: v.vol.rst -c input=utm3d@UTMfinish wcolumn=temp tension=10. cvdev=cvdevmap38 maskmap=ter@UTMfinish segmax=698 npmin=699 dmin=150.0 zmult=50.0 6283 records selected from table Processing all selected output files will require 0 bytes of disk space for temp files WARNING: Points are more dense than specified 'DMIN'--ignored 5938 points (remain 345) WARNING: 345 points given for interpolation (after thinning) is less than given NPMIN=699 WARNING: There is less than 700 points for interpolation, no segmentation is necessary, to run the program faster, set segmax=700 (see manual) bitmap mask created Percent complete: Finished interpolating Building topology for vector map cvdevmap38... Registering primitives... 334 primitives registered 334 vertices registered Building areas... 0 areas built 0 isles built Attaching islands... Attaching centroids... Number of nodes: 334 Number of primitives: 334 Number of points: 334 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 The number of points in vector map is 6283 The number of points outside of 2D/3D region 0 The number of points used (after reduction) is 345 (Sat May 31 11:09:50 2014) Command finished (26 sec) ... he told me that nothing got calculated (apparently he didn't use g.list). Indeed the information is quite buried in above output. Also r.watershed with multiple output does not say much. That's why I would see the generated map names printed out. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] os.environ['GRASS_REGION'] Error
Solved! Margherita pointed out that the original script was messing up the values of the projection because in one of the testing versions I was using integer values instead of characters for the region resolution parameter, and since then the script started giving this error, which I did not noticed. That is why it was running in one machine and not in the other one... This is the test script about parallel computing using different regions [1]. I will test it and let you know if it works with a large segmentation processing job. Thank you very much! Cheers, Javier [1] https://github.com/javimarlop/eHabpy/blob/master/pas/parallel_grass_example.py On Thu, Jun 5, 2014 at 4:46 PM, Markus Neteler nete...@osgeo.org wrote: On Thu, Jun 5, 2014 at 10:27 AM, Javier Martínez-López javi.martinez.lo...@gmail.com wrote: Hello all, trying to create a temporary region within a python GRASS script using: os.environ['GRASS_REGION'] = grass.region_env(res=150) I get the following errors on a CentOS server: ERROR: Syntax error in cell header ERROR: Field projection missing What does g.region -p say in that location? best, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] os.environ['GRASS_REGION'] Error
On Thu, Jun 5, 2014 at 12:42 PM, Javier Martínez-López javi.martinez.lo...@gmail.com wrote: Solved! Margherita pointed out that the original script was messing up the values of the projection because in one of the testing versions I was using integer values instead of characters for the region resolution parameter, and since then the script started giving this error, which I did not noticed. That is why it was running in one machine and not in the other one... This is the test script about parallel computing using different regions [1]. I will test it and let you know if it works with a large segmentation processing job. Thank you very much! Cheers, Javier [1] https://github.com/javimarlop/eHabpy/blob/master/pas/parallel_grass_example.py Hi Javier, do you know about PyGRASS GridModule [1]? Would it solve what you are doing? If you stay with your code, it might be safer for you to pass GRASS_REGION in the env parameter. I hope it works with run_command (and not only with underlying Popen [2]). You can see what I mean in the example with Popen [3]. Vaclav [1] http://grass.osgeo.org/grass71/manuals/pygrass/modules_grid.html [2] https://docs.python.org/2/library/subprocess.html#popen-constructor [3] http://trac.osgeo.org/grass/browser/sandbox/wenzeslaus/gunittest/grass_py_static_check.py?rev=60678#L65 On Thu, Jun 5, 2014 at 4:46 PM, Markus Neteler nete...@osgeo.org wrote: On Thu, Jun 5, 2014 at 10:27 AM, Javier Martínez-López javi.martinez.lo...@gmail.com wrote: Hello all, trying to create a temporary region within a python GRASS script using: os.environ['GRASS_REGION'] = grass.region_env(res=150) I get the following errors on a CentOS server: ERROR: Syntax error in cell header ERROR: Field projection missing What does g.region -p say in that location? best, Markus ___ 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] Updates of wiki page for compiling on Ubuntu
Hi, I was again revising the wiki page Compile and install Ubuntu (BTW, the name is strange, do we compile Ubuntu?). I've removed a lot of packages from the dependencies [1] since they are not need for compilation (or running) of GRASS. I don't know about others. But this is actually what I wanted to ask about. Do you this that we should change the page in the way that it will reflect the most common use case which is IMHO just compilation of GRASS but I'm not sure. Now for example, package for PROJ4 is missing and you must find out in the wiki page what to do. I suggest (slowly) change the page to the state where the compilation of GRASS only will be the primary option. This is really hard to keep this up to date since to test this, you need a fresh installation and I don't want to keep fresh Ubuntu virtual box just because of this. I actually think that there are still some packages missing in the list. Also I would like to update the ./configure command there but I don't know if to try enable some things which I have disabled. Here is my script to run ./configure: #!/bin/bash export CFLAGS=-ggdb -Wall -Werror-implicit-function-declaration -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls export CXXFLAGS=-ggdb -Wall export LDFLAGS=-s ./configure \ --enable-largefile=yes \ --with-nls \ --with-cxx \ --with-readline \ --with-pthread \ --with-openmp \ --with-proj-share=/usr/share/proj \ --with-geos=/usr/bin/geos-config \ --with-wxwidgets \ --with-cairo \ --with-opengl-libs=/usr/include/GL \ --with-ffmpeg=no --with-ffmpeg-includes=/usr/include/libavcodec /usr/include/libavformat /usr/include/libswscale /usr/include/libavutil \ --with-freetype=yes --with-freetype-includes=/usr/include/freetype2/ \ --with-postgres=yes --with-postgres-includes=/usr/include/postgresql \ --with-sqlite=yes \ --with-mysql=no \ --with-odbc=no \ --with-netcdf \ --with-liblas=yes --with-liblas-config=/usr/bin/liblas-config The things which are disabled are: BLAS, DWG, FFMPEG, LAPACK, MySQL, ODBC, OpenCL, X11. I'm fine with this. Also, I'm not installing, I'm always only compiling so I don't have a clear idea what to set for this or if to recommend it. However, I think that the right location for source and compilation is not `/usr/local/src` as suggested by wiki page but `/opt` in multiuser environment and `/home/user/` in a single user environment (or in a case of one responsible user and installation step in multiuser environment). If somebody has a some ideas what to change, please contribute. Vaclav [1] http://grasswiki.osgeo.org/w/index.php?title=Compile_and_Install_Ubuntudiff=20516oldid=20500 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Enhancement request: print name(s) of generated map(s) upon completion
On Thu, Jun 5, 2014 at 8:16 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: ... I understand the concern, but I wonder up to which point we have to hold the user's hand. The information is easily available in the man page. This is as if in R you would write out information about every single output value a function gives you. In my eyes this would be horrible. I was referring to the output maps being created, nothing else. That can be 0 to some outputs. Let's leave at least part of the responsibility for understanding how to use GRASS to the user... :-) I myself miss it a lot if that matters :-) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Enhancement request: print name(s) of generated map(s) upon completion
On Thu, Jun 5, 2014 at 2:44 PM, Markus Neteler nete...@osgeo.org wrote: On Thu, Jun 5, 2014 at 8:16 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: ... I understand the concern, but I wonder up to which point we have to hold the user's hand. The information is easily available in the man page. This is as if in R you would write out information about every single output value a function gives you. In my eyes this would be horrible. I was referring to the output maps being created, nothing else. That can be 0 to some outputs. Let's leave at least part of the responsibility for understanding how to use GRASS to the user... :-) I myself miss it a lot if that matters :-) Hm, if the message(s) would be parseable independently on the language settings (perhaps with message format set to GUI), GUI could use that information to add/re-render the layers. (Instead of current guessing based on the parameters.) Also if we will say no to the messages, we should remove them from all the modules because than users expect to see then in all modules. What you are saying about R makes sense but in case of GRASS, the modules are much more verbose (even without --verbose) than R functions (e.g. topology building), so few lines more does not make any difference IMHO. Vaclav Markus ___ 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-SVN] r60679 - grass/trunk/lib/python/script
Hi, 2014-06-05 17:36 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. I had the feeling that this was the consensus (or at least with lack of clear dissension) we had reached: consensus is somehow courageous to say, bearing in mind that Glynn simply reverts any other solution regardless that it breaks the whole GRASS on Windows (try to install 7.1, completely useless, even no answer, break is just OK). Well, someone need to implement it, even some of us are not probably happy about that, we need to take care about user scripts and so on. It's somehow funny, because 7.0 simply works (same was for 7.1 some days ago). Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.4 planning
Hi, 2014-06-05 17:47 GMT+02:00 Moritz Lennert moritz.lenn...@ulb.ac.be: [...] As I've already told Markus off-list, I think that in order for this to work we would need a clearly defined release-process with clear announcements of the different steps (pre-freeze warning sufficiently early, freeze announcement, pre-tag announcement, etc) and a strict respect of the rules during this process (i.e. no non bugfix commits during a freeze), etc. I'm not convinced that a time-based release-policy is the solution, but I think a more clearly defined release-process policy might help in avoiding frustrations. right, let's push out 6.4.4 somehow, new release policy is question for G7... Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Enhancement request: print name(s) of generated map(s) upon completion
Hi, I would like to add a +1 to Mortiz here. This enhancement should be in the verbose. Like there are debug level for message. These message can be like level in verbose. say --verbose=1 On Thu, Jun 5, 2014 at 8:44 PM, Markus Neteler nete...@osgeo.org wrote: On Thu, Jun 5, 2014 at 8:16 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: ... I understand the concern, but I wonder up to which point we have to hold the user's hand. The information is easily available in the man page. This is as if in R you would write out information about every single output value a function gives you. In my eyes this would be horrible. I was referring to the output maps being created, nothing else. That can be 0 to some outputs. Let's leave at least part of the responsibility for understanding how to use GRASS to the user... :-) I myself miss it a lot if that matters :-) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2326: Command functions in grass.script.core miss a correct error reporting
#2326: Command functions in grass.script.core miss a correct error reporting
-+--
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1.0
Component: Python | Version: svn-trunk
Keywords: script |Platform: All
Cpu: Unspecified |
-+--
There is a lot of functions in grass.core which can run a GRASS module.
One is allowing this the other that but none of them is actually providing
the convenient interface to a (the most?) common case where you not only
want stdout as a string (and perhaps stdin as a string too) but also you
want an error message to be reported in program(mer)-friendly way.
The later is actually a motivation for this ticket because I see this as a
critical issue which is very dangerous for
[https://gis.stackexchange.com/questions/99773/problems-running-grass-
mapcalc/ beginners] (writing scripts with `run_command` or others) and not
checking the return code or stderr with an expectation that the function
will report the error (in Python sense, thus raising an exception). And
this issue is valid also for advanced GRASS Python programmers/users
because there is a need to still check output of each command and report
error manually. Moreover, the current state goes against the philosophy of
C library which takes the burden of dealing with errors from the
programmer.
The fact is that you then and up with implementing your own
`start_command` wrappers. For example,
[http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/animation/provider.py#L734
animation tool] uses its own function based on `start_command` returning
return code (`int`), stdout (`str`), stderr (`str`):
{{{
#!python
def read2_command(*args, **kwargs):
kwargs['stdout'] = gcore.PIPE
kwargs['stderr'] = gcore.PIPE
ps = gcore.start_command(*args, **kwargs)
stdout, stderr = ps.communicate()
return ps.returncode, stdout, stderr
}}}
I recently used this code inside some function which gets stdin as string,
uses stdout and in case of non-zero return code throws/raises an exception
(`RuntimeError`) with error message containing module name and stderr:
{{{
#!python
proc = gcore.start_command('m.proj', input='-', separator=' , ',
flags='od',
stdin=gcore.PIPE,
stdout=gcore.PIPE,
stderr=gcore.PIPE)
proc.stdin.write(proj_in)
proc.stdin.close()
proc.stdin = None
proj_out, errors = proc.communicate()
if proc.returncode:
raise RuntimeError(m.proj error: %s % errors)
}}}
I would probably just commit the combination of the code samples above as
a new function but I want to be sure that it will be right this time. I
don't know whether my requirements are the same of the majority and
finally, I don't know what name to choose for the new function since it
seems that functions in `grass.script.core` already used every possible
name. Also, I'm not sure what is the PyGRASS's answer to this problem.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2326
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] Enhancement request: print name(s) of generated map(s) upon completion
On Thu, Jun 5, 2014 at 9:28 PM, Rashad M mohammedrasha...@gmail.com wrote: Hi, I would like to add a +1 to Mortiz here. This enhancement should be in the verbose. Like there are debug level for message. These message can be like level in verbose. say --verbose=1 I would suggest to do the opposite. Since percentage output is there, it would be helpful to - vector: put e.g. most of the many topology related messages (v.clean, v.in.ogr) into verbose, - raster: do the same for candidates like r.watershed, many messages... == But then tell the user what has been produced! The point is: if you run stuff on command line/in batch jobs, you want to know the outcome, not how many tiny interim steps have been done. Sure I can scroll back but GRASS could also simply tell me. Just my 0.02 cents (from my teaching experience with GIS experts but GRASS newbies), Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Write a test to proof that the commit works
Hi all, as you know, I'm working on a GSoC project implementing a testing framework for GRASS [1]. I'm at the beginning but I want to tell you that you can start to write test right now as I recently did for g.list [2]. If you use this as a template, you will ensure that it will be compatible with the framework I'm working on. Some projects require to have a test (test case or whatever) for each newly added feature so that it is clear that the feature works and it will be clear when it breaks (see r606618 for example). In other words, the change/commit/patch is not accepted if it is not accompanied by a test (if a test does not exists already). In the combination with tests running after each commit, this is much more powerfull then reading commits or `svn blame` because it marks the commits which should be reverted if tests fail. I don't think that we need to set up rules like this but I would like to encourage you to do it, to write the tests for your changes, especially for the commits which are changing core functionality and the test is not hard to write (the things which need to be tested are text or few numbers, not maps, for example [4]). For example to test the functionality of the parser, the simplest solution I see is to test some module which is using the parser's feature by running module with `run_command` and testing the return code using `assertEquals`. There is few other possibilities but anything will do. Please note that I'm not be able to write the actual tests for the whole GRASS, not even for significant part of it. The topic of GSoC is a framework which should provide good tools, environment settings, reports and so on. The good tools may simplify test writing and will make it more precise but nothing will save us from writing the tests for our work, our changes and the functionality we are relying on. Feel free to ask me questions here or privately about writing tests. I will try to answer as soon as possible and reflect you comments in the documentation and the code itself. Sorry for such a long email but I would like to motivate you to contribute a really long list of long tests. Vaclav [1] http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS [2] http://trac.osgeo.org/grass/browser/grass/trunk/general/g.list/test_g_list.py?rev=60619 (currently broken I guess :-) [3] http://trac.osgeo.org/grass/changeset/60618 [4] http://trac.osgeo.org/grass/changeset/60713 PS: I have some parts of the framework already in the sandbox [5] but it is unstable and for writing tests you can do the same with standard Python unittest library [6]. [5] http://trac.osgeo.org/grass/browser/sandbox/wenzeslaus/gunittest [6] https://docs.python.org/2/library/unittest.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2306: Please create an AppData file for GRASS
#2306: Please create an AppData file for GRASS -+-- Reporter: hughsient| Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 7.0.0 Component: Docs | Version: svn-trunk Keywords: AppData |Platform: Linux Cpu: All | -+-- Comment(by neteler): Added to source code in r60717 (trunk) and subsequent for GRASS 7.0.svn, 6.5.svn and 6.4.svn. Remaining issue: install it to the requested /usr/share/appdata which is (usually) left to the packager. Keeping ticket open for the case that this is not true. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2306#comment:3 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] [GRASS GIS] #2306: Please create an AppData file for GRASS
#2306: Please create an AppData file for GRASS -+-- Reporter: hughsient| Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 7.0.0 Component: Docs | Version: svn-trunk Keywords: AppData |Platform: Linux Cpu: All | -+-- Comment(by neteler): Update: I have moved the XML file to gui/icons/ alongside with grass.desktop. grass.appdata.xml will now copied at compile time into dist.$ARCH/share/appdata/ -- Ticket URL: http://trac.osgeo.org/grass/ticket/2306#comment:4 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] [GRASS-SVN] r60713 - in grass/trunk: include lib/gis
Hi, nice work! I was just trying it and I found a small error, see below On Thu, Jun 5, 2014 at 1:32 PM, svn_gr...@osgeo.org wrote: Author: hcho Date: 2014-06-05 10:32:48 -0700 (Thu, 05 Jun 2014) New Revision: 60713 Modified: grass/trunk/include/gis.h grass/trunk/lib/gis/parser.c Log: The exclusive member of the Option and Flag structures is a comma-separated string. Whitespaces are not ignored. Each name separated by comma can be used to group options/flags together, make them mutually exclusive, or make one of them conditionally required. Names starting with + tie together options/flags and names starting with * (name ignored) make them conditionally required (not always required, but if some other options/flags are not used, they become required). Other names make options/flags mutually exclusive in the same group. These three different types of grouping can be mixed. EXAMPLES 1. opt1 opt2 are mutually exclusive. opt2 opt3 are mutually exclusive. opt1-exclusive = 1; opt2-exclusive = 1,2; opt3-exclusive = 2; 2. opt1 opt2 must be used together. opt1-exclusive = +1; opt2-exclusive = +1; opt3-exclusive = ; 3. opt1 or opt2 must be used. Both can be used together. Naming ignored. opt1-exclusive = *ignored; opt2-exclusive = *; opt3-exclusive = ; 4. (opt1 opt2 together) or (opt3 opt4 together) must be used. All four can be used together. opt1-exclusive = +1,*; opt2-exclusive = +1; /* * is optional because opt2 is tied with opt1 */ opt3-exclusive = +2,*; opt4-exclusive = +2; It seems that the * is needed for both parameters (opt1 and opt2). When I have two types of inputs and one of them is required (exactly one) and I put * only to one of them (and they are in one group), I get this when I don't specify any of them in the command line: ERROR: One or more of the following options/flags must be used: or input2= instead of ERROR: One or more of the following options/flags must be used: input1= or input2= 5. Only one of (opt1 opt2 together) or (opt3 opt4 together) must be used. All four cannot be used together. opt1-exclusive = +1,*,1; opt2-exclusive = +1; /* * is optional because opt2 is tied with opt1 */ opt3-exclusive = +2,*,1; opt4-exclusive = +2; /* 1 is optional because opt4 is tied with opt3 */ Modified: grass/trunk/include/gis.h === --- grass/trunk/include/gis.h 2014-06-05 04:48:03 UTC (rev 60712) +++ grass/trunk/include/gis.h 2014-06-05 17:32:48 UTC (rev 60713) @@ -75,12 +75,12 @@ #define U_RADIANS 7 #define U_DEGREES 8 /* Temporal units from the datetime library */ -#define U_YEARS DATETIME_YEAR -#define U_MONTHSDATETIME_MONTH -#define U_DAYS DATETIME_DAY -#define U_HOURS DATETIME_HOUR -#define U_MINUTES DATETIME_MINUTE -#define U_SECONDS DATETIME_SECOND +#define U_YEARS DATETIME_YEAR +#define U_MONTHSDATETIME_MONTH +#define U_DAYS DATETIME_DAY +#define U_HOURS DATETIME_HOUR +#define U_MINUTES DATETIME_MINUTE +#define U_SECONDS DATETIME_SECOND /*! \brief Projection code - XY coordinate system (unreferenced data) */ #define PROJECTION_XY 0 @@ -256,7 +256,7 @@ G_OPT_M_MAPSET, /*! mapset */ G_OPT_M_COORDS, /*! coordinates */ G_OPT_M_COLR, /*! color rules */ -G_OPT_M_DIR,/*! directory input */ +G_OPT_M_DIR,/*! directory input */ G_OPT_M_REGION, /*! saved region */ G_OPT_STDS_INPUT, /*! old input space time dataset of type strds, str3ds or stvds */ @@ -273,7 +273,7 @@ G_OPT_STVDS_OUTPUT, /*! new output space time vector dataset */ G_OPT_MAP_INPUT,/*! old input map of type raster, vector or raster3d */ G_OPT_MAP_INPUTS, /*! old input maps of type raster, vector or raster3d */ -G_OPT_STDS_TYPE,/*! the type of a space time dataset: strds, str3ds, stvds */ +G_OPT_STDS_TYPE,/*! the type of a space time dataset: strds, str3ds, stvds */ G_OPT_MAP_TYPE, /*! The type of an input map: raster, vect, rast3d */ G_OPT_T_TYPE, /*! The temporal type of a space time dataset */ G_OPT_T_WHERE, /*! A temporal GIS framework SQL WHERE statement */ @@ -393,15 +393,15 @@ /*! \brief Resolution - east to west cell size for 2D data */ double ew_res; /*! \brief Resolution - east to west cell size for 3D data */ -double ew_res3; +double ew_res3; /*! \brief Resolution - north to south cell size for 2D data */ -double ns_res; +double ns_res; /*! \brief Resolution - north to south cell size for 3D data */ -double ns_res3; +double ns_res3; /*!
