[PROJ] Proj6 Docs

[Even Rouault]

> 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