hamish_b at yahoo.com
Wed Sep 21 19:22:39 EDT 2011
> G_units_to_meters_factor() (in lib/gis/units.c, in 7.0) has:
> case U_FEET:
> return 3.28083989501312; /* 1 / (0.0254 * 12) */
> This is correct for the international foot but, AFAIK, most
> (but not all) non-metric geographical data uses the US survey
This is a common misconception among non-USers* which has caused
me no end of headaches. The "US Survey Foot" has been in the
process of being phased out since like the 1950s or so, AFAIK
only about 2(?) of 50 state planes actively still use it,
everyone else has switched over to the translates-to-meters-
cleanly version. (down from ~13 states in the last 10 years) Of
course it is still relevant for historic datasets.
the worst offender I've found is the unix `units` programs, which
if it sees you are using an en_US locale silently decides that
you want to use the US Survey foot for all calculations of
distance, area, etc. argh!
[*] I think USers are equally vaguely aware of it, but more used
to the idea that units can be less than stable, so more easily
accept that sometimes it's this, sometimes it's that, names mean
nothing, meh, let's get a hotdog.
> IMHO, we need both U_FEET and e.g. US_USFEET.
If G_units_to_meters_factor() is going to be used, yes.. But
I question if it should be.
> Possibly also for miles.
no sure about that one (if it would ever be used in practice).
watch out for acres in old land parcels based on the US foot
> Or even U_INTFEET and U_USFEET; calling one of them just
> "feet" creates a risk of users selecting the "default" rather
> the correct one.
fwiw, for us survey foot:
1 / 0.30480060960121920243 = 3.28083333333333
G_units_to_meters_factor() seems to be used by
misc/m.measure/main.c and vector/v.to.db/units.c
which should perhaps follow the location's ultimate source, the
meters: multiplier from the PERMANENT/PROJ_UNITS file, not its
own hardcoded calculation!
for m.measure AFAICT it should definitely be reading from the
PROJ_UNITS file for the multiplier and not deciding on its own.
that's a bug.
for v.to.db, to comes from:
parms.units = G_define_standard_option(G_OPT_M_UNITS);
unless "usfoot" is added to that list, it should always return
the 0.3048m intl. foot.
see also general/g.setproj/.
More information about the grass-dev