[Proj] Getting Proj information after pj_init has been thrown

[Till]

Hi Frank,
And many thanks for your answers.

The problem I'm facing, is that I'm using it inside another project where I
need to combine with other includes.
To help going further, Id did build a 'coordinate' class for 2D/3D Points
that carry 2 'geo'-representations of their positions. This class is about
to use Proj.4 for managing the conversion from one to the other.
As such it includes proj_api.h.
This class is also used inside another framework (not to mention Ogre3D). As
long as I'd like to provide this class to some entities in this framework, I
need to be able to include my class's prototype inside some .cpp that also
include .h from this framework.
This is where my compilation pb occurs.
There are places where this framework includes 'windows.h', and I absolutely
don't know where. Furthermore, if I knew where this occurs the solution
would probably to patch this framework, which is something I'd like to
avoid.

Maybe my lack of knowledge of hacks or tricks to overcome this is in
involved, but I don't see yet any proper way to build something robust, in a
way I'd not face it again on another framework.

I hope I explained properly my concerns, and I admit I could miss some
'building/compilation' tricks that could work around all of this.

On the second point, yes there might be a couple of fields we should be able
to access.
May be another way is to split the projects.h header in such a way, the
PVALUE is isolated.

-----Message d'origine-----
De : proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] De la part de Frank Warmerdam
Envoyé : mercredi 7 janvier 2009 04:14
À : PROJ.4 and general Projections Discussions
Objet : Re: [Proj] Getting Proj information after pj_init has been thrown

Till wrote:
> Yes, but this 'segregation' is actually hard to achieve since windows.h is
> implicitly somewhere used but not in an obvious way, as long as a project
> may rely on a couple of different library includes (like ours) and
probably
> altering the way it is done, may bring some side effects we'd like to
avoid.

Till,

Sorry for the previous reply - I read these messages out of order.

I'm really just suggesting you add a small additional C++ source file to
your project in which you do all your PJ accessing and have it only include
the bare minimum of stuff.

> On the concerns, I may understand that internal access to the whole PJ
> structure is not encouraged (although I think it should be available as
> "read only", at least).

Well, it is certainly available.

> My feeling is one may however want to be able to access basic
initialization
> data that have been generated out of the initialization (like major/minor
> axis, etc.) that we could just implement adding a pj_info(char*info)
> retriever tool or some pj_getMajor/MinorAxis whatever.

Possibly, though potentially there are a lot of fields you might want access
to.

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 Programmer for Rent

_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj