+axis switch to control axis orientation

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

+axis switch to control axis orientation

Frank Warmerdam
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, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

support.mn
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 [[hidden email]] kirjoitti:

> 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, [hidden email]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Zoltan Szecsei
Hi All,
I have not used cs2cs 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.

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?]
I have often received coordinate lists in [true] LatLong order, and also YX (geodetic layout) when actually XY was needed.
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.

[Like I said - I have not fiddled with much of this stuff, but I am assuming one can pipe files through cs2cs - hence defining input coordinate order would be useful]

Hope I'm not off the mark.
Regards,
Zoltan

[hidden email] wrote:
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 [[hidden email]] kirjoitti: 
  
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, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

    

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
  


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Frank Warmerdam
In reply to this post by support.mn
[hidden email] wrote:
> 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?

Janne,

I presume your concern is that it has no effect on the pj_inv() and pj_fwd()
functions.  It is possible to implement support for it within them rather than,
or in addition to in pj_transform() but it would be more complicated for a
few reasons and likely slower since the axis switching decision would need
to be checked for every point rather than once for a whole array of points to
be transformed.

There are already a bunch of services that only apply for applications
going through pj_transform().  These include prime meridian handling
(+pm), datum shifting and alternate longitude wrapping (ie. 0 to 360
instead of -180 to 180).  So I think there is at least a precident for
the operation of the two API entry points being fairly distinct.

In part, I'm trying to keep the functioning of pj_fwd() and pj_inv() as
focused on the projection function as possible, while treating
pj_transform() as a higher level "coordinate system transformations"
function.  One benefit of this is that in theory at some point I could
replace everything from pj_fwd()/pj_inv() down with use of Gerald's new
library while treating pj_transform() and all it's services as a higher
level function that would remain distinct from the low level projections
library.

What do you think?  Is my reasoning at all convincing?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Frank Warmerdam
In reply to this post by Zoltan Szecsei
Zoltan Szecsei wrote:

> Hi All,
> _I have not used cs2cs _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.
>
> 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?]
> I have often received coordinate lists in [true] LatLong order, and also
> YX (geodetic layout) when actually XY was needed.
> 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.
>
> [Like I said - I have not fiddled with much of this stuff, _but I am
> assuming_ one can pipe files through cs2cs - hence defining input
> coordinate order would be useful]

Zoltan,

The cs2cs program actually takes two coordinate system definitions, one for
the source, and one for the destination.  I think your point was allowing
a way to represent the input and output axis order, right?  With this new
capability you could do the following to switch from long/lat to lat/long
ordering:

   cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +axis=neu +datum=WGS84

So I think the ability to attach an axis order to each used coordinate system
definition is sufficient for your needs.

I should however mention that the proj and cs2cs programs already support
the -r and -s commandline switches to switch the x/y order of coordinates
on input and output.  This is done in the program itself rather than down in
pj_transform().  So if we considered cs2cs and proj to be the only important
interfaces to the proj.4 library there would be no real need for +axis.
We could just use those switches.

However, in my humble opinion, the use of proj.4 as a library rather than
as command line utilities is far more important.  So the +axis switch is
an attempt to provide axis control within the library without the
application having to know anything about it.  It is also necessary if
we want to embed axis orientation with the coordinate system definition
in initialization files like the epsg init file.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Datum shift to WGS84 for Dutch coordinate system (EPSG:28992)

Jan Hartmann
In reply to this post by Frank Warmerdam
For all the fans of the official Dutch coordinate system ("Amersfoort",
"Rijksdriehoeksnet", "RD"), EPSG:28992, I finally figured out what the
right codes are in our beloved epsg database, version 4.9, 24 nov 2009.
See text and attached Excel spreadsheet at:

http://trac.osgeo.org/geotiff/ticket/22#comment:3

Comments are appreciated and I'll let you know when the earth changes
form again.

Jan
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Daniel Morissette
In reply to this post by Frank Warmerdam
Hi Frank,

I think that's a good idea. +1

BTW, how do you plan to reflect this in future revisions of the "epsg"
file? Will every definition contain an explicit +axis parameter or will
it be specified only for those that do not use the default (+axis=enu)?
I think it would be best if the epsg file contained an explicit +axis
value for every definition.

This question crossed my mind as I was trying to figure the logic that
would have to be implemented in an application that wants to rely on the
axis order info from the epsg file (for OGC WMS 1.3.0 support for
instance). I guess applications will need to be aware that they are
running against a version of PROJ.4 with +axis support, and in this case
know that it can rely on the presence of the +axis parameter to decide
on coordinate order. However, to make sure things don't break if for
whatever reason the app is still using an old epsg file without +axis
info, it would be better to know that if +axis is absent then we should
not assume the default of "enu" but instead behave as if the information
is not available and either produce a fatal error or fallback on other
mechanisms if any is available. Hence my conclusion that you should
provide +axis explicitly in *all* definitions in the epsg file,
including those that use +axis=enu. (That was hard to explain, hopefully
my comment makes sense to you after a few reads)

