[PROJ] Use of EPSG codes in proj_create()

Even Rouault even.rouault at spatialys.com
Tue Apr 2 03:44:08 PDT 2019


On mardi 2 avril 2019 10:38:45 CEST Oliver Eichler wrote:
> Hi,
> 
> I am working on the transition of QMapShack from version 4 to version 5
> API. So far so good. There is only on thing that breaks. The use of EPSG
> codes for projection strings.
> 
> That's what I try to do:
> 
>      // used PROJ version: 6.0.0
>      // PJ * pj = proj_create(PJ_DEFAULT_CTX, "EPSG:3395");      // [1]
> result for x and y is inf
>      PJ * pj = proj_create(PJ_DEFAULT_CTX, "+proj=merc");        // [2]
> result is expected one
>      // PJ * pj = proj_create(PJ_DEFAULT_CTX, "+init=EPSG:3395") // [3]
> pj is nullptr
>      PJ_COORD pt = {11 * DEG_TO_RAD, 48 * DEG_TO_RAD};
>      size_t s = proj_trans_generic(pj, PJ_FWD,
>                                  &pt.xy.x, 0, 1,
>                                  &pt.xy.y, 0, 1,
>                                  0,0,0,
>                                  0,0,0);
> 

With PROJ 6, [1] instanciates a CRS object, not a coordinate transformation. 
So proj_trans_generic() will return an error on it. You'd rather want to use 
proj_create_crs_to_crs() with in the source CRS a geographic CRS and as target 
CRS, "EPSG:3395". The coordinates passed and returned to/from 
proj_trans_generic will have to follow the axis order and units of the source 
and target CRS
See https://proj4.org/faq.html#why-is-the-axis-ordering-in-proj-not-consistent

[2] matches the PROJ 5 behaviour, and creates a coordinate operation using the 
merc method. Input units and axis order is longitude, latitude in radians.

[3] is a deprecated syntax in PROJ 6. The reason is that older versions of 
PROJ didn't respect the EPSG axis order in a lot of situations, and we didn't 
want that to go on when using the new API.

Even

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


More information about the PROJ mailing list