[PROJ] Migrating to proj API 6+ without forcing crs input

[Johannes Schauer Marin Rodrigues]

Dear proj list,

in my application [1] I was using the ability of the Python mapnik library to
render an arbitrary transformation by supplying my own custom proj string (a
+proj=pipeline with +proj=tinshift). This stopped working when mapnik
implemented support for the proj API 6+ [2] because mapnik followed the proj
migration guide and turned code that looked like this before:

    projPJ pj_longlat = pj_init_plus(source);
    projPJ pj_merc = pj_init_plus(target);
    pj_transform(pj_longlat, pj_merc, ...)

Into code that looks like this:

    PJ *P = proj_create_crs_to_crs(PJ_DEFAULT_CTX, source, target, NULL);
    proj_trans(P, PJ_FWD, ...);

This means that in contrast to before, the source and target transformation
must now be a CRS. My own custom proj string (a pipeline) is not a CRS and thus
my code is now non-functional with mapnik versions from git.

I want to contribute an alternative codepath to mapnik which restores its
previous ability to work with arbitrary proj strings (even those that are not a
CRS). But how is this done? All projects that migrated to API 6+ that I was
able to find follow the migration guide and call proj_create_crs_to_crs.

So my question ultimately becomes: how do I implement proj API 6+ support
without proj_create_crs_to_crs so that the software retains its ability to
handle arbitrary user-supplied proj strings?

I also asked the same question on stackoverflow [3] in case somebody wants to
grab the bounty.

Thanks!

cheers, josch


[1] https://blog.mister-muffin.de/2014/04/03/mapbender---maps-for-long-distance-travels/
[2] https://github.com/mapnik/mapnik/commit/88241b32eeaccdc9eda7b92b7e7b6d4deac88e12
[3] https://stackoverflow.com/questions/71823105/migrating-to-proj-api-6-without-forcing-crs-input
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220414/169aad2d/attachment.sig>