[GRASSLIST:695] d.measure units

GRASS GRASS user
1

The manual for d.measure says that it outputs distances in the units of the
current location, but as far as I can tell it only outputs in meters.

I'm using grass 6.1cvs, updated a few days ago. My location was created
by importing a shapefile with v.in.ogr and the "location=" flag. My shapefile
came from a county GIS department, and had the following prj file:

PROJCS["NAD_1983_HARN_StatePlane_New_Mexico_Central_FIPS_3002_Feet",
  GEOGCS["GCS_North_American_1983_HARN",
     DATUM["D_North_American_1983_HARN",
       SPHEROID["GRS_1980",6378137.0,298.257222101]],
     PRIMEM["Greenwich",0.0],
     UNIT["Degree",0.0174532925199433]],
  PROJECTION["Transverse_Mercator"],
  PARAMETER["False_Easting",1640416.666666667],
  PARAMETER["False_Northing",0.0],
  PARAMETER["Central_Meridian",-106.25],
  PARAMETER["Scale_Factor",0.9999],
  PARAMETER["Latitude_Of_Origin",31.0],
  UNIT["Foot_US",0.3048006096012192]]

(I've reformatted this from the single line in the .prj file so it is more
readable here)

On import, grass warns me about the unknown datum and that I won't be able
to reproject from here, but otherwise works fine. The PROJ_INFO file contains:

name: Transverse Mercator
proj: tmerc
a: 6378137.0
es: 0.006694380022900787
lat_0: 31
lon_0: -106.25
k: 0.999900
x_0: 500000.0000000002
y_0: 0
no_defs: defined

and PROJ_UNITS contains:

unit: Foot_US
units: Foot_USs
meters: 0.3048006096012192

But each time I use d.measure, with or without the "-m" flag, it reports all
distances in meters (and does so correctly, but requires that I reconvert
back to US feet by hand).

