[GRASS5] [bug #939] (grass) d.barscale ignores PROJ_UNITS

[Glynn Clements]

[RT snipped from recipient list]

Eric G. Miller wrote:

> > > I believe that the error was only in the untis that it has written
> > > out - so everything should have stayed the same except it should
> > > have written ft insted of m. So I had a barscale showing 5000m but
> > > its length was in fact 5000ft. So looking into PROJ_UNITS and
> > > choosing whether to write ft or m should be the fix.
> > 
> > So, if the "meters" setting in PROJ_UNITS is approximately equal to
> > 0.3048, d.barscale should use multiples of feet, otherwise use metres? 
> 
> Ideally, d.barscale should generate scale bars in a number of units,
> which the user may specify.  That is, my map units may be meters, but
> folks in the U.S. often want feet/yard/mile scales. 

That was basically my line of thought. It shouldn't be too hard to
implement; just select a different "scales" table.

> Or, I might want a
> barscale showing both kilometers and miles.  It might be nice to
> allow the user to specify the number of divisions, and the division
> sizes (e.g. divisions=4 divsize=10 units=miles).  Gives the user a bit
> more flexibility...

I was thinking of a quicker solution than a "barscale definition
language" ;)

> > While we're on the subject of units, I note that GRASS' "foot"
> > (according to src/libes/gis/proj3.c) is the international foot
> > (0.3048m) rather than the US survey foot (0.3048006096m). Is this
> > correct? It isn't likely to be a problem for measurements (the
> > difference being 2 ppm), but it could be a significant problem for
> > coordinates.
> 
> Yea, I think that's incorrect.  It should be using the "old" survey
> foot.

So, what to do about it?

Simply changing 0.3048 to 0.3048006096 might mess up users' existing
data. OTOH, there's possibly a fair number of cases where the data is
already messed up but the user doesn't realise it.

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