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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