Daniel


Frank Warmerdam wrote:

> 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,


--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Frank Warmerdam
Daniel Morissette wrote:
> Hi Frank,
>
> I think that's a good idea. +1
>
> BTW, how do you plan to reflect this in future revisions of the "epsg"
> file? Will every definition contain an explicit +axis parameter or will
> it be specified only for those that do not use the default (+axis=enu)?
> I think it would be best if the epsg file contained an explicit +axis
> value for every definition.

Daniel,

It was my intention to *not* emit a +axis definition for coordinate
systems with the default axis orientation; however, I do not feel
strongly on this topic.

> This question crossed my mind as I was trying to figure the logic that
> would have to be implemented in an application that wants to rely on the
> axis order info from the epsg file (for OGC WMS 1.3.0 support for
> instance).

Currently the epsg init file is still being generated with the
rule not to honour EPSG axis order for geographic coordinate systems.
That is, the default importFromEPSG() rule is used on the OGRSpatialReference
rather than the importFromEPSGA() which will preserve the geographic
coordinate systems axis orientation as defined by EPSG.

If this approach remains unchanged, the epsg init file is still not very
helpful for determining the epsg expected axis ordering.  I'm wondering
if I ought to generate an "epsga" version of the file that explicitly
always follows the epsg axis order conventions.

On a related point, I've been quite quite surprised how often EPSG
defines axis orientations other than easting, northing for projected
coordinate systems.  Translating the pcs.csv file I have found
1072 coordinate systems with non-default axis orientation out of
7051 total projected coordinate systems.  I'm now quite worried that,
like with geographic coordinate systems, we are going to find that
EPSG follows "paper conventions" in it's definition of axis orientation
for many projected coordinate systems even though that does *not*
reflect usage patterns in GIS.

If I just carry through the EPSG axis orientation, I'm worried that
lots of coordinate systems that were in reasonably wide use will
suddenly be broken.  I am not sure how to address this.  I could take
the EPSG/EPSGA approach where I only used the EPSG axis orientation
in exceptional circumstances (like TM south oriented projections) in
the epsg init file, but do use them all the time in the "epsga" file.

 > I guess applications will need to be aware that they are

> running against a version of PROJ.4 with +axis support, and in this case
> know that it can rely on the presence of the +axis parameter to decide
> on coordinate order. However, to make sure things don't break if for
> whatever reason the app is still using an old epsg file without +axis
> info, it would be better to know that if +axis is absent then we should
> not assume the default of "enu" but instead behave as if the information
> is not available and either produce a fatal error or fallback on other
> mechanisms if any is available. Hence my conclusion that you should
> provide +axis explicitly in *all* definitions in the epsg file,
> including those that use +axis=enu. (That was hard to explain, hopefully
> my comment makes sense to you after a few reads)

I see your point though I'm not sure I'm completely convinced this is
the best way for applications to check.  Normally applications don't
actually get to "see" the definition loaded from the epsg init file
and used within PROJ.4.  It might be better if apps just checked the
proj.4 version to decide whether it is likely handling the axis order
issues automatically

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Zoltan Szecsei
In reply to this post by Frank Warmerdam
Frank Warmerdam wrote:
Zoltan Szecsei wrote:
  
Hi All,
_I have not used cs2cs _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.

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?]
I have often received coordinate lists in [true] LatLong order, and also 
YX (geodetic layout) when actually XY was needed.
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.

[Like I said - I have not fiddled with much of this stuff, _but I am 
assuming_ one can pipe files through cs2cs - hence defining input 
coordinate order would be useful]
    

Zoltan,
I think your point was allowing
a way to represent the input and output axis order, right?  
Hi Frank/all,
Yep, sort of.
We have a lot of issues in South Africa because our Gauss Conformal projection is "+ve South", and many GIS packages cannot handle that. Also, I have seen quite a few coordinate files that have been given to me, where the XY Gauss values are represented as YX (ie: distance from Equator in 1st column, and distance from central meridien in second). That too confuses GIS packages and users who are not sufficiently "coordinate literate".
So, without have dug into proj much, I took the opportunity of this "+axis" thread to see if there is an easy way to define both the axis order and the orientation for both the input and output files.

Thanks for your comments.
Kind regards,
Zoltan



_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Gerald I. Evenden
In reply to this post by Frank Warmerdam
My first reaction to the thread was to simply add the basic transformation
matrix to the xy side of the proj system but after looking at

http://en.wikipedia.org/wiki/Transformation_matrix

I think the more general affine matrix would be a better final solution.

+xform=[comma separated array of 4 or 6 real numbers]

4 for transform, 6 for affine.

