[PROJ] About PROJ.6: Radians or Degrees ?

[Kristian Evers]

I agree that the documenation of this could be better. Suggestions
for improvements are appreciated. Pull requests that improve
the docs are also greatly appreciated :-)

Your conclusions based on your tests are not exhaustive. Is is
possible to have proj_create() return degrees instead of radians
by adding a unitconvert step to a pipeline. Similarly,
proj_create_crs_to_crs() can theoretically return a PJ that outputs
radians instead of degrees (not sure if it actually is the case currently). 

Use proj_angular_input() [0] and proj_angular_output() [1] to determine
what a PJ expects and returns.

The reasons for this somewhat complicated situation is a combination
of backwards compliance and conforming to the ISO19111 standard at the
same time. 

/Kristian

[0] https://proj4.org/development/reference/functions.html#c.proj_angular_input
[1] https://proj4.org/development/reference/functions.html#c.proj_angular_output


-----Oprindelig meddelelse-----
Fra: PROJ <proj-bounces at lists.osgeo.org> På vegne af a.furieri at lqt.it
Sendt: 2. april 2019 09:54
Til: proj at lists.osgeo.org
Emne: [PROJ] About PROJ.6: Radians or Degrees ?

the second glitch I noticed is about some inconsistency
in requiring angular coordinates expressed in Radians
or Degrees.

I always used proj_trans_generic() in SpatiaLite, and
I experienced several strong headaches before guessing
by trial and error what really were the expectations of
PROJ.6 about angular coordinates.
the documentation is very cryptic/incomplete about this
very critical and absolutely relevant detail.
this is what I've discovered after many practical tests:

- if the PJ transformation object has been created by
   proj_create() angular coordinates are expected to be
   passed back and forth converting to/form Radians.
- but (rather surprisingly) if PJ has been create by
   proj_create_crs_to_crs() angular coordinates must
   be passed back and forth directly expressed in
   Degrees; there is no need to convert in Radians.

the real problem is not in this sudden change of
behaviour; it's someway inconsistent and unexpected,
but it's not a big issue once you are well aware
of it.
the real problem is that this absolutely critical
point seems to be completely ignored by the
documentation.
may be that adding a second and third C samples
could be very useful so to clarify any possible
doubt.

bye Sandro
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj