[Proj] +axis switch to control axis orientation
warmerdam at pobox.com
Sun Feb 28 23:46:09 EST 2010
As part of an effort to support the transverse mercator south orientated
based coordinate systems as well as a few other coordinate systems with
unusual axis orientations I have tentatively introduced support for a new
+axis parameter for coordinate systems in PROJ.4 (the OSGeo version).
The +axis switch takes three character arguments defining the axis
orientation of the coordinate system. The possible values are:
'e' - easting
'w' - westing - an x/longitude with the opposite sign to normal.
'n' - northing
's' - southing - a y/latitude with the opposite sign to the normal.
'u' - up - normal z
'd' - down - a z/elevation with the opposite sign to the normal.
So, a normal coordinate system is defined as "+axis=enu". This is the
default and it may be omitted in the normal case. Some variations:
"end" - Normal in x/y but the Z is a depth rather elevation.
"neu" - reversed x/y axes, for instance +proj=latlong +axis=neu would truely
be a latitude/longitude coordinate system.
"wsu" - A coordinate system with the sign of x and y negated as is used
for transverse mercator south orientated.
I have committed preliminary support for this switch in PROJ.4 trunk. I
should note that the axis switching is done on entrance to pj_transform()
and (in reverse) on exit. So applications, like proj, that call pj_fwd()
and pj_inv() directly will ignore the axis orientation just as they ignore
the prime meridians, and datum shifts. However, programs that do use
pj_transform() - like cs2cs - will utilize the axis orientation switches.
cs2cs +proj=latlong +datum=WGS84 \
+proj=tmerc +ellps=WGS84 +datum=WGS84 +k_0=1 +lon_0=31 +lat_0=0 \
+x_0=0 +y_0=0 +axis=wsu
48483.46 3264793.45 0.00
Though this is already in trunk, I am seeking feedback from the community
on the approach. Whether it seems sufficiently general for other possible
uses, and whether the naming seems reasonable.
I should note that anyone who feels that non-projection coordinate system
services (like datum shifts, etc) do not belong in PROJ.4 need not feel
obligated to make that point again in reference to +axis. It can be assumed
If there is no widespread outcry against this functionality, I will
document it properly and make modifications to the mechanisms for
generating the epsg init file to take advantage of it.
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the Proj