[Proj] Optimizing lookup of init files
warmerdam at pobox.com
Wed Aug 1 14:30:34 EDT 2007
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.
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
So, I'm personally inclined towards the internal thread locking approach,
though not strongly.
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
More information about the Proj