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@gclements.plus.com>