[Proj] Optimizing lookup of init files

[Eric Miller]

>>> On 8/1/2007 at 9:46 AM, "Gerald I. Evenden" <geraldi.evenden at gmail.com> wrote:
> On Wednesday 01 August 2007 11:49 am, Daniel Morissette wrote:
>> Hi,
>>
>> Users of applications such as MapServer that make use of the
>> "+init=epsg:4326" type of syntax to initialize projection definitions
>> have reported a performance issue when their maps contain multiple
>> projections (see http://trac.osgeo.org/mapserver/ticket/1976).
> 	...
>> There are pros and cons to both approaches. Can anyone think of a 3rd
>> option that would be even less disruptive?
> 
> Yes.  Remove the +init from proj.  That was the first thing I did when 
> upgrading to libproj4 and lproj.  Seems like something more appropriate for 
> mysql or other DBMS.
> 
>> Comments and suggestions welcome. I'm especially interested in feedback
>> from developers of applications using PROJ.
> 
> Sorry.  I am sure that suggestion was not appreciated but it follows my 
> approach of keeping operations separated into appropriate categories.
> Like datum shifting is not appropriate within the projection software 
> element, 
> extracting initialization information from a database is also not 
> appropriate.

I tend to agree with Gerald on this issue.  I think maintenance of predefined coordinate systems
should be separated from the library.  It seems the coordinate systems need to be updated more
often than the actual library.

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.

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.

For instance:

typedef struct _transform_t transform_t;

int transform_create(const char *init, transform_t **transform);
int transform_apply(const transform_t *transform, size_t dims, double data[dims]);
void transform_destroy(transform_t **transform);

Initialization strings might be something like:
"+transform=pj_fwd +proj= ... "
"+transform=gridshit +grid=conus +direction=forward"

But, that's about as far as I got.  It's hard for me to devote any time to work on this...

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).