[Proj] Optimizing lookup of init files

[Frank Warmerdam]

Eric Miller wrote:
> However, if you're going to add caching support and make it thread safe, you
> might as well fix the non-thread safe caching of grid shift files.  I
> recently had to abandon PROJ.4 from a project because of that.

Eric,

I agree.  If we either introduce a session object, or thread locks
this should also be used to protect the grid shift file stuff.

> Because of the threading problems from above, I started to look into using
> Gerald's new library.  After I patched that library for Windows (no atanh in
> math.h), I started looking at how the interface should be designed.  My
> initial idea is a bit different than the cs2cs model.  Basically, I decided
> the library should supply a set of coordinate transformations.  The
> transformations then can be chained to get from some system A to another
> system B.  It'd be up to the client to specify the set of transforms that
> need to be applied.
...
> The main idea was that there are many ways to transform coordinates, so the
> library should provide more flexibility on how to get from A to B.  A higher
> level interface could provide some defaults (invproj -> geodetic2geocentric
> -> bursa_wolf -> geocentric2geodetic -> proj).

I'm not adverse to having the library expose individual methods so folks
can have detailed control when they want it.  But from a practical point of
view I believe that applications like MapServer, GRASS, and GDAL mostly
want to avoid micromanaging this stuff.  They want a string representation
of two coordinate systems and a function to convert coordinates from one
to the other.

This discussion is beside the point as far as Daniel's question goes though.

With regard to his two approaches, I think introducing thread locks in
PROJ.4 would not be terribly complicated. We have good models for this in
MapServer and GDAL.  But I do hate having to maintain platform stuff like
a thread locking abstraction in so many different places.

The session idea provides a nice lock-free approach with the understanding
that sessions cannot be shared between threads - at least concurrently.
*But* each session will end up with duplication of cached grids and
initialized projections.  It puts a non-trivial weight on calling
applications to keep track of sessions when there was previously no such
thing.

So, I'm personally inclined towards the internal thread locking approach,
though not strongly.

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    | President OSGeo, http://osgeo.org