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

[Paul Kelly]

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