<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi All,<br>
<u>I have not used cs2cs </u>and am fairly new to this list, however,
as acceptance/rejection of ideas like Frank's below seems to happen a
lot faster on this list, than I think I will have time to "get into
cs2cs" at the moment, I'd like to add my 2c even though my thoughts may
already be covered by other functionality.<br>
<br>
I would like to suggest that the +axis option also covers the input
value layout (source coordinate). Perhaps this could be done by only
allowing 3 or 6 character options for this parameter. If 6 chars, the
1st 3 apply to the source coordinates. [... but then do we also allow 2
& 4 char values, to cater for when when no Z exists?]<br>
I have often received coordinate lists in [true] LatLong order, and
also YX (geodetic layout) when actually XY was needed. <br>
By allowing +axis to define a non-standard coordinate layout, proj
could save us the time it takes to write a quick filter for the input
file layout.<br>
<br>
[Like I said - I have not fiddled with much of this stuff, <u>but I am
assuming</u> one can pipe files through cs2cs - hence defining input
coordinate order would be useful]<br>
<br>
Hope I'm not off the mark.<br>
Regards,<br>
Zoltan<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:support.mn@elisanet.fi">support.mn@elisanet.fi</a> wrote:
<blockquote
cite="mid:1106316.5427091267433408824.JavaMail.support.mn@elisanet.fi"
type="cite">
<pre wrap="">Hello,
my opinion is that it is an improvement and since it is downwards compatible
it is also very welcome. My only concern is that it only works partially? An user
might expect it to do the hole work but it just did half of it? How could it be
implemented so that all routines used that switch?
Regards: Janne
------------------------------------------------
Frank Warmerdam [<a class="moz-txt-link-abbreviated" href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>] kirjoitti:
</pre>
<blockquote type="cite">
<pre wrap="">Folks,
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.
eg.
cs2cs +proj=latlong +datum=WGS84 \
+to \
+proj=tmerc +ellps=WGS84 +datum=WGS84 +k_0=1 +lon_0=31 +lat_0=0 \
+x_0=0 +y_0=0 +axis=wsu
30.5 -29.5
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
to apply.
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.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, <a class="moz-txt-link-abbreviated" href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>
light and sound - activate the windows | <a class="moz-txt-link-freetext" href="http://pobox.com/~warmerdam">http://pobox.com/~warmerdam</a>
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
Proj mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a>
<a class="moz-txt-link-freetext" href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Proj mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a>
<a class="moz-txt-link-freetext" href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<br>
</body>
</html>