[GRASS-dev] [GRASS-SVN] r56717 - grass/trunk/demolocation/PERMANENT

[Hamish]

Hamish:
> grass/trunk/demolocation/PERMANENT/PROJ_INFO
> > Log:
> > "no defaults" not needed here. (see /usr/share/proj/proj_def.dat)

MarkusN:
> ... then our mechanism to generate EPSG 4326 is suboptimal

yes, that is known since 'g.proj -c' first arrived; grass's
datum and projection support is better developed than proj4's
(at least from the POV of grass's libs). By making grass's
support = proj4's (e.g. assuming 'g.proj -c' results are the
acme) we limit ourselves and make our own support worse. So
we take advantage of what proj4 offers, but we are not limited
by it, and do not become it.

Responding to an earlier email by Nikos, it is also known that the
location wizard is not as exact as the text based g.setproj. e.g.
the location wizard does not support extra known-to-grass datums
and US FIPS county codes, and all the g.proj conversions to and
from WKT and +proj4 strings are many and not perfect. It's also
known that g.setproj can't take EPSG and georef'd files as input,
so less convenient.

> and needs to be fixed.

in the case of the demolocation PROJ_INFO file I think it's
enough to just craft it by hand to make it as it should be.
For locations created by 'g.proj -c' it's always going to be
laundered through proj4 (actually it's OGR lib code) and that
incurs some proj4-related cruft. shrug, that's the cost of
using proj4 to create locations I guess.


regards,
Hamish