[GRASS-dev] d.barscale units [was: Release 6.4.1 - weekend test sprint?]

[Hamish]

Helena wrote:
> P.S. is there a reason we have km but there is the long
> meters and feet in the scalebar?
> Why not m and ft?

[d.barscale; although ps.map is also touched by similar issues,
see wish #1225]

As they are not displayed simultaneously I don't think it hurts
much. I theorize it's a matter of "kilometers" taking up too much
screen real-estate, while not abbrev. the others as they aren't
long and so didn't need to be shortened.

To me the most important thing is clarity of meaning- whatever's
least ambiguous and expected in our respective fields. Not all
consumers of our maps are scientists, and it is very hard to
please everyone (as demonstrated by discussion of units often
ending up in parochial POV bike-shed flame fests- there's simply
no single best solution). e.g. the IHO who set the standards for
nautical chart cartography use "M" to denote nautical miles
(sigh). Usually context will indicate which is the right one, but
in some cases when context is not clear it can be outright
dangerous to make those assumptions in general-purpose software.
e.g. teams of engineer-contractors who are trained to think in
feet and inches, teams of scientist-operators who are trained
to think in SI, variable names in code which do not include the
units used, "cut through the red tape" money saving plans which
get rid of built-in checks, and expensive satellites crashed into
the surface of Mars. And so I like to spell things out whenever
that's going to be unobtrusive. On the other hand km,cm,mm are
long to write out and unambiguous when abbreviated, so I don't
mind them shortened.


I am more concerned with localizing the spelling of meters ->
metres (but the two or three ways to do that has its own issues),
and adding missing "mm", "cm", and "inches" support to d.barscale.

More precise control over the exact output is arguably more
important in ps.map, as that's what is going to make the journal/
report figures much of the time, while d.* output will often be
what is used in the more relaxed settings of overhead-projector
presentations, the GUI, and web images, and so be more "human"
friendly than scientific writing tends to be.


2c,
Hamish