[GRASS-dev] v.to.db's foot
Glynn Clements
glynn at gclements.plus.com
Fri Oct 26 00:09:01 EDT 2007
Maciej Sieczka wrote:
> What is the foot in v.to.db? It's units.c reads:
>
> case U_FEET:
> f = 3.2808;
>
> Which means the v.to.db's foot is 1/3.2808=0.304803706. What
> "foot" is it? Grepping through PROJ.4's EPSG file, I find
> the following possible values used in coordinate systems
> around the world:
>
> to_meter=0.3047972654
> to_meter=0.3047994715386762
> to_meter=0.3047997101815088
> to_meter=0.3048
> to_meter=0.3048006096012192
>
> Neither seems to be the v.to.db one. Closest is the 4th one,
The 5th (US survey foot) is actualy the closest.
I would guess that v.to.db should probably use the US survey foot (or
offer a choice), as that's still in current use; other countries which
used the (international) foot have long since switched to metric. In
any case, the difference between the two (~610nm) is small compared to
the error in the v.to.db value (~3706nm).
> but for an exact match the ratio in units.c should be
> 3.280839895.
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.
Also in v.to.db/units.c:
f = 3.2808;
sq_f = 10.7639;
But 3.2808 * 3.2808 == 10.76364864.
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).
> BTW: in $GISBASE/etc/proj-units.table there are 2
> records for foot:
>
> feet:foot:0.3048
> USfeet:USfoot:0.34080060960121920243
>
> Isn't the latter supposed to start with 0.3048... instead of
> 0.3408.. ?! Feet are puzzling.
Ouch. Yes, it's 0.3048...; that is a massive error.
Fixed in CVS, and back-ported to 6.3 release branch.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list