[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