Opened 11 years ago

Closed 8 years ago

Last modified 8 years ago

#2318 closed defect (fixed)

G7: t.* modules unclear -s flag

Reported by: neteler Owned by: grass-dev@…
Priority: critical Milestone: 7.2.0
Component: Temporal Version: svn-releasebranch70
Keywords: Cc:
CPU: Unspecified Platform: Unspecified

Description

What does the -s flag do [several t.* modules]?

#% description: Activate spatial topology

perhaps change to

#% description: Check spatial topology

Change History (11)

comment:1 by martinl, 9 years ago

Milestone: 7.0.07.0.5

comment:2 by martinl, 8 years ago

Still an issue?

in reply to:  2 comment:3 by veroandreo, 8 years ago

Replying to martinl:

Still an issue?

AFAIU, yes. Check for example: t.select, t.sample, t.topology

In grass70 there's still also -s flag in t.rast.aggregate, while that was already changed to suffix parameter in 72 and trunk.

Then, t.rast.univar uses -s to suppress printing of column names in 70, 72 and trunk.

In 72 and trunk, t.rast.algebra uses -s to activate spatial topology (there's no t.rast.algebra in 70); t.rast.mapcalc in 70, 72 and trunk uses -s to check for spatial overlap.

-s is used differently across t.* modules

comment:4 by neteler, 8 years ago

This should be solved prior to the 7.2.0 release

comment:5 by martinl, 8 years ago

Priority: normalcritical

comment:6 by huhabla, 8 years ago

Attempt to harmonize the temporal module flags in r69510.

The column header suppress flags is now "u" in all related modules. The "-s" flag is now consistently used for spatio-topological relation computation.

Backport to 7.2 after approval of the changes.

comment:7 by mlennert, 8 years ago

Milestone: 7.0.57.2.0

IIUC, this should not go into 7.0.5.

in reply to:  6 comment:8 by martinl, 8 years ago

Replying to huhabla:

Backport to 7.2 after approval of the changes.

Please backport (we are close to RC2)

comment:9 by huhabla, 8 years ago

Resolution: fixed
Status: newclosed

Backport done in r69830.

comment:10 by wenzeslaus, 8 years ago

Do I understand correctly that renamed_options is really just for options, not flags, right? Anyway, it would be good to keep the original flag where possible (even manually by putting there another flag).

in reply to:  10 comment:11 by huhabla, 8 years ago

Replying to wenzeslaus:

Do I understand correctly that renamed_options is really just for options, not flags, right? Anyway, it would be good to keep the original flag where possible (even manually by putting there another flag).

Renamed flags have been added to renamed_options file in relbr72 and trunk.

Note: See TracTickets for help on using tickets.