Hi Michael,
On Sun, 30 Sep 2012, Michael Barton wrote:
[...]
The only way to generate a proj4 string interactively is to pick the
appropriate values from a table. When g.proj was still an interactive terminal
module, running it would bring up the lists from these tables to generate a
proper projection.
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.
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.
A nice, clean set of 4 csv files that includes all relevant data (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.
That sounds like a good idea, although it would be a massive amount of
work.
If you can come up with a combination of GRASS and GDAL versions that result in
this behaviour (i.e. g.proj accepts GRASS datum names for the +datum option in
a PROJ.4 string) then I promise to look into it and debug.
The problem is that it no longer works this way
What I was saying was that if you can let me know a certain combination of
GRASS and GDAL versions in which g.proj *does* accept GRASS-specific datum
names for the +datum option in a PROJ.4 string, let me know which versions
and I will investigate. As far as I'm aware up to now it never did work
like that.
Best regards
Paul
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
