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

Martin Landa landa.martin at gmail.com
Sat Feb 10 12:08:58 EST 2007


Hi,

2007/2/10, Michael Barton <michael.barton at asu.edu>:
> Beyond the larger issue of how the complex command g.region should be
> controlled (which has already had considerable discussion), won't replacing

the last Glynn's notes about print parameters make sense to me.

> g.region -gm with g.region -gpm fix the immediate problem with the r.nulls
> shell script?

I hope I fixed this problem or I missed something? Now:

g.region -m == g.region -gm (== g.region -pgm)

Regards, Martin

> 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
>
>
>


-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *




More information about the grass-user mailing list