Note that cos/sin values must be precomputed.

I'm somewhat kidding about the affine. ;-)

--
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Daniel Morissette
In reply to this post by Frank Warmerdam
Frank Warmerdam wrote:
>
> If I just carry through the EPSG axis orientation, I'm worried that
> lots of coordinate systems that were in reasonably wide use will
> suddenly be broken.  I am not sure how to address this.  I could take
> the EPSG/EPSGA approach where I only used the EPSG axis orientation
> in exceptional circumstances (like TM south oriented projections) in
> the epsg init file, but do use them all the time in the "epsga" file.
>

I see your point, I had not thought of those potential side-effects.
Perhaps the EPSG/EPSGA approach would be best then, and apps that want
to use +axis info would read it from the EPSGA file.

--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

support.mn
In reply to this post by Frank Warmerdam
Frank Warmerdam [[hidden email]] kirjoitti:

> [hidden email] wrote:
> > 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?
>
> Janne,
>
> I presume your concern is that it has no effect on the pj_inv() and pj_fwd()
> functions.  It is possible to implement support for it within them rather than,
> or in addition to in pj_transform() but it would be more complicated for a
> few reasons and likely slower since the axis switching decision would need
> to be checked for every point rather than once for a whole array of points to
> be transformed.

I would like to have the support there also since if the user enters the switch
then he also expects to have the effect.

Why would that need to be checked for every point? Just write two different
loops and check it before entering the loop .. or something similar?

Janne

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Frank Warmerdam
[hidden email] wrote:

> Frank Warmerdam [[hidden email]] kirjoitti:
>> [hidden email] wrote:
>>> 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?
>> Janne,
>>
>> I presume your concern is that it has no effect on the pj_inv() and pj_fwd()
>> functions.  It is possible to implement support for it within them rather than,
>> or in addition to in pj_transform() but it would be more complicated for a
>> few reasons and likely slower since the axis switching decision would need
>> to be checked for every point rather than once for a whole array of points to
>> be transformed.
>
> I would like to have the support there also since if the user enters the switch
> then he also expects to have the effect.
>
> Why would that need to be checked for every point? Just write two different
> loops and check it before entering the loop .. or something similar?

Janne,

The pj_inv() and pj_fwd() functions only operate on a single point -
not an array of points like pj_transform(), so there is no loop.

Are you suggesting that we also ought to add prime meridian (+pm),
"latlong as a projection" support (+proj=latlong), and alternative
longitude wrapping (+lon_wrap) support in pj_fwd() and pj_inv() to
provide for fully comparible functionality?  Datum shifting is the
one thing we would not need in these functions that is in pj_transform()
since pj_fwd() and pj_inv() are always operating within the datum same
datum.

If anything, I'd rather just drop the "proj" program, making it an
alias for cs2cs rather than do this sort of change to pj_fwd() and
pj_inv().  Are you concerned about end users of "proj" or developers
who might be using pj_fwd()/pj_inv()?  I'm already trying to discourage
new developers from using pj_fwd() / pj_inv() directly unless they
really know what they are doing.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Mikael Rittri
In reply to this post by Frank Warmerdam
Frank wrote:

