[PROJ] Proj6 Docs

[Kristian Evers]

Paul,

This is not related to you question but you mentioned in a previous mail that you
weren’t sure how to use PJ_FWD/PJ_INV in relation to proj_angular_input/output.
I noticed that in your gist you are probably not doing what you want. You have:

	int ango = proj_angular_output(pj, PJ_FWD);
	int angi = proj_angular_input(pj, PJ_INV);

ango and angi will always be the same in this code. The reason being that you
in the first line ask what type of output unit is produced in the FORWARD
transformation direction and in the second line you ask for the unit of the
input in the INVERSE direction. The second function call is basically a
double-negation of the first. Let me explain. Say you have a simple transformation
such as a UTM-projection. In the forward direction your transformation
looks something like:

	latlong -> UTM

This takes angular input and outputs projected coordinates. In the INVERSE
transformation direction you have:

	UTM -> latlong

which takes projected coordinates as input and the output comes in angular units.

This can also be demonstrated with proj:

$ echo 12 56 | proj +proj=utm +zone=32
687071.44	6210141.33

$ echo 687071.44 6210141.33 | proj -I +proj=utm +zone=32
12dE	56dN

In your code this translates to ango==angi==0 since both call will check the units
of the UTM coordinates. 

The idea behind PJ_FWD/PJ_INV is that it is much simpler to do the inverse
transformation by switching the direction than to initialise a new PJ that goes
in the opposite direction. 

I hope this clears things up.

/Kristian


> On 16 Feb 2019, at 22:40, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> 
> 
>> On Feb 16, 2019, at 12:30 PM, Even Rouault <even.rouault at spatialys.com> wrote:
>> 
>>> Hum. Right now I’m creating and caching the result of
>>> proj_create_crs_to_crs(). If I get two PJ from proj_create() is there a way
>>> to create an “optimum pipeline” ala proj_create_crs_to_crs() using two PJ
>>> as the start/end points, instead of two strings?
>> 
>> 2 options:
>> - you export your PJ objects as wkt with proj_as_wkt() and feed that to 
>> proj_create_crs_to_crs()
>> - or you emulate most of what proj_create_crs_to_crs() does, which is 
>> essentially using proj_create_operations() which takes 2 PJ objects (of type 
>> CRS):
>> https://github.com/OSGeo/proj.4/blob/master/src/4D_api.cpp#L1010
>> 
>> 
>>>> Or, after the commit I just pushed, you can extract the source CRS from
>>>> the
>>>> pipeline with proj_get_source_crs() (but only if you've created the
>>>> pipeline with proj_create_crs_to_crs(). Not if you created it with
>>>> proj_create("+proj=pipeline ...") )
>>> 
>>> Any chance you could also add proj_get_dest_crs() to pick the CRS off the
>>> end of a pipeline? 
>> 
>> Ah, that was implied that my changeset also fixes the dest part of course.
> 
> Ah, I see! I cannot get it to work though, I am trying this:
> 
> https://gist.github.com/pramsey/22127622023e88cd415cd1524db0a285#file-proj-c-L19-L24
> 
> And getting:
> 
>  proj_get_source_crs: Object is not a BoundCRS or a CoordinateOperation 
>  proj_get_target_crs: Object is not a BoundCRS or a CoordinateOperation
> 
> What’s my mistake?
> 
> P
> 
>> 
>> Even
>> 
>> -- 
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
> 
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj