[MetaCRS] A Question About The Typical Method Of CRS Transformations

[Landon Blake]

Frank wrote: " I'm afraid I don't really follow the essence of your
question."

I really need to work on my communication skills. I suppose I can take
some small comfort in the realization that this is not a simple subject.

Let me try again to explain a couple of different possible approaches to
CRS transformations:

In the first approach CRS transformations are enabled by adding
executable code to a library. In Java this would be done with an
accepted interface and a plug-in mechanism. In essence, I would add
support for a new CRS by adding a JAR file to a program library.

In this approach, I (as the third-party code) make the library (and
subsequently the user of the library) a promise. This promise
essentially states: "You give me the ordinate values for your coordinate
in some well-known pivot CRS, (like WGS84) and I will perform my black
magic. When my black magic is finished I will return to you a coordinate
whose ordinate values are now based on my CRS."

In this approach the end user, and the library, has no knowledge of the
parameters, or even the type, of subject CRS being supported. Support
for additional CRS definitions is added via this "black box" mechanism.

The other approach is more similar to what you and Martin describe. All
Transverse Mercator Projections share some common geometry. The library
determines that a CRS is based on a Transverse Mercator projection, and
then applies algorithms common to all Transverse Mercator projections
using specific parameters to perform the adjustment.

I hope this makes more sense.

Landon

-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Thursday, May 15, 2008 8:33 AM
To: Landon Blake
Cc: metacrs at lists.osgeo.org
Subject: Re: [MetaCRS] A Question About The Typical Method Of CRS
Transformations

Landon Blake wrote:
> I had a question about the typical method used by existing CRS code in

> different projects to perform transformations from one CRS to another.
> 
>  
> 
> Does most code search for the definition of a transformation
algorithm, 
> with no real knowledge of the projection geometry of the source and 
> destination CRS, to perform the transformation?
> 
>  
> 
> Or does most code, on the contrary, use knowledge of the projection 
> geometry of the source and destination CRS to determine the 
> transformation algorithm on its own?

Landon,

I'm afraid I don't really follow the essence of your question.  As
others
have pointed out it is typical to implement a bunch of particular
projection
methods (ie. Transvere Mercator, Lambert Conformal Conic), that take a
set of
parameters, and then use various sorts of configuration files,
databases, etc
to identify the parameters and method for a particular CRS.

Another thing that *seems* to be suggested by your question is whether
some
systems need to know the extents of the input and output to setup
reprojection.
Generally this is not the case, though in some cases knowing the area
being
operated on could be helpful in automatic selection of the most
appropriate
datum shift (for instance).  I'm generally against this sort of
automatic magic
because it can cause very hard to understand differences, but it is
possible.

But perhaps you were getting at something else?

Best regards,
-- 
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,
http://osgeo.org



Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.