[GRASS5] Re: [Proj] Continuing confusion of datums vs. projections

[Michel Wurtz]

I just wanted to say that you cannot propose a GIS without offering a
*correct* function to transform a map from one coordinate system to
another one, even if the Datum involved is not the same.  The problem
is not "should we develop this as internal or external library" : that
doesn't matter.  The problem is "I have many sources of data, with an
accuracy of a few meters.  I want to display/compare/mix/analyse them
together.  My GIS should manage that".

So the coordinate transformation functions must take care of datums.

If Grass can't do that, Gras is unusable for a vast majority of application,
and we will not have any usable open-source GIS that can stand in front of
ArcView, MapInfo, GeoConcept and other commercial GIS softwares...

Gerald Evenden wrote:
> Sorry, but I have been through this issue several times but I see it is still
> necessary to reiterate my position: cartographic projections are a subject
> area unto themselves and have *no* relationship to datums nor other
> aspects of common cadastral and geodetic activities.  One can spend
> their entire life studying and developing cartographic projections and
> not have one whit of knowledge of datums nor how to manipulate them.
> 
> I take John Snyder as an excellent example: he wrote many articles and
> books related to cartographic projections.  He created new projections.
> He was recognized as a world class expert on cartographic projections.
> However, you do not need to take your shoes off to count the number
> of paragraphs he wrote on datum operations.  In fact, I cannot think
> of one case other than his listing of the projection parameters for
> both NAD27 and NAD83.  Surely, Snyder may have been aware of
> datum shifting and how to do it but he did not seem to include it in
> his research activities.
> 
> Surely, projections are required in the practical world of cadastral and
> geodetic activities, but so are sine and cosine and a bunch of other
> transcendental functions.  The software development business
> normally compartmentalizes solutions by individuals specializing
> in solving different parts of a larger problem with the result of a
> collection of libraries that are linked together to produce a more
> general application program that utilizes a wide area of disciplines.
> 
> Lastly, the argument that because the major axis and eccentricity are
> major details of a datum and that they are required by a projection, 
> then the 
> projection should be included as part of a datum library just obfuscates
> the issue.  This whole subject area uses the sine function in many
> places---does that mean that we have to include the sine function in a
> cadastral library?  I think not.
> 
> I am sorry to bore y'all but I think this is an important issue and needs
> to be understood.
> _____________________________________
> Jerry and the low riders: Daisy Mae and Joshua
> 
> 


-- 
Michel Wurtz - Auzeville-Tolosane