[OSRS-PROJ] Interface ideas for Proj4

[Frank Warmerdam]

Martin,

It is great to have you involved!

Martin Manningham wrote:
> 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!

To the best of my knowledge the only datum support in PROJ is the NADCON
based NAD27/NAD83 conversions.  I would like to incorporate support for
7 parameter Bursa-Wolf datum transformations, and perhaps introduce a 
support file associating "datum names" with translation coefficients.  
This could be populated from the EPSG database, and then perhaps augmented
from other sources.

I have already done some work to this end in my higher level "OGR" 
spatial reference code.  If it works and there is broad interest I could
incorporate it into PROJ. 

On the point of projection documentation, Martin is right that it is hard
to get the information to formulate projections.  The PostScript documents
written by Gerald are good, but even when you browse them them, it is often
hard to figure out what "implied" parameters are available for whole families
of projections.  I have done some work in creating a catalog of projections
on the GeoTIFF web site, and included with these a "PROJ.4 formulation" 
as well as relating them to GeoTIFF, EPSG and OpenGIS Well Known Text.  This
is available at:

  http://www.remotesensing.org/geotiff/proj_list/index.html

About half a year ago I spoke to Gerald Evenden about getting the LaTeX
source for his papers, but it seems his methodology for handling all the
figures was involved, and that the documents are not easily processed 
elsewhere.  I think I will approach him again about getting at least the 
.tex files. 

I suppose it is also hard to work out areas of applicability for projections
though this isn't something I had thought to address.
 
> 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.

The general idea is good.  For various projects of my own I have been working
on OpenGIS inspired C++ classes for coordinate system handling.  Some 
documentation of these can be found at:

http://gdal.velocet.ca/projects/opengis/ogrhtml/class_ogrspatialreference.html
http://gdal.velocet.ca/projects/opengis/ogrhtml/osr_tutorial.html

In this case my normative description for projections is OpenGIS Well Known
Text format, but internally I convert to PROJ.4 string representation in order
to have the projection work done by PROJ.4.  The class includes methods to
initialize projections from EPSG databases, well known text or to setup by
a number of method calls on the object. 

While use it's quite as convenient as Martin described above, the idea is
similar, and it could be fine tuned somewhat. 

However, I am somewhat concerned about adopting a radical new C++ API for
PROJ.4.  As Jan points out, C++ can be off putting for some developers.  I 
have seen projects where extensive use of STL (the Standard Template Library),
overloading, multiple inheritance and other esoteric C++ features made 
particpation by more mundane programmers such as myself quite difficult.  
Furthermore, use of cutting edge features carries a cost in portability, and
any use of C++ will generally lead to difficulties in exporting the API from
a shared library or DLL to other applications due to complex, and ever changing
name mangling schemes. 

On the other hand, I am currently working on a project mostly written in C
and using Gtk.  Gtk implements object semantics in C and in my opinion it is
a bloody mess.  Stuff that would be so natural in C++ is a mess of macros and
casting in C. 

The C/C++ issue aside, I think we should also consider how much we want to 
step away from the existing PROJ.4 methodology.  My suggestion is:

 o We incorporate datum shifting and "projection dictionary lookup" into the
   existing PROJ.4 C API. 

 o We work on the OGRSpatialReference and OGRCoordinateTransformation C++ 
   classes as a higher level API hosted on top of PROJ.4.  I could even 
   separate them out of their current source tree, and have them be distributed
   with PROJ.4 if that is deemed to be desirable.

Alternatively we could develop a C API that does approximately what Martin
suggests,
but without C++. 

I would also caution against setting ourselves goals that are too ambitious. 
Putting out a PROJ.4 release with broader datum support, and improved online
documentation would be a good first project.  

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda at home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent
----------------------------------------
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