[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