[GRASS5] [bug #992] (grass) g.region Vask problem in lat/long

[Glynn Clements]

Markus Neteler wrote:

> > Can you tell us the default region (rather than the current region),
> > as it seems to be the default West value that's causing the problem.
> 
> Yes, please have a look in the RT - I had submitted a followup (and
> obviously forgot to cc to the list). In fact the default West value that's
> causing the problem.

OK, I've looked at that, but I cannot reproduce the problem. Can you
send me the files?

> > > Now starting g.region, selecting menu 1:
> > > V_ask error: Length out of bounds in call to V_const           <- this warning appears for 3 sec
> > 
> > > The west value makes me unhappy. Looks like a rounding problem somewhere.
> > 
> > Well, floating point can't represent exactly fractions where the
> > denominator isn't a power of two, so rounding errors will occur.
> 
> Mhhh, but I was demanding rounded coordinates with
> g.region res=0:00:30 -a
> earlier. The DEFAULT_WIND contains a round West, only inside g.region
> it appears strange (means: should be everywhere the same value).

Well, GRASS doesn't use DMS internally; the DMS -> FP -> DMS
conversions could easily introduce rounding error. Particularly if
something is multiplying a rounded representation of one second by 30.

> > G_lon_format() (which generates the string in question) doesn't use
> > any specific precision, so you get the standard behaviour of "%f",
> > which is 6 digits after the point.
> > 
> > But how many digits should it use? Are whole seconds sufficiently
> > accurate? Unless you require accuracy better than thousandths of a
> > second, the argument should be converted to seconds and integer
> > arithmetic used.
> 
> Eventually yes. At least the overwriting (see RT followup) isn't nice.

    I slighly change the report:
    The field of default region in the g.region menu is too long and writing
    into the current region. If there are no objections we should limit the
    field length in
    src/libes/gis/edit_cellhd.c

What should it be changed to? To whatever space is currently
available?

This would be better done in G_{lat,lon}_format(); using a precision
specifier (e.g. "%.2f") will round the result, so that e.g. 
"59.999999" -> "60.00", while truncating the string within
G_edit_cellhd() would, er, truncate it, so "59.999999" -> "59.99".

But G_{lat,lon}_format() are used elsewhere, and other uses might
warrant greater precision. Ideally the formatting functions should
allow the precision to be specified, but that has compatibility
implications.

Ultimately, there are two problems here. One is that the error is
being introduced in the first place, the other is that G_edit_cellhd()
only copes with certain easting/northing values.

-- 
Glynn Clements <glynn.clements at virgin.net>