[GRASS-user] r.fillnulls in the latest cvs version doesn't work appropriately

Michael Barton michael.barton at asu.edu
Sat Feb 10 11:58:50 EST 2007


Beyond the larger issue of how the complex command g.region should be
controlled (which has already had considerable discussion), won't replacing
g.region -gm with g.region -gpm fix the immediate problem with the r.nulls
shell script?

Michael


On 2/9/07 11:35 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Martin Landa wrote:
> 
>>>> -g implies that you want output. You shouldn't have to add -p as well.
>>>> I still don't fully understand the logic of why it was changed.
>> 
>> my idea was to make the -g flag more general (i.e. *"how"* to print
>> not "what" to print).
>> 
>>> 
>>> The idea was that the choices of what to print and how to print it are
>>> orthogonal.
>>> 
>>> There should be a fallback so that if you don't specify *what* to
>>> print, -p should be assumed. However, the code which is meant to do
>>> this isn't sufficiently general; it treats -g as -gp and -gz as -gzp,
>>> but doesn't add -p in other cases which might need it.
>>> 
>>> Rather than having one variable (print_flag), there should be two: one
>>> for the "what" and another for the "how". If the "what" is empty, it
>>> should add -p.
>> 
>> I agree,
>> 
>> *what* to print
>> #define PRINT_REG    0x01
>> #define PRINT_LL     0x04
>> #define PRINT_EXTENT 0x08
>> #define PRINT_CENTER 0x10
>> #define PRINT_METERS 0x20
>> #define PRINT_3D     0x40
>> #define PRINT_MBBOX  0x80
>> 
>> *how* to print:
>> #define PRINT_SH     0x02
>> 
>> should be OK?
> 
> I would have thought that PRINT_LL and PRINT_METERS should be in the
> "how" category. I'm aware that the issue is complicated by the fact
> that the existing flags combine "what" and "how":
> 
>        -p  Print the current region
>        -l  Print the current region in lat/long on current ellipsoid/datum
>        -e  Print the current region extent
>        -c  Print the current region map center coordinates
>        -m  Print region resolution in meters (geodesic)
>        -3  Print also 3D settings
>        -b  Print the maximum bounding box in lat/long on WGS84
>        -g  Print in shell script style
> 
> E.g. -m combines a what (resolution) with a how (metres).
> 
> AFAICT, the "what" category consists of:
> 
> region (bounds, resolution, rows/cols)
> extent
> centre
> resolution only
> also 3D (Z) values
> 
> while the "how" category consists of:
> 
> shell-script style ("key=value" rather than "key: value")
> metres (for lat/lon locations)
> degrees (for projected locations)
> 
> Any position or dimension should be able to be output in metres,
> degrees, or the location's units (in case it uses neither metres nor
> degrees, but e.g. feet).
> 
> The output should be available in either "key: value" style (with
> padding to align the "value" column) or "key=value" style.
> 
> The bounds, resolution, extent, and centre can be either 2D or 3D.
> 
> Thinking about it, the existing mess of printing flags is probably too
> far gone to be put into any sane framework without creating major
> compatibility problems.
> 
> It may be better to simply add a print= option which takes a list of
> keywords, each of which controls a single "what" or "how" choice,
> e.g.:
> 
> g.region print=bounds,resolution,center,meters,shell
> 
> would output:
> 
> n=4928010
> s=4913700
> w=589980
> e=609000
> nsres=30
> ewres=30
> center_northing=4920855
> center_easting=599490

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton





More information about the grass-user mailing list