Add option to disable warnings in modules

[kyngchaos]

I would like to be able to suppress warning messages in commands, yet keep messages based on the GRASS_VERBOSE level, especially in raster projection (r.proj) where is possible to get thousands of "pj_transform() failed: tolerance condition error" warnings, depending on the projection, that are expected but clutter the progress output and slow down the process.

I see that G_warning() has a companion G_suppress_warnings(), so this at least was an intended possibility at one time (but maybe deprecated or discouraged now?).

[hamish]

Replying to kyngchaos:

I would like to be able to suppress warning messages in commands, yet keep messages based on the GRASS_VERBOSE level, especially in raster projection (r.proj) where is possible to get thousands of "pj_transform() failed: tolerance condition error" warnings, depending on the projection, that are expected but clutter the progress output and slow down the process.

better: fix the noisy module. e.g.

 if(!pj_fail_flag)
    G_warning();
 else
    pj_fail_flag = TRUE;

I see that G_warning() has a companion G_suppress_warnings(), so this at least was an intended possibility at one time (but maybe deprecated or discouraged now?).

vaguely discouraged, as it will inadvertently hide important problems, and you /will/ be bitten by this after some time.

Hamish

[kyngchaos]

better: fix the noisy module.

Well, it's in the GRASS proj library, do_proj.c: pj_do_proj() and pj_do_transform(), so it'll affect anything that projects coordinates. I don't see a way to remove it for a single module other than a flag.

if (ok < 0) {
  G_warning(_("pj_transform() failed: %s"), pj_strerrno(ok));
}
return ok;

[pkelly]

Something about this just doesn't seem quite right to me. What is the "tolerance condition error" and under what conditions does it appear? Are you sure it is harmless? It sounds to me like something we should clarify on the PROJ.4 list, rather than just hiding it.

[kyngchaos]

This will happen in any of the perspective/orthographic and related projections where there are large sections (ie corners) that have no reverse projection, since GRASS uses a reverse projection to project rasters.

[kyngchaos]

This will add a 'w' nowarn flag for just r.proj.seg, and toggles the warning around the 2 sections of code where projection occurs

[kyngchaos]

Hmm, the first nowarn toggle missed the correct code... maybe it should go around the bordwalk() calls (both? 2nd only?)? I still got warnings when it scans for the extents. But the main row/column loop worked.

So, as a comparison: before this enhancement request, I had a r.proj (LL to perspective) running for 2 hours and gave up and cancelled it. I couldn't tell how far it got since the progress was lost in warnings.

With just the main loop with warnings off, r.proj finished projecting the raster in 10 minutes, and I don't see any missing or corrupt data.

Yes, it is possible that that there could be other issues in other projections where warnings would be helpful, but if (I know, "if") I see them I can redo it with warnings. Maybe some known harmless warnings, like the tolerance condition error warning, could be explicitly ignored in the nowarn flag, but I suppose we'd have to decide what is harmless, if possible.

[pkelly]

I also like the idea of a flag for r.proj to hide any errors from PROJ.4, but for implementing it I think it might be better (this would be for GRASS 7 - too disruptive for 6.x I think) to remove the code in lib/proj_do_proj.c that prints the error messages as a GRASS warning, and instead make sure all modules calling pj_do_proj() or pj_do_transform() check the return value and do what they see fit if it indicates an error value. They really should be checking the return value at the minute IMHO.

[glynn]

Replying to kyngchaos:

I would like to be able to suppress warning messages in commands, yet keep messages based on the GRASS_VERBOSE level, especially in raster projection (r.proj) where is possible to get thousands of "pj_transform() failed: tolerance condition error" warnings, depending on the projection, that are expected but clutter the progress output and slow down the process.

The correct solution here is as others have suggested: limit the number of warnings from a single source rather than disabling them completely.

The main problem with pj_do_proj() and pj_do_transform() is that the same G_warning() call is used to report any and all error conditions from pj_transform(). Some may be more serious than others, so printing a fixed number of warnings could result in harmless warnings being shown but more serious ones being suppressed.

A more robust solution is to record the last error code, and suppress multiple consecutive occurrences of the same error. If you get a different error, you generate a warning for it.

This will still produce a flood if you get alternating errors, but avoiding that is awkward, requiring e.g. an array containing a flag for each error code.

I see that G_warning() has a companion G_suppress_warnings(), so this at least was an intended possibility at one time (but maybe deprecated or discouraged now?).

It's a band-aid for library functions which generate too many warnings. I suggest removing it in 7.0. If there are cases where the library should normally produce a warning (because it's unrealistic to require programmers to manually check for rare errors) but cases where it needs to be disabled, there should either be a "nowarn" flag or a corresponding function to suppress a specific warning.

The existing usage means that code which uses G_suppress_warnings() around e.g. G_read_colors() to suppress the "colour support ... missing" warning (which is harmless; you just get the default rainbow colour table) could also suppress more significant warnings.

[neteler]

See also ticket #383