[GRASS-dev] Re: Decimal degree support for Lat Lon

[Glynn Clements]

Hamish wrote:

> re. this request:
>   http://article.gmane.org/gmane.comp.gis.grass.user/5335/
> 
> I wonder how it should be done.
> 
> we could make a "LL_FORMAT" variable which could take values of D, DM,
> and DMS. The default/failover would continue to be DMS. (ddd:mm:ss.ssssE)
> 
> and then any module using the G_format_northing() string would get the
> formatted result.
> 
> a question is whether to have that as a shell enviro variable or a GIS
> variable? the advantage of a GIS variable is that it could go onto a
> preferences GUI. Otherwise I'd just go with a shell var.
> 
> 
> There is the chance that scripts/modules parse the dd:mm:ss string so
> we risk breaking those.(m.proj would need to be adjusted for example) I
> think any user setting shell environment variables will be prepared to
> deal with that when their scripts break though.
> 
> another option might be LL_FORMAT=PROJ4 to get 000d00'00.000"E style
> for cs2cs.
> 
> 
> comments/ideas?

One option is to make G__getenv() always check for environment
variables first, followed by GRASS variables, and replace most of the
getenv() calls with G_getenv().

The main problem with just using $GISRC for everything is that it's
more awkward for scripts to override a variable for a single command
(e.g. if a script needs to force a specific LL_FORMAT setting so that
it can parse the output). Scripts shouldn't be modifying $GISRC
directly; instead, they need to create a private copy, modify that,
run the command with GISRC pointing to the private copy, then delete
it when they're finished.

The main problem with allowing environment variables to override GRASS
variables is that if the user sets the variable via "export" from the
command line (or bashrc etc), changes to $GISRC will cease to work.

On balance, I'm inclined to just use $GISRC for everything. If there
are cases where settings frequently need to be overridden on a
per-command basis, we should add command-line options to the affected
commands.

As for LL_FORMAT, we would also need a function to allow the module to
force a specific format. I'm not sure what the default should be. 
Using the user-specified format by default probably means that we will
be continually bumping into cases where it needs to be overridden.

There is a similarity with locale settings. If you respect the locale
by default (GRASS itself doesn't, but Python does, and this affects
GRASS code called from Python), you end up with printf("%f") using
commas as the decimal separator unless you specifically call
setlocale(LC_NUMERIC, "C") first.

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