[Proj] PROJ 4.8.0, projects.h and projPJ struct
José Luis García Pallero
jgpallero at gmail.com
Wed Apr 11 13:50:57 PDT 2012
El día 11 de abril de 2012 19:27, Frank Warmerdam
<warmerdam at pobox.com> escribió:
> Eric,
>
> This seems reasonable. Don't hesitate to file a ticket ideally with a patch.
>
> Best regards,
> Frank
>
> On Wed, Apr 11, 2012 at 8:25 AM, Eric Miller <EMiller at dfg.ca.gov> wrote:
>> I think that being able to interrogate the projection definition to know
>> if it has an inverse is useful, so a function should be added to
>> proj_api.h.
>>
>> Perhaps:
>>
>> int pj_has_inverse(projPJ);
>>
>> And in pj_utils.c
>>
>> /******************************************************************/
>> /* pj_has_inverse()
>> */
>> /*
>> */
>> /* Return TRUE if this coordinate system object has */
>> /* and inverse projection method.
>> */
>> /*****************************************************************/
>> int pj_has_inverse( PJ *pj )
>> {
>> return pj != NULL && pj->inv != NULL;
>> }
Hello:
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.
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
Cheers
>>
>> --
>>
>> Eric G. Miller
>> Software Developer
>> CA Dept. of Fish & Game
>>
>>
>>>>> On 4/11/2012 at 3:30 AM, José Luis García Pallero
>> <jgpallero at gmail.com>
>> wrote:
>>> Hello:
>>>
>>> As it is said in NEWS files from PROJ 4.8.0 now proj_api.h file
>> should
>>> be included in programs instead projects.h. I've tried to compile my
>>> old code (that has no problems with 4.7.0) and I've obtained a
>> warning
>>> and an error.
>>> In my code I have a declaration like
>>>
>>> projPJ proyec;
>>>
>>> and I use them later as
>>>
>>> proyec = pj_init_plus(param);
>>>
>>> and more later, in order to check if a projections has inverse step:
>>>
>>> if(proyec->inv==0)
>>> {
>>> ......
>>> }
>>>
>>> If I compile the program using 4.8.0 version I obtain a warning and
>> an
>>> error:
>>>
>>> geocproj.c:202:14: warning: dereferencing *void ** pointer
>> [enabled by
>>> default]
>>> geocproj.c:202:14: error: request for member *inv* in something
>> not a
>>> structure or union
>>>
>>> Looking proj_api.h file, in both versions 4.7.0 and 4.8.0 I can see
>> the
>>> block
>>>
>>> for 4.7.0
>>>
>>> #if !defined(PROJECTS_H)
>>> typedef struct { double u, v; } projUV;
>>> typedef void *projPJ;
>>> #define projXY projUV
>>> #define projLP projUV
>>> #else
>>> typedef PJ *projPJ;
>>> # define projXY XY
>>> # define projLP LP
>>> #endif
>>>
>>> for 4.8.0
>>>
>>> #if !defined(PROJECTS_H)
>>> typedef struct { double u, v; } projUV;
>>> typedef void *projPJ;
>>> #define projXY projUV
>>> #define projLP projUV
>>> typedef void *projCtx;
>>> #else
>>> typedef PJ *projPJ;
>>> typedef projCtx_t *projCtx;
>>> # define projXY XY
>>> # define projLP LP
>>> #endif
>>>
>>> Both are the same (except for the ctx context). In both if
>> PROJECTS_H
>>> is not defined (i.e. if projects.h was not included) the type projPJ
>>> is defined as void* instead PJ*. PJ is defined in projects.h. But in
>>> the include/ folder of 4.8.0 project.h was not copied, so it's
>>> impossible to use it. So I can't use the 'inv' field and I suppone
>> no
>>> PJ struct at all as projPJ was defined as void*. Then which is the
>>> correct way in order to use the new PROJ 4.8.0 version?
>>>
>>>
>>>
>>> On the other hand, suppose that 4.8.0 works well in my case only
>>> including proj_api.h. Then my problem is that if I have not
>> knowledge
>>> about the version of PROJ in one computer, how can I proceed in
>> order
>>> to use the correct include depending versions.
>>> First of all, can I use version 4.7.0 (for example) with only
>>> #include<proj_api.h>? In my case the answer is NO because I obtain
>> the
>>> same warning and error that in 4.8.0. Then I try:
>>>
>>> #include<proj_api.h>
>>> #if PJ_VERSION<480
>>> #include<projects.h>
>>> #endif
>>>
>>> PJ_VERSION is defined in proj_api.h. I check if version is older
>> than
>>> 4.8.0 and try to include then projects.h. But I obtain some errors:
>>>
>>> /usr/include/projects.h:139:33: error: conflicting types for
>> *projUV*
>>> /usr/include/proj_api.h:54:37: note: previous declaration of
>> *projUV*
>>> was here
>>> geocproj.c: In function *ProjFwd*:
>>> geocproj.c:120:9: error: incompatible type for argument 1 of
>> *pj_fwd*
>>> /usr/include/proj_api.h:66:8: note: expected *projUV* but
>> argument is
>>> of type *projUV*
>>> geocproj.c: In function *ProjInv*:
>>> geocproj.c:202:14: warning: dereferencing *void ** pointer
>> [enabled by
>>> default]
>>> geocproj.c:202:14: error: request for member *inv* in something
>> not a
>>> structure or union
>>> geocproj.c:223:9: error: incompatible type for argument 1 of
>> *pj_inv*
>>> /usr/include/proj_api.h:67:8: note: expected *projUV* but
>> argument is
>>> of type *projUV*
>>>
>>> We can see conflicting type errors due to definitions of projUV in
>>> proj_api.h and projects.h.
>>>
>>> Opinions about?
>>>
>>> Cheers
>>
>> _______________________________________________
>> Proj mailing list
>> Proj at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/proj
>
>
>
> --
> ---------------------------------------+--------------------------------------
> 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!
*****************************************
More information about the Proj
mailing list