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

this bug's URL: http://intevation.de/rt/webrt?serial_num=939
-------------------------------------------------------------------------

Subject: d.barscale ignores PROJ_UNITS

grass downloaded at: CVS Server, Germany
grass binary for platform: I compiled the sources myself
grass sources source: yes, I am using the latest GRASS from CVS

Hi,

Helena reported to me (and I tend to agree) that d.barscale
ignores PROJ_UNITS. In case one work in a feet State Plane
coordinate system, d.barscale will report nonsense.
Probably other modules are affected as well?

Markus

-------------------------------------------- Managed by Request Tracker

Request Tracker wrote:

Subject: d.barscale ignores PROJ_UNITS

Helena reported to me (and I tend to agree) that d.barscale
ignores PROJ_UNITS. In case one work in a feet State Plane
coordinate system, d.barscale will report nonsense.

I've fixed this (well, I think so; either that or I've squared the
error factor).

I'm presuming that the bug treated units as metres, resulting in the
bar being too small (e.g. a "5km" bar was really 5000 ft). The bar now
gets larger as the "meters" setting in PROJ_UNITS gets smaller.

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

Glynn

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. The length of the bar should be OK, drawing a longer bar may
make it difficult
to place it (it is already pretty long)..

In addition to this problem, I have an area where I need to combine data
provided in
state plane ft and state plane meters and when I try to project between
the
two locations proj complains that the map is not in my region. So it
looks like
it interprets ft as meters for both locations - I will try to go through
lat-long location
to see what is going on, but if anybody has done anything like this and
can confirm
or deny the problem that would help.

Also some other modules need to be checked for units (e.g. r.profile and
area
measurements). The numbers would be probably correct, it is just the unit

written on the screen which is wrong and assumes that everything is
meter.
I will check some of the modules and report what I find.

thanks for looking into this - the life would be for sure easier if we
could finally
switch to meters, however the latest and greatest and newest and most
high tech state data that I am
working with are again in feet.

Helena

Clements wrote:

Request Tracker wrote:

> Subject: d.barscale ignores PROJ_UNITS

> Helena reported to me (and I tend to agree) that d.barscale
> ignores PROJ_UNITS. In case one work in a feet State Plane
> coordinate system, d.barscale will report nonsense.

I've fixed this (well, I think so; either that or I've squared the
error factor).

I'm presuming that the bug treated units as metres, resulting in the
bar being too small (e.g. a "5km" bar was really 5000 ft). The bar now
gets larger as the "meters" setting in PROJ_UNITS gets smaller.

--
Glynn Clements <glynn.clements@virgin.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Helena 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?

I think that it would probably be better to add an explicit option to
d.barscale to select non-metric units.

Also, what to do about large scale factors? d.barscale chooses among a
list of bar size according to the size of the window. Currently, the
available sizes are:

  {"10 meters" , 10. , 70., 10},
  {"50 meters" , 50. , 200., 5},
  {"100 meters", 100. , 700., 10},
  {"500 meters", 500. , 2000., 5},
  {"1 km" , 1000. , 7000., 10},
  {"5 km" , 5000. , 20000., 5},
  {"10 km" , 10000. , 70000., 10},
  {"50 km" , 50000. , 200000., 5},
  {"100 km" , 100000. , 700000., 10},
  {"1000 km" ,1000000. ,7000000., 10},
  {"10000 km" ,10000000.,70000000., 10}

Presumably the larger scales would use (statute) miles rather than
"kilofeet"? What should the changeover point be? 1 mile (= 5280 feet)?

Anyway, I'll leave it alone for now; at least the length should
actually be as indicated, even if it doesn't use the preferred units.

The length of the bar should be OK, drawing a longer bar may
make it difficult
to place it (it is already pretty long)..

Well, the bar is sized automatically; the change shouldn't cause it to
occupy a larger region of the window than it otherwise would have.

Also some other modules need to be checked for units (e.g. r.profile
and area measurements). The numbers would be probably correct, it is
just the unit written on the screen which is wrong and assumes that
everything is meter. I will check some of the modules and report
what I find.

Again, this is arguably better dealt with via command-line options.
The user doesn't necessarily want to use the same units as the map's
coordinate system.

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.

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

On Sun, Mar 03, 2002 at 11:58:11PM +0000, Glynn Clements wrote:

Helena 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. 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...

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.

--
Eric G. Miller <egm2@jps.net>

[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" :wink:

> 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@virgin.net>

On Mon, Mar 04, 2002 at 01:59:59AM +0000, Glynn Clements wrote:

> > 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.

I don't know how many places that feet/meters conversion is used. It
might be worthwhile to do a little investigation to see how significant
the effects might be. Say, if you took a state plane map, and projected
it to UTM, if that conversion was used, then significant error likely was
introduced (provided the state plane was in feet, not meters). We need
to keep both, but differentiate between the International Foot, and the
U.S. Survey Foot. I think there may be places that use the
International Foot for mapping ??

Anyway, probably little point in changing it until the whole projection
code gets fixed up.

--
Eric G. Miller <egm2@jps.net>

Glynn Clements wrote:

> 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.

d.barscale now has a "-f" switch to select feet/miles instead of
metres.

Also, the bug with the x/y coordinates from the "at=..." option being
swapped has been fixed, and "d.barscale -m" will now invoke
"d.barscale at=..." once you confirm placement (so the command will
appear in the output of d.save, and the scale won't vanish if the
monitor is resized).

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