[GRASS-dev] Re: [GRASS-CVS] hamish: grass6/vector/v.to.db units.c, 1.4, 1.5

[Hamish]

Hi Maciek,
[& cc -dev]

> Regarding this fix:
> 
> grass at intevation.de wrote:
> > Author: hamish
> > 
> > Update of /grassrepository/grass6/vector/v.to.db
> > In directory doto:/tmp/cvs-serv538
> > 
> > Modified Files:
> > 	units.c 
> > Log Message:
> > more precise conversions for square miles, feet, and acres
> 
> <snip>
> >  	case U_FEET:
> > -	    f      = 3.2808;
> > -	    sq_f   = 10.7639;
> > +	    f      = 3.28083989501312; /*  1 / (0.0254 * 12)    */
> > +	    sq_f   = 10.7639104167097; /*  1 / (0.0254 * 12)^2  */
> >  	    break;
> >      }
> </snip>
> 
> Glynn wrote on the grass-dev ML [1]:
> 
> "I suggest changing v.to.db/units.c to divide by a factor
> rather than multiply (conversions are normally specified as
> metres/unit rather than units/metre), and *not* excessively
> rounding the constants (an IEEE-754 "double" has 15 decimal
> digits of precision)."

I hadn't realized the problems referred to in that email hadn't been fully
fixed. Given the seriousness of GRASS reporting slightly wrong results..

> Do you think this could be applied now and would you be
> willing to? I guess the same applies to r.report, does it?
> If this cannot be done, should I open a ticket in the tracker?
> 
> [1]http://www.nabble.com/v.to.db%27s-foot-t4694999.html#3854949952855493162

the 15 digit precision issue has now been fixed in CVS for v.to.db (and thus
v.report), r.coin, and r.report. Reported feet, acres, & square miles from
those modules are affected.

as for dividing vs. multiplying that's mostly a matter of understandability,
which isn't as clear as it might be but doesn't affect the output. I would
leave that for someone else if they really want to change it. I have no intent
to do so and don't think that alone is worthy of a bug report. At least now the
code is commented WRT where those numbers came from.

as for foot vs US survey foot, there seems to be some confusion from the
[rather poor IMO] abbreviation of the US survey foot to "USfoot". This tends to
make many (non US) folks incorrectly assume that in the US the "USfoot" is in
common use outside of surveying circles. I can guess that if your GRASS
location is using a State-Plane projection where the unit length IS in survey
feet a user /might/ guess that v.to.db would answer in survey feet too, and
that might warrant a mention in the v.to.db+v.report help pages to express that
"normal" feet are used. Outside that case, no American would assume that a foot
was anything other than exactly 12" (ie normal inches) unless it specifically
said it was "survey feet".

It's not the same situation as the US ton vs the kg tonne, where the "US"
version is actually what is commonly used in the US.

Glynn:
> Neither the US survey foot (1200/3937 metres) nor the international
> foot (0.3048 metres) can have the foot/metre ratio represented exactly
> in decimal. 

the "normal" foot* is exactly 0.3048m as the modern inch is defined to be
exactly 25.4mm.  (and 254 * 12 = 3048)

[*] i.e. 12", I think "international foot" contributes to assumptions that this
is not the version commonly used in the US.

The 'units' program's "automatic smart l10n" locale-based tricks have been
giving me headaches too, FWIW.


corrections welcome,

Hamish


      ____________________________________________________________________________________
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/