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

[Maciej_Tomaszczyk]

Hello

r.fillnulls in the latest cvs version doesn’t work appropriately.

GRASS 6.3.cvs (polska_srtm):~/grass > r.fillnulls input=N49E018 output=N49E018_fill tension=40. smooth=0.1
Locating and isolating NULL areas…
100%
WARNING: Use the -m flag in combination with other print flags.
WARNING: r.buffer: 0.000000 - illegal distance specification
ERROR: parse distances error
ERROR detected: /usr/local/grass-6.3.cvs/scripts/r.fillnulls abandoned. Removing temporary map, restoring user mask if needed:
Remove
WARNING: Raster map not found
WARNING: nothing removed
Remove <r_fillnulls_17731>
Remove <r_fillnulls_17731.buf>
WARNING: Raster map <r_fillnulls_17731.buf> not found
WARNING: <r_fillnulls_17731.buf> nothing removed
Remove <r_fillnulls_17731_filled>
WARNING: Raster map <r_fillnulls_17731_filled> not found
WARNING: <r_fillnulls_17731_filled> nothing removed
ERROR: <usermask_mask.17731> not found

when i used 6.2.1 version everything was ok

r.fillnulls input=N49E018 output=N49E018_fill tension=40. smooth=0.1
Locating and isolating NULL areas…
100%
Reading input map (r_fillnulls_17909) … 100%
Finding buffer zones … 100%
Writing output map (r_fillnulls_17909.buf) … 100%
100%
Creating interpolation points…
Extracting points … 100%
Building topology …
129 primitives registered
Building areas: 100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids: 100%
Topology was built.
Number of nodes : 129
Number of primitives: 129
Number of points : 129
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0
r.to.vect complete.

Interpolating 129 points

Note: Below warnings may be ignored.

Using no segmentation for interpolation as not needed…

Authors: original version - H.Mitasova, L.Mitas, I. Kosinovsky, D.P. Gerdes
See manual pages for references and publications

Procent wykonania: Loading data from attribute table …
Reading lines from vector map … Reading nodes from vector map … 100%
100%
WARNING: strip exists with insufficient data

WARNING: 129 points given for interpolation (after thinning) is less than
given NPMIN=300

The number of points from vector file is 129
The number of points outside of 2D/3D region 0
The number of points being used is 129

Processing all selected output files
will require 5769620 bytes of disk space for temp files
Procent wykonania: WARNING:
Overshoot – increase in tension suggested.
Overshoot occures at (643,121) cell
The z-value is 196.260378,zmin is 210.000000,zmax is 347.000000
100%
history initiated
v.surf.rst complete.

Note: Above warnings may be ignored.

Patching fill data into NULL areas…
r.patch: procent wykonania: 100%
CREATING SUPPORT FILES FOR N49E018_fill

Filled raster map is: N49E018_fill

Done.

Is it a bug??
regards
maciej

Maciej Tomaszczyk
Polish Geological Institute
Geological Mapping Department

[H_B]

Maciej Tomaszczyk wrote:

r.fillnulls in the latest cvs version doesn't work appropriately.

GRASS 6.3.cvs (polska_srtm):~/grass > r.fillnulls input=N49E018
output=N49E018_fill tension=40. smooth=0.1 Locating and isolating NULL
areas...
100%
WARNING: Use the -m flag in combination with other print flags.

That is due to a bug in g.region.

LatLon:> g.region -gm
WARNING: Use the -m flag in combination with other print flags.
(and no result)

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

Hamish

[Glynn_Clements1]

Hamish wrote:

> r.fillnulls in the latest cvs version doesn't work appropriately.
>
> GRASS 6.3.cvs (polska_srtm):~/grass > r.fillnulls input=N49E018
> output=N49E018_fill tension=40. smooth=0.1 Locating and isolating NULL
> areas...
> 100%
> WARNING: Use the -m flag in combination with other print flags.

That is due to a bug in g.region.

LatLon:> g.region -gm
WARNING: Use the -m flag in combination with other print flags.
(and no result)

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

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.

--
Glynn Clements <glynn@gclements.plus.com>

[martinl]

Hi,

2007/2/9, Glynn Clements <glynn@gclements.plus.com>:

[snip]

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

Martin

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

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

[martinl]

Hi,

this bug should be fixed in CVS now.

Martin

2007/2/9, Hamish <hamish_nospam@yahoo.com>:

Maciej Tomaszczyk wrote:

> r.fillnulls in the latest cvs version doesn't work appropriately.
>
> GRASS 6.3.cvs (polska_srtm):~/grass > r.fillnulls input=N49E018
> output=N49E018_fill tension=40. smooth=0.1 Locating and isolating NULL
> areas...
> 100%
> WARNING: Use the -m flag in combination with other print flags.

That is due to a bug in g.region.

LatLon:> g.region -gm
WARNING: Use the -m flag in combination with other print flags.
(and no result)

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

Hamish

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

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

[Glynn_Clements1]

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

--
Glynn Clements <glynn@gclements.plus.com>

[cmbarton]

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

[martinl]

Hi,

