[OSRS-PROJ] Interface ideas for Proj4

[Martin Manningham]

"Gerald I. Evenden" wrote:

> Sorry, I'm jumping into an ongoing discussion so I may be
> a little out of context but I felt I needed to add some
> material.  See below.
>
> Jerry Evenden and the low riders: Katie and Daisy-Mae
> gevenden at capecod.net  http://www.capecod.net/~gevenden
> -----Original Message-----
> From: Martin Manningham <martinm at six.net>
> To: osrs-proj at remotesensing.org <osrs-proj at remotesensing.org>
> Date: Tuesday, March 28, 2000 6:28 PM
> Subject: Re: [OSRS-PROJ] Interface ideas for Proj4
>
> >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?
>
> Oh boy!  This is part of the reason I added the -V option---to allow the
> user to examine some of the details of transformation such as scale
> factor and other distortions.  In general, knowing the proper use
> and limits of a cartographic projection requires looking at the literature,
> consulting with a guru and/or projection experience.
>
> >> >                        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!
>
> Personally, I can't program without documentation.  If I want to use some
> function or construct that I don't normally employ, I have to get the book
> and do a little studying.  And that's with a subject I am active with.
> With an occassional operation, as suggested above, I would not think of
> not having documentation for referral.
>
> Doesn't "quick and nice" mean "sloppy and error prone."
>
> I also do not
> know what you mean by "their own projection."  Are you saying their
> own parameters for a particular projection or their own mathematical
> definition of a projection?  Or both?
>
> >> 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.
>
> PROJ.x was never designed to be a datum
> system.  The NAD material added was because of the parochial interests
> of the USGS and represented an example of how the PROJ.4 library
> could be used in a simple US datum conversion program.  Non-US datums
> and other coversion methods were not considered especially because
> the author (me) did not have access to reliable sources of information
> regarding foreign conversions (particularly the constants associated
> with them).  I get a little nervious when I hear PROJ.4 being considered
> a datum conversion system.
>     ...
> >> 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 wish I knew what you meant here.
>     ...
> >> 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 don't understand to what end.
> >>
> >> I suppose it is also hard to work out areas of applicability for
> projections
> >> though this isn't something I had thought to address.
>
> I'm foggy as what you're driving at also. ;-)
>     ...
> >> > 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.
>
> I presume you're talking about the Equirectangular.  It is certainly a
> simple projection, but a projection none the less.  I don't see how it
> "manipulates" projections.??
>
> >> >
>
>     ...
>
> I'm skipping the rest of the stuff as it is for C++ programmers and
> far, far too inscrutable for this humble C programmer.
>
> With my historical interest in the PROJ.4 system, I can't help but
> have some distress about the binding of datum conversions with the
> package.  For me, datums are the property of the geodesists and
> have nothing to do with cartographic projections other than providing
> the data for the elliptical constants employed.
>
> Lastly, I don't want to get into any brouhaha about anything. I just
> contributing my observations.
>
> ----------------------------------------
> 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

This is quite interesting to read this kind of view of what must be projection transformation. And I think
you got a point about the mixing of projection change and datum handling in this library.

The main problem with datum is many organisations want so much precision in the coordinates handling they
even consider the continental shift in the calculations of a map. Many people in the discussion are
handling both domains (datums and projections) and some of them think there should be a way to merge these
two concepts. I don't pretend to have the perfect solution to that problem, but of what I heard in that
discussion is these concepts must be fused outside PROJ.4 (if they had to be fused), maybe in C++ but
certainly with a more global vision of the differents interests involved.

But your concerns are more than important and serious thinking must be done before going too far in the
idea. And you are right about the "brouhaha", a lot of different conceptions of how the library from many
differents kind of users in differents kind of fields using this library are discussing here. And also my
english is far from perfect, I have to apologise about that.

Regards

Martin Manningham



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