[OSRS-PROJ] prime meridians

[Gerald Evenden]

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.

Secondly, the  u-v results of the library entries are relative to the user's
definition of the geographic origin.  Similarly, the users defines the units
of the cartesian data by his definition of the geodetic radii.  There is
conversion of x-y for cases where the geodetic units are in meters and
the user wants x-y in some other metric.

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.

I don't object to the simple filter function of adjusting longitude but I
do strongly object to the statement that any part of the PROJ.4 system
has any knowledge of a "Prime Meridian."  It does seem strange
to me that someone would use the Paris meridian and then crank
geographic coodinates thru the system that were *not* in the Paris
meridian system.  If everything is relative to the Paris meridian one
would use proj in a maner identical to, say, US usage.  That is, the
French live in a different world than the English, but proj functions
without change in both worlds (except for lack of French language
manuals ;-) ).

Frank Warmerdam wrote:

> Folks,
>
> I have introduced a form of prime meridian support to PROJ.4.  The
> +pm=<prime_meridian> option can be used to set a prime meridian.  The
> argument can be a longitude (relative to Greenwich) or the name of
> a well known prime meridian.  These can be listed with the -lm flag:
>
> warmerda at gdal[317]% cs2cs -lm
>     greenwich 0dE
>        lisbon 9d07'54.862"W
>         paris 2d20'14.025"E
>        bogota 74d04'51.3"E
>        madrid 3d41'16.48"W
>          rome 12d27'8.4"E
>          bern 7d26'22.5"E
>       jakarta 106d48'27.79"E
>         ferro 17d40'W
>      brussels 4d22'4.71"E
>     stockholm 18d3'29.8"E
>        athens 23d42'58.815"E
>          oslo 10d43'22.5"E
>
> The prime meridians are applied within pj_transform() so that if the
> input or output coordinate system is proj=latlong with a prime meridian
> set the longitude will be offset accordingly.  The prime meridian does
> not effect pj_fwd() and pj_inv() all. The u and v results from these
> functions will always be relative to Greenwich.  So (by association)
> the prime meridian will have no effect on the proj program, it is
> only utilized in cs2cs (based on pj_transform()).
>
> When I generate the new epsg init database I will be including non
> greenwich meridians where appropriate.
>
> I also looked at implementing an angular units option but decided
> against it in the end.  Currently PROJ.4 input/output angles are all
> radians, and it is up to the client programs (including proj and cs2cs)
> to convert to degrees or other units if they wish.  Therefore I don't
> feel it appropriate for the proj.4 core to "known" about coordinate
> system angular units.  I have implemented support for angular units in
> my OGRCoordinateTransformation wrapper around PROJ.4.
>
> Let me know if there are any questions.

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