[GRASSLIST:718] Re: d.measure units

[David Finlayson]

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