[PROJ] Use of EPSG codes in proj_create()

Oliver Eichler oliver.eichler at dspsolutions.de
Tue Apr 2 23:04:54 PDT 2019


> But it raises the question: What sort of things will be useful to
> demonstrate on doc pages
> like that?
> 

Well, as mentioned, it should contain a code snippet that restores the 
old functionality of pj_transform(). I would guess that is in close to 
100% of the migration cases the function to migrate. It does not have to 
be necessarily API compliant to pj_transform(). But it shouldn't break 
the functionality. And if it does this has to be documented as detailed 
as possible.

There is no problem in telling the users that there has been a version 
change and some things have to be done different. As long as I can point 
out what's different and provide an example for the alternative. But 
"Ooops it breaks because it's different and I don't really know why and 
how to fix it" isn't satisfying for anyone.

And probably examples how to port the other complex functions like 
pj_datum_transform(), pj_geocentric_to_geodetic(), 
pj_geodetic_to_geocentric(), pj_compare_datums() and 
pj_apply_gridshift() would be helpful. The rest of the functions seems 
to be simple enough to be replaced by some counterpart of the new API. 
But a complete table would help. The current one seems to be a bit 
short.






More information about the PROJ mailing list