[PROJ] coordinate order confusion

[Even Rouault]

On jeudi 23 avril 2020 16:03:43 CEST Greg Troxel wrote:
> I'm trying to actually use proj to calculate something, as part of being
> sure about NAD83/WGS84 for imagery available for openstreetmap in
> Massachusetts.  So while I've used proj long ago, mostly I've been
> keeping up with packaging lately and am thus kind of like a new user.
> 
> I read the cs2cs man page (proj 6.3.1), and see
> 
>        -r     This options reverses the order of the expected input from
>               longitude-latitude or x-y to latitude-longitude or y-x.
> 
>        -s     This options reverses the order of the output from x-y or
>               longitude-latitude to y-x or latitude-longitude.
> 
> I want to use "lat lon" (with lon being roughly -71 for 71W), so I gave
> -r and -s.  However, when I do that, and then use invgeod on the input
> and transformed coordinates, I get displacements that seem unreasonably
> large.  Without, they are ok.
> 
> On the  third time through the man page, I see that the coordinate order
> depends on the CRS, and apparently both that I am using are "lat lon"
> 
> So I think the -r/-s descriptions need to be changed, because they state
> outright that without them the order is "longtitude latitude".  It seems
> really it is
> 
>        -r     This options reverses the order of the first two expected
>               inputs from that specified by the CRS to the opposite
>               order.  The third coordinate, typically height, remains
>               third.
> 
> which is quite different, at least as I see it.

Yes the text of man page dates pack to pre-PROJ 6 era where CRS axis order for geographic 
was always (except when +axis= was used) longitude, latitude. Your suggestion sounds good. 
Please submit a pull request with it (to the .rst file)

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200423/256ec286/attachment.html>