[Proj] PROJ 4.8.0, projects.h and projPJ struct

[José Luis García Pallero]

El día 12 de abril de 2012 07:32, Frank Warmerdam
<warmerdam at pobox.com> escribió:
> 2012/4/11 José Luis García Pallero <jgpallero at gmail.com>:
>> This function sounds good, but I have a couple of objections:
>>
>> 1. First of all, the portability of old code. The programs that until
>> now include projects.h instead proj_api.h should be corrected. I
>> propose to rename projects.h to projects_internal.h (for example) and
>> create a new projects.h that contains only #include<proj_api.h> Then,
>> it can be maintained in programs the #include<projects.h> and it runs
>> always: prior to 4.8.0 and 4.8.0 or higher. Previously on this same
>> topic I explained that is impossible to check automatically the
>> version of PROJ via PJ_VERSION and select the correct header to
>> include because if projects.h is included after proj_api.h some errors
>> of conflicting types appears. Creating new projects.h could avoid this
>> gotcha.
>
> José,
>
> On linux configure can check for projects.h and probe for versions.
>
> On windows you are generally having to handle proj yourself so what
> is the big issue about different versions?
>
> I guess I just don't feel this as a serious issue.
>
>> 2. What about the old code that uses explicitly some fields of projPJ
>> structs? Why in 4.8.0 projPJ fields are not public? For old code that
>> uses explicitly fields of projPJ the solution of the point 1 is not
>> valid. Another solution could be to define explicitly the PJ struct in
>> proj_api.h. Whith this solution plus the new projects.h I think that
>> almost all old code should have not problems with new 4.8.0 version
>
> A large part of the reason for making projects.h private was to break
> the dependence of application on the particulars of the layout of the
> projPJ structure!  So, if you really need it, just include projects.h and
> manually copy that from the source distribution.  But if you want to
> follow the public API contract then stick to proj_api.h.
>
> I don't mean to be peevish, but to me this seems to be an issue from
> half a decade ago.  I've certainly been advising all to migrate to proj_api.h
> for a long time.

OK, I understand. Thank you for your answers.

And about checking if a projection has inverse step, if I can't access
to projPJ->inv field I'll try to detect it via pj_get_errno_ref(). In
the source of pj_transform.c I can see that a projection that has not
inverse step returns an error code -17. This -17 is hardcoded in
pj_transform.c. Can you confirm that for no inverse step was always
-17 the error value, in old releases included?

Cheers

>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Software Developer
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj



-- 
*****************************************
José Luis García Pallero
jgpallero at gmail.com
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************