[Proj] Optimizing lookup of init files

[Dean C. Mikkelsen]

I like the route shown below.

invproj -> geodetic2geocentric -> bursa_wolf -> geocentric2geodetic -> proj

I'm currently looking at developing a tool based PROJ.4 to do something
similar (web-based possibly).

I've always thought of projections and datum transforms as two different
beasts.

In place of busra_wolfe in the above example, though, you could incorporate
the grid methods (used in South Africa, Canada, the U.S., etc.), depending
on the accuracy you are after, whether it be for mapping or more detailed
surveying.

Ideally, also, on the bursa_wolfe, you'd have to specify which specific one
particular to a region, as even in the EPSG codes, there are various ones
for various parts of countries or states and even offshore. The accuracies
range from being very poor (very few survey points to be adjusted) to very
good for a small area (many survey points used to determine the rotations,
scale factor, translations).

Cheers,
Dean


-----Original Message-----
From: proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] On Behalf Of Eric Miller
Sent: Wednesday, August 01, 2007 10:38 AM
To: geraldi.evenden at gmail.com; PROJ.4 and general Projections Discussions
Subject: Re: [Proj] Optimizing lookup of init files


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



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