geod is lat,lon; proj is lon,lat

[jidanni]

proj's default output order is lon,lat:

$ echo 121 24|proj +proj=tmerc|proj +proj=tmerc -I
121dE   24dN

proj also has

       -r     This  options reverses the order of the expected input from lon‐
              gitude-latitude or x-y to latitude-longitude or y-x.

       -s     This options reverses the order of the output from x-y or longi‐
              tude-latitude to y-x or latitude-longitude.

geod's only input order is the opposite: lat,lon.

Nor does geod have any switches like proj, to deal with even proj's
default output order. So one needs proj -s...

One would think programs packaged together would be more coordinated.

(Yes we can use perl etc. if needed to fix the order before piping it
into geod.)

Anyway perhaps acknowledge the situation on the geod man page.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jidanni]

Doesn't anybody have any opinions?

[jidanni]

By the way, don't add a -r to geod, as it would then be the opposite of proj's.
Add a --lola, for longitude/latitude.

[busstoptaktik]

Doesn't anybody have any opinions?

It's hard to argue against historical reasons.

We could correct the unconventional input order of proj to fit the conventional one of geod, but it would probably be quite annoying for a lot of people using proj the way it was originally conceived by Jerry Evenden, i.e. as a Unix style filter, typically embedded deeply into the dark caves of shell scripts, not touched by human hands for decades.

One (unrecommended) way to resolve this would be to make proj default to the conventional input order (i.e. as if invoked as proj -r) if invoked as some other name (the anadrome jorp would be the logical choice).

This would mimic exactly the existing case, where invproj is just proj behaving as proj -I, if argv[0] matches the string constant "invproj".

[jidanni]

Definitely don't rip up the defaults,
of any program, because that would break people's scripts, and create a loss of trust that future scripts will continue to work etc.

So all that needs fixing, is adding a little switch to geod.

The switch, which should not be called -r, would simply add the ability to geod to accept lon lat.

[jidanni]

(In fact, minus r could be added to geod, but it should have parentheses there on the man page saying default.)

And then proj, and cs2cs, could have the same new option added as what is coming to geod, with parentheses on their Man pages saying default.

[jidanni]

That way, via options, users could obtain consistent behavior across every single one of the applications.

Consistent options, consistent behavior!

No more worries about what default is what.

Just like if I mail a letter to 1313 Nerdsburg Heights Rd.

All I need to add is the city, state and zip code, and my worries about where the letter is going are gone.

Something like that.

(Anyway, yes, half of the new options would be no ops, I mean the default.)