[OSRS-PROJ] Interface ideas for Proj4

[Gerald I. Evenden]

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