[OSRS-PROJ] Interface ideas for Proj4

[Martin Manningham]

Frank Warmerdam wrote:

> 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.
>

Great, I am sure that will improve the library. Will it be new API functions?


>
> 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,

Sound ok for me. Good plan.

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