[OSRS-PROJ] Interface ideas for Proj4

[Martin Manningham]

Hi, my name is Martin Manningham. I am mainly involved with the OGDI and
I think the PROJ.4 library is a great piece of software. I would like to
be involve someway in this project but first, here are some comments and
ideas about the library.

There is one or two problems with PROJ.4. First, this is difficult to
handle projections and datum with it, the number of possible fields is
long and without the documentation, a user is kind of lost. And how
could we know if the projection we want to use is able to translate from
and to longitude-lattitude coordinates, what are the limitations of the
projection geographically or mathematically? Also, the ability to
translate coordonates from one set to another is not obvious and the
geodetic datum handling is far from perfect.  I think this is important
to provide the most simple API to the user of a library in order to help
him build something quick and nice. We must also think to the people who
want to update this library with their own projection and datum stuff.
These things must be obvious, even without documentation!

This is why I think the best way to start with this library is to keep
the current API backward compatible, but we must create a new API, in
C++, to ease the interactions between the components. The basic object
would be a Projection object that would encapsulate the projection and
datum handling. Two possible constructors, one with the "old" Evenden
string to set the projection, one with only the projection name. Of
course, the parameters are set in object attributes. To perform a
transformation, two projections objects must be completely set and a
function will handle the transformation.

Ex 1:
    EProjection proj1("+proj=longlat");
    EProjection proj2("+proj=utm +zone=13 +ellps=clrk66");

    EProjCoord coord(-47.85,35.567,proj1);   // A coordinate is in a
certain projection
    if (!coord.convert(proj2)) {
        // An error occur...
    }

This is only an example, but it is a lot easier and obvious to
manipulate this kind of objects. In this example, I also describe the
"longlat" projection. In fact, most purist say this is not a projection,
but this is the easiest way to manipulate projections.

Ex 2:
    EProjection utm("utm");
    if (!utm.SetZone(95)) {
         // An error occur, the utm zone is too large
    }
    cout << utm.GetZone();
    cout << utm;  // Display the fields in the utm object in the Evenden
format

In this example, I try to point how the manipulation of the projection
would be a lot easier with that API.

This kind of object structure would be easier to maintain and update. It
is possible to create methods in the projection object to describe a
geographic region where the projection will be valid or less distorded
(utm zone as an example). But this last point is less obvious because in
many situations, even outside the zone, the projection change is still
valid but the distortion is not very important.

Of course, I don't think this kind of thing could be simple to implement
over the PROJ.4 library. But we could implement it first as an interface
to the current C library and then improve it. But it's only an idea, and
ideas require "eyeballs" to improve.

Regards

Martin


----------------------------------------
OSRS PRoject PROJ Discussion List
To Subscribe: send a message to majordomo at remotesensing.org with 'subscribe osrs-proj' in the body
To Unsubscribe: send a message to majordomo at remotesensing.org with 'unsubscribe osrs-proj' in the body
To Report Problems: send a message to owner-osrs-proj at remotesensing.org