[GRASS-dev] datums not recognized by g.proj?

[Hamish]

Paul wrote:
> Are you perhaps thinking of g.setproj? It does something
> fairly similar to what you describe, whereas g.proj has
> never had a very extensive interactive mode. That might
> explain a lot of the confusion. g.setproj is a completely
> different beast, one that I was never really able to tame.

I dunno, AFAIK g.setproj in G6 works extremely well. Extraordinarily well
even. Despite its complications if in doubt it's the guaranteed to work
fallback method.


Michael wrote:
> > If all the data tables in ../etc/proj are wrong and are
> > not used for anything anymore, we need to get rid of them
> > and replace them with something that works.

they are not wrong; they are still used; and they should stay (for now).
Certainly the old method is more robust than the new one is. When the
new one gets to a better state than the old, then let's talk about
replacement. But we're not there yet.. not even close IMO.

Note in GRASS 7 there is a bug in the location wizard. I need the help of
a wxPy expert to fix it..
  http://trac.osgeo.org/grass/ticket/1513#comment:3

this is known to break the ellipsoid (maybe datum too?) setting, so a good
thing to fix before digging too deep.


> A nice, clean set of 4 csv files that includes all relevant data

it ain't broke. please don't try to fix it.


If you are not being prompted for datum transform opts, my first question
is --> are you running PROJ4 version 4.7.0 <-- ? (not a svn dev checkout)
If not, rebuild against that version and try again.
(see original report in ongoing  http://trac.osgeo.org/grass/ticket/1452)

> (projections, datums, datum transforms, ellipsoids) would be
> much easier to parse. The stuff currently in ../etc/proj is
> currently a real mishmash and difficult to parse.

it's all cleanly formated, just that the logic of how it all works
is perhaps a bit convoluted. I'm pretty sure that between Paul and me
we know how it all fits together though so could add any missing
documentation.


see `proj -ld` for a list of datums known to PROJ.4. If trying to convert
non-epsg coded manually specified strings to +proj4 format, then back
to grass is failing, it seems to me the obvious solution is to only use
the +proj4 parsing for epsg codes, and use the decades worth of field
tested grass tables directly. (~recreate what g.setproj does in python,
or port a non-interactive g.setproj to a new lib fn for 'g.proj -c' to
use, if needed [I'm not sure it is; just don't try to pass GRASS datum
names to +proj=, as PROJ4 only knows its internal offerings])


thanks,
Hamish

(sorry if this is a bit off-base, I haven't seen the full thread yet; I'll
be playing catchup when I can, but I'll still be mostly offline for a wee
while yet/ for anything really important try my personal email address
which I'll check in on more often)