[GRASS-dev] v.to.db's foot

[Glynn Clements]

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>