-
Notifications
You must be signed in to change notification settings - Fork 807
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option in proj CLI to use a CRS #3825
Conversation
thanks @jjimenezshaw very useful! |
BTW, I chose |
Perhaps skip the flag and just parse whether it looks like a CRS, rather than a PROJ definition? |
I was just going to suggest the same thing. cs2cs has logic to be able to deal with things like "cs2cs EPSG:foo EPSG:bar" or "cs2cs +proj=... +to + proj=...." automatically. Here I believe that the criterion would be "argvVector.empty() && eargc >= 1", and consider eargv[0] as the CRS code instead of being the first file |
Hum while fixing #3824, I'm wondering what we should do if allowing to pass CRS by codes when they have northing/easting axis order:
Note that the proj utility didn't honour the (now deprecated) +axis= modifier which was a cs2cs / pj_transform() thing and ignored by the pj_fwd() logic . |
I was making myself the same question. Somehow I have a preference to keep the CRS order (to be consistent with the printed pipeline). But it is not very strong opinion. See that the problem is not only with CRS codes (or wkt). If you pass the pipeline with the units or axis order (or anything that is not the "standar" way probably) #3824 still fails (probably you realized that already). |
In case it is not clear: the CRS definition can be anything that works with "from user input". Can be a code, a WKT, a PROJJSON, etc. |
60c2624
to
8ac1a2e
Compare
8ac1a2e
to
5301fdc
Compare
I applied the same criterion as in #3826 for the proj_factors calls (not for the projection calls). |
With the C++ API: CRS::mustAxisOrderBeSwitchedForVisualization() |
Unfortunately the linker does not find it. Anyhow, the check was easy with the C++ object. The output of a northing-easting CRS is something like this:
|
Is there anything missing in this PR? (behavior, feature or documentation) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, but a few minor things should be improved in the docs
docs/source/apps/proj.rst
Outdated
@@ -172,6 +172,13 @@ also used for supporting files like datum shift files. | |||
Usage of *+opt* varies with projection and for a complete description | |||
consult the :ref:`projection pages <projections>`. | |||
|
|||
.. versionadded:: 9.3.0 | |||
|
|||
*{crs}* is one of the possibilities accepted by proj_create(), provided it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*{crs}* is one of the possibilities accepted by proj_create(), provided it | |
*{crs}* is one of the possibilities accepted by :c::func:`proj_create()`, provided it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Further down the page an example using proj with a CRS would be nice as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Following #3824 , to easily apply
proj
on the projection of a projected CRS, this PR adds the option-C
.It follows the same logic as in function
proj_factors
, that is to compute the projection from the CRS to the geographic underlying CRS.This PR does NOT fix #3824.
Example of usage:
docs/source/*.rst
for new API