2007/2/10, Michael Barton <michael.barton@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@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@gmail.com> * http://gama.fsv.cvut.cz/~landa *

[Glynn_Clements1]

Martin Landa wrote:

2007/2/10, Michael Barton <michael.barton@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)

Actually, I don't consider -gm => -gpm to be "correct"; what do you
use if you *only* want the resolution in metres, and not the region?

Explicitly adding -p in r.nulls is preferable, IMHO.

--
Glynn Clements <glynn@gclements.plus.com>

[cmbarton]

I agree that the larger issues for g.region need to be sorted out. But can
the script be made functional in this way until they are?

Michael

On 2/10/07 11:04 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Martin Landa wrote:

2007/2/10, Michael Barton <michael.barton@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)

Actually, I don't consider -gm => -gpm to be "correct"; what do you
use if you *only* want the resolution in metres, and not the region?

Explicitly adding -p in r.nulls is preferable, IMHO.

__________________________________________
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

[H_B]

Michael Barton wrote:

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?

That would fix r.fillnulls, but g.region is probably one of the most
heavily scripted modules, and who knows how many user scripts this
breaks?

We made a commitment that any script written for GRASS 6.0.0 should work
the same or better for any version of GRASS up to GRASS 7, and that any
data created for GRASS 6.0.0 will be compatible with any version of
GRASS up to GRASS 7. The only thing worse than having to rewrite your
scripts every time a new version of GRASS comes out (1-2 times a year)
is having your script silently not do the thing you expect it to do
after am upgrade. The lesson here is that messing with core modules and
library functions should be done with extreme care.

Martin Landa wrote:

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

thanks,

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

AFAIU,
* "g.region -m" by itself was and is meaninless. (doesn't print anything)

* "g.region -gm" is not the same as "g.region -pm"!
   i.e. -m does not imply -g.

* the "new way" is that "-g" be like "-m", a flag to change the state.

* the old -m did not restrict printing to just the res. Regardless of
the merits of changing that to something more logical, doing that might
break a script on someone from Basingstoke's customised Amstrad.

Fortunately "g.region -pg" == "g.region -g" output since GRASS 6.0.

Michael:

I agree that the larger issues for g.region need to be sorted out. But
can the script be made functional in this way until they are?

With Martin's 'g.region -gm' == 'g.region -pgm' fix, it should be.
I do not intend to rewrite scripts to fix forward compatibility
issues, when the compatibility issues are the things that should be
fixed. If we do that we won't catch backwards compatibility issues/
combinations when they happen and then we get lots of grumpy support
questions when we release a new version which is no longer compatible
with an earlier minor release.

WRT "g.region print=region", just typing "g.region -p" is faster

Hamish

[martinl]

Hi,

I am trying to revert the changes. I think it is better to implement
print option from the scratch then trying to change the existing flags
behaviour. I agree that all scripts written for GRASS 6.x should work
without any modification. These changes should come with new version
of GRASS (GRASS 7.x). The question is when it will be. Maybe we should
collect more detailed ideas for GRASS7.

2007/2/12, Hamish <hamish_nospam@yahoo.com>:

[snip]

We made a commitment that any script written for GRASS 6.0.0 should work
the same or better for any version of GRASS up to GRASS 7, and that any
data created for GRASS 6.0.0 will be compatible with any version of
GRASS up to GRASS 7. The only thing worse than having to rewrite your
scripts every time a new version of GRASS comes out (1-2 times a year)
is having your script silently not do the thing you expect it to do
after am upgrade. The lesson here is that messing with core modules and
library functions should be done with extreme care.

I absolutely agree.

AFAIU,
* "g.region -m" by itself was and is meaninless. (doesn't print anything)

OK, using GRASS 6.2 I get the following:

g.region -m
n=4928000
s=4914020
w=590010
e=609000
nsres=10
ewres=10
rows=1398
cols=1899

so it seems to be same as g.region -gm.

-> currently g.region in GRASS6.3 has the same output.

* "g.region -gm" is not the same as "g.region -pm"!
   i.e. -m does not imply -g.

The only difference between -gm and -pm flags, which I can see, is
missing information about projection, ellipsoid and geodetic datum.

* the "new way" is that "-g" be like "-m", a flag to change the state.

Yes, it was my idea.

* the old -m did not restrict printing to just the res. Regardless of
the merits of changing that to something more logical, doing that might
break a script on someone from Basingstoke's customised Amstrad.

Currently using print flags in g.region should be "corrected", i.e. it
should be the same as in GRASS 6.2. I hope it is. For GRASS7 (maybe to
start implementing in GRASS 6.3 as an alternative) we can try to add a
print option.

Martin

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

[Glynn_Clements1]

Martin Landa wrote:

I am trying to revert the changes. I think it is better to implement
print option from the scratch then trying to change the existing flags
behaviour. I agree that all scripts written for GRASS 6.x should work
without any modification. These changes should come with new version
of GRASS (GRASS 7.x). The question is when it will be. Maybe we should
collect more detailed ideas for GRASS7.

There's no reason why you can't add the print= option in 6.x. Adding
entirely new functionality is safe, so long as it doesn't affect
anything which doesn't explicitly use it.

--
Glynn Clements <glynn@gclements.plus.com>

[cmbarton]

Please let me know when the dust settles on how g.region is going to work
now in GRASS 6.3.

It is critical to the functionality of the GUI. A month or so back, I had to
switch all the calls from g.region -g to g.region -gp. While I'd prefer not
to have to switch them back, it is not a big effort to do so. I just need to
know which syntax is going to be used.

If there is going to be a change in g.region that could potentially break
the GUI, it would be best if we could coordinate the changes to avoid this.

Michael

On 2/12/07 5:36 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Martin Landa wrote:

I am trying to revert the changes. I think it is better to implement
print option from the scratch then trying to change the existing flags
behaviour. I agree that all scripts written for GRASS 6.x should work
without any modification. These changes should come with new version
of GRASS (GRASS 7.x). The question is when it will be. Maybe we should
collect more detailed ideas for GRASS7.

There's no reason why you can't add the print= option in 6.x. Adding
entirely new functionality is safe, so long as it doesn't affect
anything which doesn't explicitly use it.

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

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

[H_B]

Michael wrote:

Please let me know when the dust settles on how g.region is going to
work now in GRASS 6.3.

It is critical to the functionality of the GUI. A month or so back, I
had to switch all the calls from g.region -g to g.region -gp. While
I'd prefer not to have to switch them back, it is not a big effort to
do so. I just need to know which syntax is going to be used.

If there is going to be a change in g.region that could potentially
break the GUI, it would be best if we could coordinate the changes to
avoid this.

The whole idea of having a stable major version is that you should never
need to do that during any GRASS "6.x". Only if you want access to a new
feature.

Maris wrote:

maybee as light offtopic, but one day I was thinking how to deal with
changes, that break scripts/existing programms? No matter how hard we
try to keep backwards compatability, still time to time we break some
things.

Then they are bugs and we should either fix them or revert the change.

Not a solution but a nice feature could be BREAKLOG.

I fear if we have that we may be tempted to use it. Certainly we need
one for a major version change (5->6, 6->7), and it is important to note
on the Wiki Plans roadmap page (-> next release announcement) when major
code changes happen in modules which subtly change the result without
actually breaking anything.

Hamish

[martinl]

Hi Michael,

2007/2/12, Michael Barton <michael.barton@asu.edu>:

Please let me know when the dust settles on how g.region is going to work
now in GRASS 6.3.

It is critical to the functionality of the GUI. A month or so back, I had to
switch all the calls from g.region -g to g.region -gp. While I'd prefer not
to have to switch them back, it is not a big effort to do so. I just need to
know which syntax is going to be used.

I understand, sorry for these complications, g.region -pg still
working as g.region -g. I hope there is no problem with print flags in
g.region. This behaviour should be stabilized.

If there is going to be a change in g.region that could potentially break
the GUI, it would be best if we could coordinate the changes to avoid this.

OK, the flags behaviour should be frozen. I would like to implement
print option.

Martin

Michael

On 2/12/07 5:36 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

>
> Martin Landa wrote:
>
>> I am trying to revert the changes. I think it is better to implement
>> print option from the scratch then trying to change the existing flags
>> behaviour. I agree that all scripts written for GRASS 6.x should work
>> without any modification. These changes should come with new version
>> of GRASS (GRASS 7.x). The question is when it will be. Maybe we should
>> collect more detailed ideas for GRASS7.
>
> There's no reason why you can't add the print= option in 6.x. Adding
> entirely new functionality is safe, so long as it doesn't affect
> anything which doesn't explicitly use it.

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

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

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

[cmbarton]

Thanks Martin. As long as the flags don't change and the format of their
output doesn't change, there will be no problem with the GUI.

Michael

On 2/13/07 1:04 AM, "Martin Landa" <landa.martin@gmail.com> wrote:

Hi Michael,

2007/2/12, Michael Barton <michael.barton@asu.edu>:

Please let me know when the dust settles on how g.region is going to work
now in GRASS 6.3.

It is critical to the functionality of the GUI. A month or so back, I had to
switch all the calls from g.region -g to g.region -gp. While I'd prefer not
to have to switch them back, it is not a big effort to do so. I just need to
know which syntax is going to be used.

I understand, sorry for these complications, g.region -pg still
working as g.region -g. I hope there is no problem with print flags in
g.region. This behaviour should be stabilized.

If there is going to be a change in g.region that could potentially break
the GUI, it would be best if we could coordinate the changes to avoid this.

OK, the flags behaviour should be frozen. I would like to implement
print option.

Martin

Michael

On 2/12/07 5:36 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Martin Landa wrote:

I am trying to revert the changes. I think it is better to implement
print option from the scratch then trying to change the existing flags
behaviour. I agree that all scripts written for GRASS 6.x should work
without any modification. These changes should come with new version
of GRASS (GRASS 7.x). The question is when it will be. Maybe we should
collect more detailed ideas for GRASS7.

There's no reason why you can't add the print= option in 6.x. Adding
entirely new functionality is safe, so long as it doesn't affect
anything which doesn't explicitly use it.

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

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

__________________________________________
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