Re: [GRASS-dev] [GRASS GIS] #1480: v.outlier - distinguish positive and negative outlier filtering from lidar point clouds
#1480: v.outlier - distinguish positive and negative outlier filtering from lidar point clouds --+- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: unspecified Resolution: fixed|Keywords: review Platform: All | Cpu: All --+- Changes (by sbl): * status: new = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/1480#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] pyGRASS not finding addons?
Hi Yann, On Fri, Jun 20, 2014 at 7:21 AM, Yann Chemin yche...@gmail.com wrote: line 86, in __init__ self.typedesc = diz['gisprompt']['prompt'] KeyError: u'prompt' Thanks to find out this bug, should be fix in r60881. Let me know. Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2281: t.rast.aggregate unnecessaryly slow with limited number of maps
#2281: t.rast.aggregate unnecessaryly slow with limited number of maps --+- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: Default | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by sbl): * status: new = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/2281#comment:2 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] #2266: g.list and g.mlist should be able to handle strds, str3ds, stvds
#2266: g.list and g.mlist should be able to handle strds, str3ds, stvds --+- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Temporal | Version: unspecified Resolution: fixed|Keywords: g.list, g.mlist Platform: Unspecified | Cpu: Unspecified --+- Changes (by sbl): * status: reopened = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/2266#comment:6 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] #2294: t.rast.aggregate: Name output rasters based on start-time
#2294: t.rast.aggregate: Name output rasters based on start-time --+- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal| Milestone: 7.1.0 Component: Temporal | Version: svn-trunk Keywords: t.rast.aggregate |Platform: All Cpu: All | --+- Changes (by sbl): * platform: Unspecified = All * component: Default = Temporal * cpu: Unspecified = All -- Ticket URL: http://trac.osgeo.org/grass/ticket/2294#comment:1 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] #2311: PyGRASS points read from map are always 2D although they have z coordinate
#2311: PyGRASS points read from map are always 2D although they have z coordinate -+-- Reporter: annakrat | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Python | Version: svn-trunk Keywords: pygrass |Platform: All Cpu: Unspecified | -+-- Comment(by zarch): Replying to [ticket:2311 annakrat]: When I read a 3D vector map [snip] ok should be fix in r60880, please test it and let me know. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2311#comment:2 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] #2344: v.rast.stats: manual updates (esp. GRASS 7.1)
#2344: v.rast.stats: manual updates (esp. GRASS 7.1) --+- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal| Milestone: 7.1.0 Component: Docs | Version: unspecified Keywords: v.rast.stats |Platform: All Cpu: All | --+- Changes (by sbl): * component: Default = Docs -- Ticket URL: http://trac.osgeo.org/grass/ticket/2344#comment:1 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] #2320: PyGRASS doesn't write 3D vector map
#2320: PyGRASS doesn't write 3D vector map
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Python | Version: svn-trunk
Keywords: pygrass |Platform: All
Cpu: Unspecified |
-+--
Comment(by zarch):
Replying to [comment:2 annakrat]:
Actually I don't like too much the is2D parameter
in the open method, perhaps is3D could be clearer,
but we should change the attribute of the geometry
features from is2D to is3D for consistency.
Yes, I definitely agree, is3D would be much more intuitive.
I didn't change that part for now...
Probably we don't need to change 2D/3D, user specifies
3D when opening the vector map and there is already a
parameter for that in ```Vect_open_new```.
ok, done.
Now you should be able to create a 3D vector map with:
{{{
with VectorTopo(new3D, mode=w, with_z=True) as vect:
vect.write(Point(10, 20, 100))
}}}
or using the with_z parameter with the open method:
{{{
vect = VectorTopo(new3D)
vect.open(mode=w, with_z=True)
vect.write(Point(10, 20, 100))
vect.close()
}}}
I did some tests and it seems to work, let me know if you have problems.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2320#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-SVN] r60879 - grass/trunk/lib/gis/colors
On Fri, Jun 20, 2014 at 8:33 AM, svn_gr...@osgeo.org wrote: Author: ychemin Date: 2014-06-19 23:33:17 -0700 (Thu, 19 Jun 2014) New Revision: 60879 Added: grass/trunk/lib/gis/colors/kelvin Log: Added Kelvin palette ... this is incomplete, it lacks the description in lib/gis/colors.desc Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.li.simpson: memory leak in linked list?
Hi, I am trying to understand a potential memory leak in r.li.simpson: NC location, using this amount of raster cells: rows: 1355 cols: 1503 cells: 2036565 (not so many!) I get this valgrind result: ==26597== LEAK SUMMARY: ==26597==definitely lost: 690,677,357 bytes in 28,777,237 blocks ==26597==indirectly lost: 115 bytes in 2 blocks ==26597== possibly lost: 205 bytes in 6 blocks ==26597==still reachable: 4,225,783 bytes in 741 blocks ==26597== suppressed: 0 bytes in 0 blocks On larger maps wants 10GB of RAM. It happens in the linked list avl_to_array() management. ... ==26597== 129,615,648 bytes in 5,400,652 blocks are definitely lost in loss record 90 of 91 ==26597==at 0x4C279EE: malloc (vg_replace_malloc.c:270) ==26597==by 0x526CD42: G__malloc (in /usr/local/grass-7.0.0svn/lib/libgrass_gis.7.0.0svn.so) ==26597==by 0x4E3131C: avl_to_array (in /usr/local/grass-7.0.0svn/lib/libgrass_rli.7.0.0svn.so) ==26597==by 0x4E31303: avl_to_array (in /usr/local/grass-7.0.0svn/lib/libgrass_rli.7.0.0svn.so) ==26597==by 0x401C7B: calculate (in /usr/local/grass-7.0.0svn/bin/r.li.simpson) ==26597==by 0x401D8E: simpson (in /usr/local/grass-7.0.0svn/bin/r.li.simpson) ==26597==by 0x4E349D5: worker_process (in /usr/local/grass-7.0.0svn/lib/libgrass_rli.7.0.0svn.so) ==26597==by 0x4E34189: calculateIndex (in /usr/local/grass-7.0.0svn/lib/libgrass_rli.7.0.0svn.so) ==26597==by 0x573ED1C: (below main) (in /lib64/libc-2.12.so) ==26597== ... [many times] ... The code: raster/r.li/r.li.daemon/avl.c long avl_to_array(avl_node * root, long i, AVL_table * a) ... void avl_destroy(avl_tree root) used in raster/r.li/r.li.simpson/simpson.c I am not sure if the avl_destroy() doesn't leak, Help Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60879 - grass/trunk/lib/gis/colors
Thank you Markus, updated in r60889 Yann On 20/06/2014, Markus Neteler nete...@osgeo.org wrote: On Fri, Jun 20, 2014 at 8:33 AM, svn_gr...@osgeo.org wrote: Author: ychemin Date: 2014-06-19 23:33:17 -0700 (Thu, 19 Jun 2014) New Revision: 60879 Added: grass/trunk/lib/gis/colors/kelvin Log: Added Kelvin palette ... this is incomplete, it lacks the description in lib/gis/colors.desc Markus -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60879 - grass/trunk/lib/gis/colors
Hi, 2014-06-20 15:07 GMT+02:00 Yann Chemin yche...@gmail.com: candidate for relbr70 backport? 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] r60870 - grass/trunk/lib/python/script
Hi Glynn,
is this a backport to relbr7 candidate?
On Thu, Jun 19, 2014 at 4:35 PM, svn_gr...@osgeo.org wrote:
Author: glynn
Date: 2014-06-19 07:35:05 -0700 (Thu, 19 Jun 2014)
New Revision: 60870
Modified:
grass/trunk/lib/python/script/core.py
Log:
Use subprocess.Popen() directly for calling g.parser
Modified: grass/trunk/lib/python/script/core.py
===
--- grass/trunk/lib/python/script/core.py 2014-06-18 19:59:38 UTC (rev
60869)
+++ grass/trunk/lib/python/script/core.py 2014-06-19 14:35:05 UTC (rev
60870)
@@ -644,7 +644,8 @@
else:
argv[0] = os.path.join(sys.path[0], name)
-p = Popen(['g.parser', '-n'] + argv, stdout=PIPE)
+prog = g.parser.exe if sys.platform == win32 else g.parser
+p = subprocess.Popen([prog, '-n'] + argv, stdout=subprocess.PIPE)
s = p.communicate()[0]
lines = s.split('\0')
thanks
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60870 - grass/trunk/lib/python/script
Hi, 2014-06-20 16:07 GMT+02:00 Markus Neteler nete...@osgeo.org: is this a backport to relbr7 candidate? not really, it's one of many steps which need to be done after disabling shell on Windows [1]. Compilation still fails [2]. Martin [1] http://trac.osgeo.org/grass/changeset/60679/grass/trunk/lib/python/script/core.py [2] http://wingrass.fsv.cvut.cz/grass71/logs/log-r60875-997/package.log ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60870 - grass/trunk/lib/python/script
On Thu, Jun 19, 2014 at 10:35 AM, svn_gr...@osgeo.org wrote: Use subprocess.Popen() directly for calling g.parser Glynn, please provide reasoning for this change, especially its first line, since it is not in commit message and the motivation for this change is spread over several threads. Comment is the source code seems like a good place. Thanks, Vaclav Modified: grass/trunk/lib/python/script/core.py === --- grass/trunk/lib/python/script/core.py 2014-06-18 19:59:38 UTC (rev 60869) +++ grass/trunk/lib/python/script/core.py 2014-06-19 14:35:05 UTC (rev 60870) @@ -644,7 +644,8 @@ else: argv[0] = os.path.join(sys.path[0], name) -p = Popen(['g.parser', '-n'] + argv, stdout=PIPE) +prog = g.parser.exe if sys.platform == win32 else g.parser +p = subprocess.Popen([prog, '-n'] + argv, stdout=subprocess.PIPE) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2320: PyGRASS doesn't write 3D vector map
#2320: PyGRASS doesn't write 3D vector map ---+ Reporter: annakrat | Owner: grass-dev@… Type: defect| Status: closed Priority: normal| Milestone: 7.0.0 Component: Python| Version: svn-trunk Resolution: fixed |Keywords: pygrass Platform: All | Cpu: Unspecified ---+ Changes (by annakrat): * status: new = closed * resolution: = fixed Comment: Thanks a lot, it's working for me now. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2320#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] g.mlist list multiple types from all mapsets
On Thu, Jun 19, 2014 at 1:47 PM, Huidae Cho gras...@gmail.com wrote: Hmm... one flag -s (switch default) should be enough, I think. I'm not sure what is the current proposal (I think I've seen something else in some other thread) but flag -s (switch default) seems like a very bad idea as well as switching the format according to isatty(). Both would be confusing/inconsistent behavior (trying something in command line and then getting something else in Python). Vaclav On Thu, Jun 19, 2014 at 1:38 PM, Huidae Cho gras...@gmail.com wrote: Looks like we need pretty printing by default in terminal and parsable printing by default in non-terminal with -p to force pretty printing. When defaulting to pretty printing in terminal, we may need to ignore some flags only meant for parsable output. Also, a flag to force parsable printing in terminal would be useful too. On Thu, Jun 19, 2014 at 8:03 AM, Glynn Clements gl...@gclements.plus.com wrote: Huidae Cho wrote: IMO, if we replace g.list with g.mlist, it would be better to remove the -p flag and switch between the pretty output and machine-friendly output based on isatty(STDOUT_FILENO). In most cases, if the user types a command from the terminal without redirecting, they want to *see* output, not *parse* it. This way, the new g.list (current g.mlist) will be backward compatible *unless* any scripts depend on saved output of the old g.list. Also, we can save additional typing. But I'm not sure if it's a good idea to print two different outputs based on isatty. I don't think that isatty() should be the sole determining factor. I'd rather see it used to select a default format but to allow the choice to be overridden. E.g. you might want the pretty format to still be used if the output is piped through more, less, pr, etc, but piping will result in stdout being a pipe rather than a tty. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2311: PyGRASS points read from map are always 2D although they have z coordinate
#2311: PyGRASS points read from map are always 2D although they have z coordinate -+-- Reporter: annakrat | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Python | Version: svn-trunk Keywords: pygrass |Platform: All Cpu: Unspecified | -+-- Comment(by annakrat): It seems to work, thank you. Could you backport it before we close it? And the fix for #2320 as well. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2311#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] #2346: r.timestamp: support also YYYY-DOY
#2346: r.timestamp: support also -DOY +--- Reporter: neteler | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: LibGIS | Version: svn-releasebranch70 Keywords: r.timestamp, t.register, temporal, doy |Platform: All Cpu: Unspecified | +--- Changes (by wenzeslaus): * keywords: r.timestamp, t.register = r.timestamp, t.register, temporal, doy Comment: If doing this, try to follow some consistent terminology/naming. I've recently encountered different namings in GRASS: DOY, Day of Year, day of year, doy, daynum and day. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2346#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS 7 release planning
Hi devs, ... so, getting out 7.0 seems to be endless... A radical solution might be to change trunk into GRASS GIS 8. Then we do not need to wait in 7 for API stabilization and can release it as is and go ahead with the planned massive improvements. Best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2346: r.timestamp: support also YYYY-DOY
#2346: r.timestamp: support also -DOY +--- Reporter: neteler | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: LibGIS | Version: svn-releasebranch70 Keywords: r.timestamp, t.register, temporal, doy |Platform: All Cpu: Unspecified | +--- Comment(by huhabla): This must be implemented in the C datetime library and in the temporal framework parser in datetime_math.py[1]. I hoped that the dateutils[2] already support this to have it out of the box, but unfortunately they don't. Hence we should orient on the ISO 8601 standard for ordinal dates when implementing this (-DDD) but not DDD, since the temporal framework and the C datetime library also support relative time and can't decide if 1900031 is 31. Jan. 1900 or if it is the number of seconds, days, ... . [1] http://grass.osgeo.org/programming7/datetime__math_8py_source.html#l00704 [2] https://labix.org/python-dateutil -- Ticket URL: http://trac.osgeo.org/grass/ticket/2346#comment:2 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] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste
Huidae Cho wrote: I assume G__check_option_rules() is supposed to be called by G_parser(). Then, instead of calling G_fatal_error, it should append errors to st-errors. Okay; I presume that the intent is so that it will report all errors, not just the first. If so... for g.mlist we can define two different versions of rules: This version prints more correct errors because only present options/flags will be displayed in errors, but too much typing. G_option_exclusive(flag.regex, flag.extended, NULL); G_option_exclusive(flag.pretty, flag.full, NULL); G_option_exclusive(flag.pretty, opt.output, NULL); G_option_exclusive(flag.pretty, flag.mapset, NULL); G_option_exclusive(flag.pretty, flag.type, NULL); G_option_exclusive(flag.full, opt.output, NULL); G_option_exclusive(flag.full, flag.mapset, NULL); G_option_exclusive(flag.full, flag.type, NULL); This version is shorter, but -p -f will print three errors including options/flags not present. G_option_exclusive(flag.regex, flag.extended, NULL); G_option_exclusive(flag.pretty, flag.full, opt.output, NULL); G_option_exclusive(flag.pretty, flag.full, flag.mapset, NULL); G_option_exclusive(flag.pretty, flag.full, flag.type, NULL); Can we implement something like G_option_exclusive(pretty, full, G_option_or(output, mapset, type)) ? I'd rather stick to flat rules rather than heading in the direction of generalised boolean expressions. Not because it's hard to implement, but because it makes it harder to utilise the information. The next logical step is to include the rules in the --interface-description output so that the GUI can convey the relationships to the user. E.g. mutually-exclusive options might use radio buttons, or greying-out excluded options. Options which are required by another option could be marked as required when a value is given for the first option. And so on. Realistically, that requires that the rules belong to a finite set of patterns. pretty, full, and any of output, mapset, and type are mutually exclusive, but output, mapset, and type are not exclusive. How about another rule type: G_option_excludes(flag.pretty, opt.output, flag.mapset, flag.type, NULL); G_option_excludes(flag.full, opt.output, flag.mapset, flag.type, NULL); where the first option excludes all remaining options. This is essentially the negation of G_option_requires(). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60870 - grass/trunk/lib/python/script
Martin Landa wrote: Compilation still fails [2]. [2] http://wingrass.fsv.cvut.cz/grass71/logs/log-r60875-997/package.log Note that there are no longer any compilation failures for the scripts directory, only for temporal and wxGUI. The compilation failures in temporal are a consequence of lib/python/pygrass/gis/__init__.py calling grass.script.gisenv() at the top level, which it shouldn't be doing. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist list multiple types from all mapsets
Huidae Cho wrote:
Hmm... one flag -s (switch default) should be enough, I think.
I think not. We need a way to specify a particular output format. A
switch flag is only useful if you already know which format will be
used without that flag, which isn't necessarily straightforward.
A similar issue arose for r.{in,out}.bin.
They used to have a -b (byte-swap) flag (it's actually still there,
for compatibility).
This is fine for interactive use, where the user (hopefully) knows
whether the byte-order of the platform they're using matches that of
the data.
But a script which is intended to be portable would have to first
determine the byte order of the platform then either use or omit the
-b flag depending on the result.
The current versions have an order= option (values: big, little,
native, swap), so that a script can simply use order=big or
order=little, and not have to work out whether that means
byte-swapping or not.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste
G_option_excludes() works for me. On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements gl...@gclements.plus.com wrote: Huidae Cho wrote: I assume G__check_option_rules() is supposed to be called by G_parser(). Then, instead of calling G_fatal_error, it should append errors to st-errors. Okay; I presume that the intent is so that it will report all errors, not just the first. If so... for g.mlist we can define two different versions of rules: This version prints more correct errors because only present options/flags will be displayed in errors, but too much typing. G_option_exclusive(flag.regex, flag.extended, NULL); G_option_exclusive(flag.pretty, flag.full, NULL); G_option_exclusive(flag.pretty, opt.output, NULL); G_option_exclusive(flag.pretty, flag.mapset, NULL); G_option_exclusive(flag.pretty, flag.type, NULL); G_option_exclusive(flag.full, opt.output, NULL); G_option_exclusive(flag.full, flag.mapset, NULL); G_option_exclusive(flag.full, flag.type, NULL); This version is shorter, but -p -f will print three errors including options/flags not present. G_option_exclusive(flag.regex, flag.extended, NULL); G_option_exclusive(flag.pretty, flag.full, opt.output, NULL); G_option_exclusive(flag.pretty, flag.full, flag.mapset, NULL); G_option_exclusive(flag.pretty, flag.full, flag.type, NULL); Can we implement something like G_option_exclusive(pretty, full, G_option_or(output, mapset, type)) ? I'd rather stick to flat rules rather than heading in the direction of generalised boolean expressions. Not because it's hard to implement, but because it makes it harder to utilise the information. The next logical step is to include the rules in the --interface-description output so that the GUI can convey the relationships to the user. E.g. mutually-exclusive options might use radio buttons, or greying-out excluded options. Options which are required by another option could be marked as required when a value is given for the first option. And so on. Realistically, that requires that the rules belong to a finite set of patterns. pretty, full, and any of output, mapset, and type are mutually exclusive, but output, mapset, and type are not exclusive. How about another rule type: G_option_excludes(flag.pretty, opt.output, flag.mapset, flag.type, NULL); G_option_excludes(flag.full, opt.output, flag.mapset, flag.type, NULL); where the first option excludes all remaining options. This is essentially the negation of G_option_requires(). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist list multiple types from all mapsets
I agree that it can be confusing. I think we have the following options:
1. Just don't replace g.list as it is more user friendly and g.mlist is
more machine friendly.
2. Replace g.list with the current version of g.mlist and use -p in
terminal as needed.
3. Redirect g.mlist output (separator=newline) to GRASS_PAGER if isatty ==
1. My main complaint with g.mlist in terminal is that I have to use a pager
in some case.
4. Change -p to parseable printing and use pretty printing by default.
Well, at this point, I think option 1 is best. We don't have to merge
g.mlist and g.list. IMO, it all comes down to when and how often we use
g.list vs g.mlist.
Unlike g.mlist, g.mremove doesn't have this problem.
On Fri, Jun 20, 2014 at 8:38 PM, Glynn Clements gl...@gclements.plus.com
wrote:
Huidae Cho wrote:
Hmm... one flag -s (switch default) should be enough, I think.
I think not. We need a way to specify a particular output format. A
switch flag is only useful if you already know which format will be
used without that flag, which isn't necessarily straightforward.
A similar issue arose for r.{in,out}.bin.
They used to have a -b (byte-swap) flag (it's actually still there,
for compatibility).
This is fine for interactive use, where the user (hopefully) knows
whether the byte-order of the platform they're using matches that of
the data.
But a script which is intended to be portable would have to first
determine the byte order of the platform then either use or omit the
-b flag depending on the result.
The current versions have an order= option (values: big, little,
native, swap), so that a script can simply use order=big or
order=little, and not have to work out whether that means
byte-swapping or not.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Week 5: GRASS GIS 3D flowlines
Hi all, 1. What did you get done this week: I was traveling, so unfortunately not much. I improved the flow accumulation computation by integrating voxel traversal algorithm which I thoroughly tested. The explanation is here [1] and code [2]. Then, with mentors we updated the plans for next few weeks. 2. What do you plan on doing next week? I will implement better integration method - Runge-Kutta with adaptive step size. The following step is to implement gradient computation used locally on-the-fly to get the velocity field (I won't be using the gpde library). 3. Are you blocked on anything? No. [1] http://trac.osgeo.org/grass/wiki/GSoC/2014/ImplementationOf3DRasterFlowLine [2] http://trac.osgeo.org/grass/browser/sandbox/annakrat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Weekly report 5: Testing framework for GRASS GIS
1. What did you get done this week? I worked on the ticket #2326 since I realized that it is hard to test some things when the underlying functions or modules are not failing properly. With my mentor I discussed different ways of comparing map outputs. I was at a conference, so I was not able to actually implement any method. However, it seems that the already implemented textual comparisons and statistical values comparison (e.g., r.univar, r.info) might be more useful then the standard (MD5) check sums and value by value comparisons. I also started to write a documentation for testing because people started to ask about how to test. 2. What do you plan on doing next week? The plan for week six was testing of what was written so far but I'm testing as I go and it seems that it is actually too soon for evaluation of the current implementation which was also planed. Instead, I plan to implement raster and vector comparisons on different basis. 3. Are you blocked on anything? This is not real blocker, but I would need a large number of different tests which requires different map comparison methods to see which is the best one but since I cannot get the test without having the functions first. So, I need to implement all of the methods, make them customizable and hope that other developers will decide later what is advantageous for their case. Vaclav http://trac.osgeo.org/grass/ticket/2326 http://trac.osgeo.org/grass/browser/sandbox/wenzeslaus/gunittest/testing.rst?rev=60907 http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS#Week05 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
