[GRASS-dev] Missing overwrite flag for r.texture
Devs, is there a reason for r.texture missing the overwrite flag? In G7, ,---%-- Flags: -s Separate output for each angle (0, 45, 90, 135) -a Calculate all textural measurements --v Verbose module output --q Quiet module output `--%--- Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Missing overwrite flag for r.texture
Yes, the output is not defined as raster map.
This should add the --o option (untested).
{{{
Index: main.c
===
--- main.c (Revision 57260)
+++ main.c (Arbeitskopie)
@@ -109,10 +109,9 @@
opt_input = G_define_standard_option(G_OPT_R_INPUT);
-opt_output = G_define_option();
+opt_output = G_define_standard_option(G_OPT_R_OUTPUT);
opt_output-key = prefix;
-opt_output-type = TYPE_STRING;
-opt_output-required = YES;
+opt_output-multiple = YES;
opt_output-description = _(Prefix for output raster map(s));
opt_size = G_define_option();
}}}
Be aware that the test to overwrite an existing map works only for the
base map name, not for output maps that are build from the base map
name and an increment.
Best regards
Soeren
2013/8/12 Nikos Alexandris n...@nikosalexandris.net:
Devs,
is there a reason for r.texture missing the overwrite flag? In G7,
,---%--
Flags:
-s Separate output for each angle (0, 45, 90, 135)
-a Calculate all textural measurements
--v Verbose module output
--q Quiet module output
`--%---
Nikos
___
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] Why the parameters of g.region are defined as string?
Hi all,
Today I've just realize that the parameter of g.region are defined as string:
http://trac.osgeo.org/grass/browser/grass/trunk/general/g.region/main.c#L203
for example:
{{{
parm.north = G_define_option();
parm.north-key = n;
parm.north-key_desc = value;
parm.north-required = NO;
parm.north-multiple = NO;
parm.north-type = TYPE_STRING;
parm.north-description = _(Value for the northern edge);
parm.north-guisection = _(Bounds);
}}}
Why should we not use TYPE_DOUBLE for these parameters (n,s,e,w,)? Is
it to not loose significant digits?
Sorry if this has already been discussed, but I was not able to find
any reference in the mailing-list's archive.
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GSoC - GRASS GIS - T-Algebra - Weekly report 11
Hey, here is the report from the last week. I finished the vector overlay function like (intersection, union, disjoint union, exclusive union and the complement) and created a lot of tests for the temporal vector algebra. I also improved the evaluation of spatio-temporal operators by implementing a new function which analyse these operators by using PLY. In the next week I will finish temporal vector algebra with documentation and start with the temporal raster algebra.. Greetings Thomas Link to project wiki page: http://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS Link to project repository: https://code.google.com/p/grass-gis-temporal-algebra/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Why the parameters of g.region are defined as string?
On 08/12/2013 05:39 PM, Pietro wrote:
Hi all,
Today I've just realize that the parameter of g.region are defined as string:
http://trac.osgeo.org/grass/browser/grass/trunk/general/g.region/main.c#L203
[snip]
Why should we not use TYPE_DOUBLE for these parameters (n,s,e,w,)? Is
it to not loose significant digits?
It needs to be a string, so that you can use
common lat/lon notations in the format °dd'mm''ss.
Ben
Sorry if this has already been discussed, but I was not able to find
any reference in the mailing-list's archive.
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Why the parameters of g.region are defined as string?
On Mon, Aug 12, 2013 at 4:54 PM, Benjamin Ducke bendu...@fastmail.fm wrote: On 08/12/2013 05:39 PM, Pietro wrote: http://trac.osgeo.org/grass/browser/grass/trunk/general/g.region/main.c#L203 Why should we not use TYPE_DOUBLE for these parameters (n,s,e,w,)? Is it to not loose significant digits? It needs to be a string, so that you can use common lat/lon notations in the format °dd'mm''ss. Thank you Ben! I didn't thought to the lat/lon notation. Best regards Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2059: WorldView2 relative spectral response data for i.atcorr
#2059: WorldView2 relative spectral response data for i.atcorr --+- Reporter: nikosa| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal| Milestone: 7.0.0 Component: Imagery | Version: svn-trunk Keywords: i.atcorr, worldview2 |Platform: Unspecified Cpu: Unspecified | --+- Comment(by hamish): Replying to [comment:9 nikosa]: Also, how can I post a new comment and at the same time attach a file? Possible? I think that only works when you are creating a new ticket. Otherwise it has to be done in two steps. regards, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2059#comment:10 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.remove rast prefered
Martin wrote: AFAR there was already discussion related to g.remove/g.copy/g.rename modules. Before we start releasing GRASS7 tech-preview I would prefer to change the current behaviour. g.remove x Removing raster x WARNING: Raster map x not found WARNING: x nothing removed to g.remove x ERROR: Invalid data element (valid options: rast,vect..) - g.remove rast=x What do you think? I'd personally prefer to have it stay as-was, but whatever. (Extra keystrokes just slow me down.) I wonder though, as long as rast= stays as the first option will your example of g.remove rast=x still just work as g.remove x anyway since the parser assumes the first option as the default? (this is what currently happens) And so does the change need some deeper parser override? If so I'd be very hesitant about touching that in libgis as it breaks predictability of parser usage. that consistency is a very strong selling point /or any inconsistency makes the learning curve that much harder and messier. To me that consistency is more important than the pain of the lesson of how the parser works. how would it be implemented? regards, Hamish ps- my big question prior to g7 preview: to reorganize raster elements into $MAPSET/raster/mapname/elements dir structure for g7 or not? if so as per Glynn's plan we need to clean-room/from scratch(spec) write a MIT/X licensed G6 raster map driver for gdal ASAP. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Why the parameters of g.region are defined as string?
Ben: It needs to be a string, so that you can use common lat/lon notations in the format °dd'mm''ss. technically it's like ddd:mm:ss.H. see the v.in.ascii man page. fwiw GMT mapping uses something similar. regards, Hamish ps- the wxgui loc'n wizard still doesn't support that? :-( ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
