Frank Warmerdam warmerdam at pobox.com
Tue Mar 20 21:23:16 EST 2001


I have been requested to rename the PVALUE type in PROJ.4 to avoid a 
conflict with something defined in one of the windows include files.  
Does anyone object to my renaming it?  

It is likely that applications would only run into problems if they are
calling the pj_param() function to fetch back parameters out of paralist

Another alternative might be to split the minimum set of definitions
required by applications into another include file (proj_public.h perhaps)
and encourage applications running into problems to use that.  It could
be setup to reduce the risk of additional name space collisions, but the
old projects.h could still be distributed (and used internally) to avoid
undue compatibility problems.  It would include proj_public.h to get
the public definitions and add lots of prototypes for internal functions,
and types that aren't needed publically.   If I do this, I would also 
make the PJ structure opaque to applications only including proj_public.h
and perhaps add a few more accessor functions to get required information

Note that we have already had to rename UV (to projUV).  I can easily imagine
XY, and LP causing problems.  Also some of the #define's in projects.h aren't
really required by calling applications, and may cause unnecessary conflicts,
stuff like HALFPI, FORTPI, PI, and so forth. 

I would appreciate prompt feedback, as I would like to do something tomorrow.

PS. I have also been thinking of adding functions like:

 pj_init_plus(): Initialize directly from a string in the form
                 "+proj=utm +zone=11 +ellps=WGS84" 
 pj_is_geographic(): to return the is_latlong flag in the PJ structure. 
 pj_latlong_from_proj(): to return a geographic coordinate system matching
                         the ellipse and datum information of a projected PJ.
 pj_compare(): Return TRUE if two PJ's appear to be identical.
 pj_get_definition(): To return the internal definition of the projection, 
                      after expanding +init= values, +datum values and so
                      forth.  This would make it easier for applications 
                      needing to transform PROJ.4 definitions into other
                      formats to correctly support more exotic definitions.

Any thoughts?

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/~warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.

More information about the Proj mailing list