[OSRS-PROJ] prime meridians

[Gerald Evenden]

I apologize for part of the problem as it is of my own making.

PROJ.4 was a cartographic projection system.  My error was to include
some datum shifting material that was useful to my local users at
the time of distribution.  The material was *very* parochial and not properly
designed for global applications partly because *very* little information about the
general world condition in this field was readily available in my local,
backwoods environment.  This unfortunate inclusion NGS US datum
conversion code probably started the concept that PROJ was also a datum handler.

What you people are doing involves general handling of geographic data
in all kinds of environments and where cartographic projection is only
part of the activity.  It would make sense to me if you call your
package something more meaningful than PROJ, something that would
more truly indicate the scope of your operations.  For example, you
might be using Prostgres to manage your data storage and retrieval
but you would not call the overall system Postgres.

My problem is that I still think of PROJ in its original form, a cartographic
projection function and thus react to functions that are outside of my
concepts of what the system should perform.

Frank Warmerdam wrote:

> Gerald Evenden wrote:
> > First, and I think a very important point, PROJ does not know of the
> > existance of a "Prime Meridian."  Input longitude is always relative to
> > a user define origin and may be offset with the built in "lon_0" option.
> > I do not see where specifying a prime meridian is anything more than
> > redefining lon_0.
>
> Gerald,
>
> As Cliff points out, the primary reason for tacking on a distinct
> concept of prime meridian is so that coordinate system to coordinate
> system conversions can be done within the API.  This is outside the original
> scope but a part of what I am trying to accomplish with pj_transform() ...
> which is intended to have the ability to translate between any two
> coordinate systems (with lots of limitations of course).
>
> Now it is  practical to translate coordinates between coordinate systems with
> different prime meridians.  You can dispute whether coordinate system
> to coordinate system translation belongs in PROJ.4, but at this point
> it is part of my goals for the library, and the least I can do is try
> and do it well.
>
> > As for radian input, that applies to the library calls that emulate other
> > math function calls that employ radian input (ie. sin, cos, tan, ...).  Program
> > proj allows for conversion of variants of DMS to and form radians as
> > well as binary radian I/O.
>
> This is correct of course, but when I talk about capabilities I am mainly
> looking at the API level which is what is used in the various environments
> like GRASS, MapServer, OGDI and OGR.  The commandline programs are useful but
> not the way that most interaction with "PROJ.4" occurs.
>
> Best regards,

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.