[PROJ] Proj6 Docs

[Paul Ramsey]

> On Feb 16, 2019, at 1:56 PM, Even Rouault <even.rouault at spatialys.com> 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