[PROJ] Use of EPSG codes in proj_create()

[Paul Ramsey]

I understand (in an “I understand your premises but don’t share them” kind of way) the push back from the real live geodesists, but if PROJ doesn’t provide, then every downstream project is going to end up with one of these

https://github.com/postgis/postgis/blob/svn-trunk/liblwgeom/lwgeom_transform.c#L298-L343 <https://github.com/postgis/postgis/blob/svn-trunk/liblwgeom/lwgeom_transform.c#L298-L343>

P.

> On Apr 2, 2019, at 11:08 AM, Oliver Eichler <oliver.eichler at dspsolutions.de> wrote:
> 
> 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
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190402/44518634/attachment.html>