[Proj] datum matters

Paul Kelly paul-grass at stjohnspoint.co.uk
Sun Mar 29 12:38:07 EST 2009


On Sun, 29 Mar 2009, Richard Greenwood wrote:

> I do however, still advocate "conflating"
> projection and datum. EPSG seems to have done it, many of the proj
> users do it without knowing it. So let's do it right.

I think the sentiment to "do it right" is the key point of contention 
here. As I see it, it has been the consensus on this list for several 
years that the way the existing PROJ.4 does this "conflation" is not the 
best. Indeed PROJ.4 maintainer Frank W has stated several times that it is 
his long-term intention to refactor the library into a separate 
"mathematically pure" core (my words not his), probably based on Gerald's 
libproj4, with a separate level of abstraction on top of that supporting 
the "less exact" science of co-ordinate system and datum conversions. I 
don't think anybody has ever seriously disagreed that that was not the 
best way forward, hence why any suggestion that the current slightly messy 
way (again my opinion) that projections and co-ordinate systems are mixed 
in the pj_transform() API is a great idea and the way we should all be 
doing things is bound to cause a bit of contention ;)

If I may be permitted to stir things up by adding another bit of my own 
personal opinion here, Gerald has not done himself any favours in support 
of use of his libproj4 as a mathematically pure core projection library by 
his ambivalent attitude towards the inclusion of improved mathematical 
algorithms for some projections - I'm thinking particularly of the recent 
discussion on transverse mercator algorithms and Charles Karney's improved 
version, and Gerald's defence that the existing versions were "good 
enough" for all reasonable uses of the projection. IMHO the discussion of 
what is a reasonable use and the the choice of projection algorithm for a 
particular co-ordinate system belongs in the abstracted co-ordinate system 
library, not the core projection library. (I realise of course that there 
are several different versions of the tmerc algorithm already and I'm 
stetching the issue a bit to make a point, but I do feel that it's a valid 
point).

Just a couple of thoughts anyway...

Paul


More information about the Proj mailing list