The man page says that d.measure's only supposed to report in meters with
-m (or presumably if the location's units are meters). What's up here? Bug,
incorrect documentation, or error between keyboard and chair?

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick

2

On Wed, Apr 12, 2006 at 11:16:49PM -0600, we recorded a bogon-computron collision of the <russo@bogodyn.org> flavor, containing:

The manual for d.measure says that it outputs distances in the units of the
current location, but as far as I can tell it only outputs in meters.

I'm using grass 6.1cvs, updated a few days ago. My location was created
by importing a shapefile with v.in.ogr and the "location=" flag. My shapefile
came from a county GIS department, and had the following prj file:

PROJCS["NAD_1983_HARN_StatePlane_New_Mexico_Central_FIPS_3002_Feet",
  GEOGCS["GCS_North_American_1983_HARN",
     DATUM["D_North_American_1983_HARN",
       SPHEROID["GRS_1980",6378137.0,298.257222101]],
     PRIMEM["Greenwich",0.0],
     UNIT["Degree",0.0174532925199433]],
  PROJECTION["Transverse_Mercator"],
  PARAMETER["False_Easting",1640416.666666667],
  PARAMETER["False_Northing",0.0],
  PARAMETER["Central_Meridian",-106.25],
  PARAMETER["Scale_Factor",0.9999],
  PARAMETER["Latitude_Of_Origin",31.0],
  UNIT["Foot_US",0.3048006096012192]]

Interestingly, when I run gis.m and use its measure tool instead of using
d.measure from the command line, it reports distances in US Feet just as I'd
expected d.measure to do.

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick

3

The manual for d.measure says that it outputs distances in the units
of the current location, but as far as I can tell it only outputs in
meters.

..

name: Transverse Mercator
proj: tmerc

..

and PROJ_UNITS contains:

unit: Foot_US
units: Foot_USs
meters: 0.3048006096012192

But each time I use d.measure, with or without the "-m" flag, it
reports all distances in meters (and does so correctly, but requires
that I reconvert back to US feet by hand).

The man page says that d.measure's only supposed to report in meters
with -m (or presumably if the location's units are meters). What's up
here? Bug, incorrect documentation, or error between keyboard and
chair?

AFAICT it always says the answer in meters, the -m flag just suppresses
the other units from being reported when it is reporting an area:
  (see "m_flag" part and the print_length() fn)

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/display/d.measure/msurements.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

Now in that code the main length calculation uses G_distance()
  length += G_distance()

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gis/distance.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

..which should return a value in meters.

So "only in meters" means "and nothing else" as opposed to "as opposed
to local units"?

the help page says:
"Line lengths are stated in the same units as those of the current
LOCATION. In a XY-LOCATION, where no units are available, d.measure
prints a warning and gives results without units."

so the help page is wrong?

d.barscale and d.grid might help clear up any confusion / confirm.

Also the print_length() fn in d.measure could divide "length" by
G_database_units_to_meters_factor() and report different units without
very much effort.

Hamish

4

On Fri, Apr 14, 2006 at 12:09:41AM +1200, we recorded a bogon-computron collision of the <hamish_nospam@yahoo.com> flavor, containing:

Tom Russo wrote:
> The manual for d.measure says that it outputs distances in the units
> of the current location, but as far as I can tell it only outputs in
> meters.

[...]

> But each time I use d.measure, with or without the "-m" flag, it
> reports all distances in meters (and does so correctly, but requires
> that I reconvert back to US feet by hand).
>
> The man page says that d.measure's only supposed to report in meters
> with -m (or presumably if the location's units are meters). What's up
> here? Bug, incorrect documentation, or error between keyboard and
> chair?

[...]

Now in that code the main length calculation uses G_distance()
  length += G_distance()

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gis/distance.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

..which should return a value in meters.

[...]

the help page says:
"Line lengths are stated in the same units as those of the current
LOCATION. In a XY-LOCATION, where no units are available, d.measure
prints a warning and gives results without units."

so the help page is wrong?

Yes, after posting I dug through the code a bit and and as you mention, I saw
that the library's G_distance function always converts to meters. So yes
indeed, the help page is wrong.

My location is clearly using feet (the coordinate system is a state plane
coordinate system with coordinates in US feet, as it shows in the PROJ_UNITS
file) and gis.m's measure tool produces measurements in feet.
But G_distance() converts internally to meters, and now that I check it,
d.barscale is also deciding to display distances in meters, too. I think
both tools should probably be set to use the units of the location, not force
to meters.

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick

5

I am sure that when the GRASS code was being developed mainly by
Americans, it made assumptions about feet being the default unit
throughout the code. Now that Europeans are mainly developing GRASS,
there are several places where meters are assumed to be the default
unit. Either way, implicit conversion are ALWAYS bad. Either way,
there is a bit of arrogance built in to the assumptions about the
"right" way to do things.

Units of the Location should be the default units of all operations.
The units of the Locations should be flexible and convertible. Meters
and Feet are the two most common, but I can imagine medical
applications of GRASS where smaller default units would be convenient
(mm or microns for example). How convenient would it be to get the
area of a blood cell in square meters?

On 4/13/06, Tom Russo <russo@bogodyn.org> wrote:

On Fri, Apr 14, 2006 at 12:09:41AM +1200, we recorded a bogon-computron collision of the <hamish_nospam@yahoo.com> flavor, containing:
> Tom Russo wrote:
> > The manual for d.measure says that it outputs distances in the units
> > of the current location, but as far as I can tell it only outputs in
> > meters.
[...]
> > But each time I use d.measure, with or without the "-m" flag, it
> > reports all distances in meters (and does so correctly, but requires
> > that I reconvert back to US feet by hand).
> >
> > The man page says that d.measure's only supposed to report in meters
> > with -m (or presumably if the location's units are meters). What's up
> > here? Bug, incorrect documentation, or error between keyboard and
> > chair?
>
[...]
> Now in that code the main length calculation uses G_distance()
> length += G_distance()
>
> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gis/distance.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
> ..which should return a value in meters.
>
[...]
> the help page says:
> "Line lengths are stated in the same units as those of the current
> LOCATION. In a XY-LOCATION, where no units are available, d.measure
> prints a warning and gives results without units."
>
> so the help page is wrong?

Yes, after posting I dug through the code a bit and and as you mention, I saw
that the library's G_distance function always converts to meters. So yes
indeed, the help page is wrong.

My location is clearly using feet (the coordinate system is a state plane
coordinate system with coordinates in US feet, as it shows in the PROJ_UNITS
file) and gis.m's measure tool produces measurements in feet.
But G_distance() converts internally to meters, and now that I check it,
d.barscale is also deciding to display distances in meters, too. I think
both tools should probably be set to use the units of the location, not force
to meters.

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick

--
David Finlayson

6

Interestingly, when I run gis.m and use its measure tool instead of using
d.measure from the command line, it reports distances in US Feet just as I'd
expected d.measure to do.

I'm glad to hear this. I was worried for a moment when I first read your
post.

Michael

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

7

I am sure that when the GRASS code was being developed mainly by
Americans, it made assumptions about feet being the default unit
throughout the code. Now that Europeans are mainly developing GRASS,
there are several places where meters are assumed to be the default
unit.

I do not think that is a just assumption. e.g. UTM long predates GRASS
by a long long time.

You can ask over on the PROJ4 mailing list about unit history if you
want, I'm sure the learned elders of cartography there can provide you
with a much more satisfactory answer to this than I could.

Either way, implicit conversion are ALWAYS bad. Either way,
there is a bit of arrogance built in to the assumptions about the
"right" way to do things.

Anyway we shouldn't start changing 20 yr old library functions and the
lib fns are doing explicit conversions (PROJ_UNITS to meters, always).
G_distance() reports meters, it's well documented as such, no problem.
If the module programmer wants something else displayed there's an easy
way to convert to the local units. So this is an issue at the module
level, not the library level. (thank goodness)

Units of the Location should be the default units of all operations.
The units of the Locations should be flexible and convertible. Meters
and Feet are the two most common, but I can imagine medical
applications of GRASS where smaller default units would be convenient
(mm or microns for example). How convenient would it be to get the
area of a blood cell in square meters?

"PROJ_UNITS" takes care of any math problems in the GIS engine.
If a module is unit centric, and there's a need to make it more general,
I'm sure that isn't a big problem.

> and now that I check it, d.barscale is also deciding to display
> distances in meters, too. I think both tools should probably be set
> to use the units of the location, not force to meters.

It wouldn't be hard to change d.barscale to force the -f flag if the
units are found to be feet, but do you then need a -u flag to force
meters?

Hamish

8

I was probably too brash (combative?) on my last post. I don't mean to
offend anyone, I also don't want to defend using feet in the US, I
think it stinks.

Unfortunately, I recently completed a major project that for a variety
of reasons was using the US State Plane coordinate system in US Survey
Feet.

I had to be very careful about how GRASS handled the units since most
modules didn't care, some could use feet, and some forced a conversion
to meters. A couple of times I was stung by careless notes and an
implicit units conversion in GRASS and had to re-run my work. I felt
at the time that GRASS should be more consistent.

The barscale thing Tom was talking about is an example. The problem
is, it is a non-issue in meter-loving countries and doesn't show up as
a problem until you need a unit that isn't meters.

On 4/14/06, Hamish <hamish_nospam@yahoo.com> wrote:

> I am sure that when the GRASS code was being developed mainly by
> Americans, it made assumptions about feet being the default unit
> throughout the code. Now that Europeans are mainly developing GRASS,
> there are several places where meters are assumed to be the default
> unit.

I do not think that is a just assumption. e.g. UTM long predates GRASS
by a long long time.

You can ask over on the PROJ4 mailing list about unit history if you
want, I'm sure the learned elders of cartography there can provide you
with a much more satisfactory answer to this than I could.

> Either way, implicit conversion are ALWAYS bad. Either way,
> there is a bit of arrogance built in to the assumptions about the
> "right" way to do things.

Anyway we shouldn't start changing 20 yr old library functions and the
lib fns are doing explicit conversions (PROJ_UNITS to meters, always).
G_distance() reports meters, it's well documented as such, no problem.
If the module programmer wants something else displayed there's an easy
way to convert to the local units. So this is an issue at the module
level, not the library level. (thank goodness)

> Units of the Location should be the default units of all operations.
> The units of the Locations should be flexible and convertible. Meters
> and Feet are the two most common, but I can imagine medical
> applications of GRASS where smaller default units would be convenient
> (mm or microns for example). How convenient would it be to get the
> area of a blood cell in square meters?

"PROJ_UNITS" takes care of any math problems in the GIS engine.
If a module is unit centric, and there's a need to make it more general,
I'm sure that isn't a big problem.

> > and now that I check it, d.barscale is also deciding to display
> > distances in meters, too. I think both tools should probably be set
> > to use the units of the location, not force to meters.

It wouldn't be hard to change d.barscale to force the -f flag if the
units are found to be feet, but do you then need a -u flag to force
meters?

Hamish

--
David Finlayson