[PROJ] Use of EPSG codes in proj_create()

[Oliver Eichler]

Thanks for the answer! :D

But I still wonder what is the best way to get the same functionality as 
with pj_transform(). It might not have been the most standard conform 
thing but it did the job quite good and consistent. Now it seems to be 
that everyone needs to write a beast that analyzes the axis ordering, 
analyzes the coordinate format, fix all input to match requirements, do 
the conversion and normalize all output.

It's a good thing for sure to have all these functions separately to use 
them in an optimized way if possible. But on the other hand side a high 
level function like pj_transform() that simply hides all the details 
behind a very simple and generic interface would be nice to have, too.

Or do I miss the obvious?

Oliver


Am 2019-04-02 12:44, schrieb Even Rouault:
> 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