> I have tentatively introduced support for a new +axis parameter [...]
> [...]
> ... 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.
  (http://lists.maptools.org/pipermail/proj/2010-February/005111.html )

I like it. The design makes sense, and the syntax is quite readable.

Just my 20 öre,

--
Mikael Rittri
Carmenta AB
SWEDEN
www.carmenta.com

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam
Sent: Monday, March 01, 2010 5:46 AM
To: PROJ.4 and general Projections Discussions
Subject: [Proj] +axis switch to control axis orientation

[-- Text deleted --]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

support.mn
In reply to this post by Frank Warmerdam
Hello,

I am only worried that the new development in proj4 is lost due
to some formal detail?

At least if someone could make a document about the new features
and how to use them? That would be nice. There are many newcomers
that need last time information about the proj4 development.

New features could be separated using new names with improved functions
so that old compilations would continue to be as they were?

Regards: Janne.

-------------------------------------------------------------------------

Frank Warmerdam [[hidden email]] kirjoitti:

> [hidden email] wrote:
> > Frank Warmerdam [[hidden email]] kirjoitti:
> >> [hidden email] wrote:
> >>> 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?
> >> Janne,
> >>
> >> I presume your concern is that it has no effect on the pj_inv() and pj_fwd()
> >> functions.  It is possible to implement support for it within them rather than,
> >> or in addition to in pj_transform() but it would be more complicated for a
> >> few reasons and likely slower since the axis switching decision would need
> >> to be checked for every point rather than once for a whole array of points to
> >> be transformed.
> >
> > I would like to have the support there also since if the user enters the switch
> > then he also expects to have the effect.
> >
> > Why would that need to be checked for every point? Just write two different
> > loops and check it before entering the loop .. or something similar?
>
> Janne,
>
> The pj_inv() and pj_fwd() functions only operate on a single point -
> not an array of points like pj_transform(), so there is no loop.
>
> Are you suggesting that we also ought to add prime meridian (+pm),
> "latlong as a projection" support (+proj=latlong), and alternative
> longitude wrapping (+lon_wrap) support in pj_fwd() and pj_inv() to
> provide for fully comparible functionality?  Datum shifting is the
> one thing we would not need in these functions that is in pj_transform()
> since pj_fwd() and pj_inv() are always operating within the datum same
> datum.
>
> If anything, I'd rather just drop the "proj" program, making it an
> alias for cs2cs rather than do this sort of change to pj_fwd() and
> pj_inv().  Are you concerned about end users of "proj" or developers
> who might be using pj_fwd()/pj_inv()?  I'm already trying to discourage
> new developers from using pj_fwd() / pj_inv() directly unless they
> really know what they are doing.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Frank Warmerdam
[hidden email] wrote:
> Hello,
>
> I am only worried that the new development in proj4 is lost due
> to some formal detail?
>
> At least if someone could make a document about the new features
> and how to use them? That would be nice. There are many newcomers
> that need last time information about the proj4 development.

Janne,

I'm a bit lost with regard to what you want.  It is my intention to document
the +axis at:

   http://trac.osgeo.org/proj/wiki/GenParms

 > New features could be separated using new names with improved functions
 > so that old compilations would continue to be as they were?

The +axis feature should have no impact on those using the library who do
not incorporate +axis into their coordinate system descriptions.

Perhaps you can explain a bit more if this does not satisfy your needs?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

support.mn
In reply to this post by Frank Warmerdam
Hello,

> I'm a bit lost with regard to what you want.  It is my intention to document
> the +axis at:
>
>    http://trac.osgeo.org/proj/wiki/GenParms
>

Ok, I was thinking those proj4 standard documents in pdf format. Somebody
should add somthing to those? But if it is already on a web page it should be
simple to take a pdf print out. There is a need for a complete single document
(or set of documents) that cover all (also the latest) details. Just add a pdf (print
out) to those there are?

I would edit a complete proj4 single pdf document out of those there are and
update it regulary as new versions come out. Now the documentation is here
and there split all over the world.. not a very user friendly approach? (Given
enough time)

>  > New features could be separated using new names with improved functions
>  > so that old compilations would continue to be as they were?
>
> The +axis feature should have no impact on those using the library who do
> not incorporate +axis into their coordinate system descriptions.
>

Yes, that works also.

Regards: Janne

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Frank Warmerdam
[hidden email] wrote:

> Hello,
>
>> I'm a bit lost with regard to what you want.  It is my intention to document
>> the +axis at:
>>
>>    http://trac.osgeo.org/proj/wiki/GenParms
>>
>
> Ok, I was thinking those proj4 standard documents in pdf format. Somebody
> should add somthing to those? But if it is already on a web page it should be
> simple to take a pdf print out. There is a need for a complete single document
> (or set of documents) that cover all (also the latest) details. Just add a pdf (print
> out) to those there are?
>
> I would edit a complete proj4 single pdf document out of those there are and
> update it regulary as new versions come out. Now the documentation is here
> and there split all over the world.. not a very user friendly approach? (Given
> enough time)

Janne,

The problem is that the original documents are not available in
an updatable form, and no one has stepped forward to prepare new
comprehensive documentation.  I don't have the time or creativity
to do so.

My inclination is to continue adding material in the Trac web
pages as time permits.  I am not particularly enthusiastic of big
pdf documents for software systems.

I will certainly agree that the PROJ.4 documentation is not in a unified
form any more, and that this is unfortunate.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

Roger Oberholtzer
On Wed, 2010-03-10 at 10:31 -0500, Frank Warmerdam wrote:

> My inclination is to continue adding material in the Trac web
> pages as time permits.  I am not particularly enthusiastic of big
> pdf documents for software systems.

And if you add TracWikiPrintPlugin, you can select wiki pages and have
them printed to a pdf doc, with titles and table of contents.

--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: +axis switch to control axis orientation

support.mn
In reply to this post by Frank Warmerdam
Hello,

Frank Warmerdam [[hidden email]] kirjoitti:

> I am not particularly enthusiastic of big
> pdf documents for software systems.
>

Yes, I agree. I would also shrink the documentation to absolute minimium
with lot of examples and divide it to two pieces: One pdf for the end user
who just needs information about the definition matters and the (larger) one
for the implementer who needs to know how to write programs with it.

> I will certainly agree that the PROJ.4 documentation is not in a unified
> form any more, and that this is unfortunate.
>

Sure, it can be on a web page and then just take pdf print outs of it as
required.

Regards: Janne

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj