[PROJ] Proj6 Docs

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROJ] Proj6 Docs

Paul Ramsey
Hi all,
I apologize for list spamming, I guess I'm just impatient to get proj6
support into PostGIS :)

I did up a little test program to try and learn more about how to do
this in the large in PostGIS, and I'm kind of confused with the many
forms "PJ" can take...

https://gist.github.com/pramsey/22127622023e88cd415cd1524db0a285

When I run the program, I get

proj_crs_get_coordinate_system: Object is not a SingleCRS
proj_cs_get_axis_count: Object is not a CoordinateSystem
axis_count = -1

So... my PJ is a full pipeline, I guess, since it came from
proj_create_crs_to_crs().
But how do I extract the first SingleSRS from the pipeline? The last?
(I'll only be doing two-system pipelines in my use case.)

Are the proj6 docs built out anywhere online? Do they address this?

P.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Even Rouault-2
Paul,

Answering this question and the one about X/Y order.

Yes PJ objects can be of different kinds and do not all play well with all
functions.

proj_crs_get_coordinate_system(), as the name implies, expects a PJ object of
type CRS, but proj_create_crs_to_crs() returns a PJ object of type Coordinate
Operation / pipeline

So you should call proj_crs_get_coordinate_system() on the result of
proj_create("EPSG:4326") instead.

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 ...") )

Regarding the proj6 docs, they will be online as soon as it is promoted. You
can build them locally with "make html" in the docs/ directory. The output
will be in docs/build/html/

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Paul Ramsey


> On Feb 16, 2019, at 10:24 AM, Even Rouault <[hidden email]> wrote:
>
> Paul,
>
> Answering this question and the one about X/Y order.
>
> Yes PJ objects can be of different kinds and do not all play well with all
> functions.
>
> proj_crs_get_coordinate_system(), as the name implies, expects a PJ object of
> type CRS, but proj_create_crs_to_crs() returns a PJ object of type Coordinate
> Operation / pipeline
>
> So you should call proj_crs_get_coordinate_system() on the result of
> proj_create("EPSG:4326") instead.

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?

> 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? Then I’d be able to read off the two things I need from the pipeline PJ I already have in my cache...

> Regarding the proj6 docs, they will be online as soon as it is promoted. You
> can build them locally with "make html" in the docs/ directory. The output
> will be in docs/build/html/

Thanks!

P

>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Even Rouault-2
> 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.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Paul Ramsey


On Feb 16, 2019, at 12:30 PM, Even Rouault <[hidden email]> 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:


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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Even Rouault-2
> 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
> <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?

Ah... That gets tricky becase EPSG:3005 uses NAD83 datum, and there's no single transformation path from WGS84 to NAD83

If you add
printf("definition: %s\n", proj_pj_info(pj).definition);

you'll see in the output:
definition: unavailable until proj_trans is called

And if you do:

$ src/projinfo -s EPSG:4326 -t EPSG:3005 --spatial-test intersects -o PROJ

you'll see:

-------------------------------------
Operation n°1:

unknown id, Inverse of NAD83 to WGS 84 (1) + British Columbia Albers, 4 m, North America - Canada and USA (CONUS, Alaska mainland)

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80

-------------------------------------
Operation n°2:

unknown id, Inverse of NAD83 to WGS 84 (41) + British Columbia Albers, 1 m, USA - Oregon and Washington

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=WO +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80

-------------------------------------
Operation n°3:

unknown id, Inverse of NAD83 to WGS 84 (20) + British Columbia Albers, 1 m, USA - Idaho and Montana - west of 113°W

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=wmhpgn.gsb +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80

-------------------------------------
Operation n°4:

unknown id, Null geographic offset from WGS 84 to NAD83 + British Columbia Albers, unknown accuracy, World

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80

-------------------------------------
Operation n°5:

unknown id, Inverse of NAD83 to WGS 84 (8) + British Columbia Albers, 1 m, Canada - Alberta

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=AB_CSRS.DAC +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80


So proj_create_crs_to_crs() see that there are several potential transformation and keep the list internally.
When proj_trans() is invoked it picks up the most appropriate transformation from the above according to the current coordinate value.
So in that case, the PJ object is in a rather particular state and has no proper single CoordinateOperation stored, but a list of candidates that is hidden from the API.
I could potentially fix proj_get_source/target_crs() to properly behave in that situation
since all candidate transformations share the same source and target SRS. Perhaps I should
since the above explanation are probably just an implementation detail for your use case ?

Even


--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Paul Ramsey


> On Feb 16, 2019, at 1:56 PM, Even Rouault <[hidden email]> wrote:
>
>> 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
>> <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?
>
> Ah... That gets tricky becase EPSG:3005 uses NAD83 datum, and there's no single transformation path from WGS84 to NAD83
>
> If you add
> printf("definition: %s\n", proj_pj_info(pj).definition);
>
> you'll see in the output:
> definition: unavailable until proj_trans is called
>
> And if you do:
>
> $ src/projinfo -s EPSG:4326 -t EPSG:3005 --spatial-test intersects -o PROJ
>
> you'll see:
>
> -------------------------------------
> Operation n°1:
>
> unknown id, Inverse of NAD83 to WGS 84 (1) + British Columbia Albers, 4 m, North America - Canada and USA (CONUS, Alaska mainland)
>
> PROJ string:
> +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80
>
> -------------------------------------
> Operation n°2:
>
> unknown id, Inverse of NAD83 to WGS 84 (41) + British Columbia Albers, 1 m, USA - Oregon and Washington
>
> PROJ string:
> +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=WO +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80
>
> -------------------------------------
> Operation n°3:
>
> unknown id, Inverse of NAD83 to WGS 84 (20) + British Columbia Albers, 1 m, USA - Idaho and Montana - west of 113°W
>
> PROJ string:
> +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=wmhpgn.gsb +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80
>
> -------------------------------------
> Operation n°4:
>
> unknown id, Null geographic offset from WGS 84 to NAD83 + British Columbia Albers, unknown accuracy, World
>
> PROJ string:
> +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80
>
> -------------------------------------
> Operation n°5:
>
> unknown id, Inverse of NAD83 to WGS 84 (8) + British Columbia Albers, 1 m, Canada - Alberta
>
> PROJ string:
> +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=AB_CSRS.DAC +step +proj=aea +lat_0=45 +lon_0=-126 +lat_1=50 +lat_2=58.5 +x_0=1000000 +y_0=0 +ellps=GRS80
>
>
> So proj_create_crs_to_crs() see that there are several potential transformation and keep the list internally.
> When proj_trans() is invoked it picks up the most appropriate transformation from the above according to the current coordinate value.
> So in that case, the PJ object is in a rather particular state and has no proper single CoordinateOperation stored, but a list of candidates that is hidden from the API.
> I could potentially fix proj_get_source/target_crs() to properly behave in that situation
> since all candidate transformations share the same source and target SRS. Perhaps I should
> since the above explanation are probably just an implementation detail for your use case ?

Yes, I’m only looking for source/target so I can figure out if I need to do an axis swap before (or after) feeding the transformation. Is there a decent way to stick a swap directing onto the end/start of the transformation so I get it “for free” when I run proj_trans?

P


>
> Even
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Even Rouault-2
> > Perhaps I should since the above explanation are probably
> > just an implementation detail for your use case ?

OK, fix just pushed.

> Yes, I’m only looking for source/target so I can figure out if I need to do
> an axis swap before (or after) feeding the transformation. Is there a
> decent way to stick a swap directing onto the end/start of the
> transformation so I get it “for free” when I run proj_trans?

That would involve hand editing the pipeline.

proj_as_proj_string(ctx, P, PJ_PROJ_5, nullptr) will return a PROJ string that
generally begin with "+proj=pipeline" (not in your case with alternatives
though)

If just after that and before the first +step, you insert

+step +proj=axisswap +proj=axisswap +order=2,1

(or you append it at the end if you want to reverse the order for the output)

And then you can recreate a PJ pipeline with that string with proj_create()

Or course if you do an axisswap just before/after another one, their effect
cancels each other, so you could optimize by removing it;

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Paul Ramsey


On Feb 16, 2019, at 2:13 PM, Even Rouault <[hidden email]> wrote:

Perhaps I should since the above explanation are probably
just an implementation detail for your use case ?

OK, fix just pushed.

This seems to get me there… now I’m disambiguating axes, hoorah (?)


Yes, I’m only looking for source/target so I can figure out if I need to do
an axis swap before (or after) feeding the transformation. Is there a
decent way to stick a swap directing onto the end/start of the
transformation so I get it “for free” when I run proj_trans?

That would involve hand editing the pipeline.

proj_as_proj_string(ctx, P, PJ_PROJ_5, nullptr) will return a PROJ string that
generally begin with "+proj=pipeline" (not in your case with alternatives
though)

If just after that and before the first +step, you insert

+step +proj=axisswap +proj=axisswap +order=2,1

twice?

Unfortunately, running proj_as_proj_string() on my transform <https://gist.github.com/pramsey/22127622023e88cd415cd1524db0a285#file-proj-c-L19> results in 

  proj_as_proj_string: Object type not exportable to PROJ

So this route to swapping may not be available to me.

P.

(or you append it at the end if you want to reverse the order for the output)

And then you can recreate a PJ pipeline with that string with proj_create()

Or course if you do an axisswap just before/after another one, their effect
cancels each other, so you could optimize by removing it;




Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Even Rouault-2
In reply to this post by Even Rouault-2
On samedi 16 février 2019 23:13:56 CET Even Rouault wrote:

> > > Perhaps I should since the above explanation are probably
> > > just an implementation detail for your use case ?
>
> OK, fix just pushed.
>
> > Yes, I’m only looking for source/target so I can figure out if I need to
> > do
> > an axis swap before (or after) feeding the transformation. Is there a
> > decent way to stick a swap directing onto the end/start of the
> > transformation so I get it “for free” when I run proj_trans?
>
> That would involve hand editing the pipeline.
>
> proj_as_proj_string(ctx, P, PJ_PROJ_5, nullptr) will return a PROJ string
> that generally begin with "+proj=pipeline" (not in your case with
> alternatives though)
>
> If just after that and before the first +step, you insert
>
> +step +proj=axisswap +proj=axisswap +order=2,1
>
> (or you append it at the end if you want to reverse the order for the
> output)
>
> And then you can recreate a PJ pipeline with that string with proj_create()
>
> Or course if you do an axisswap just before/after another one, their effect
> cancels each other, so you could optimize by removing it;

Another option is that you alter your source/target CRS to have the axis order
you wish.

In proj_experimental.h, you have functions to do CRS manipulations

For example if you start with a geographic CRS PJ* geogCRS, you could do:


PJ* datum = proj_crs_get_datum(geogCRS);
PJ* long_lat_cs = proj_create_ellipsoidal_2D_cs(ctx,
                                                                                                                  PJ_ELLPS2D_LONGITUDE_LATITUDE,
                                                                                                                  "Degree",
                                                                                                                  180.0 / M_PI);
PJ* long_lat_crs = proj_create_geographic_crs_from_datum(
        ctx, "my CRS", datum, long_lat_cs);
proj_destroy(datum);
proj_destroylong_lat_cs);

But using that API might be more tricky and have side effects (like area of
use being lost, which can have effects when datum transformation paths are
searched. Setting this area of use could be done with the C++ API, but the C
API is just a subset of it that doesn't expose that), so you'd better do the
axis swapping game in your code rather than creating those alternative CRS
definitions.


Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Even Rouault-2
In reply to this post by Paul Ramsey
> > If just after that and before the first +step, you insert
> >
> > +step +proj=axisswap +proj=axisswap +order=2,1
>
> twice?

For example if you transform from EPSG:4326 to something, as PROJ internally
handles geodetic coordinates in the long, lat order, the pipeline it will
return will do as a first step an axis inversion from lat, long (the axis
order of EPSG:4326) to long, lat.
If you actually want to create a pipeline that takes long, lat coordinates,
you'd have to add an extra axisswap before, or remove the axisswap PROJ
automatically added.

>
> Unfortunately, running proj_as_proj_string() on my transform
> <https://gist.github.com/pramsey/22127622023e88cd415cd1524db0a285#file-proj
> -c-L19
> <https://gist.github.com/pramsey/22127622023e88cd415cd1524db0a285#file-proj
> -c-L19>> results in
>
>   proj_as_proj_string: Object type not exportable to PROJ

Yes, that's what I meant with my above "(not in your case with
alternatives though)". As there are several potential alternatives, the PJ
object you get cannot be exported as a PROJ string, since the actal PROJ
string will change depending on the coordinates with which you'll call
proj_trans()

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Proj6 Docs

Kristian Evers-2
In reply to this post by Paul Ramsey
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 <[hidden email]> wrote:
>
>
>
>> On Feb 16, 2019, at 12:30 PM, Even Rouault <[hidden email]> 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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj