[Proj] Old problems

[Frank Warmerdam]

On 1/4/06, Gerald I. Evenden <gerald.evenden at verizon.net> wrote:
> The only other items I find are the non-projection projections geocentric,
> latlong and longlat.  Am I correct to this point?
>
> This leaves pj_init as the focus of compatibility issues.  Correct?  That is,
> as far as usage of proj4 and libproj4 there would be no changes other than
> what pj_init does and the 3 non-projections.
>
> Now assume that libproj4 has new entry points, proj_init, proj_fwd and
> proj_inv, and the initialized structure is PROJ and your requirements still
> have the pj_ series and structure PJ.  The structure PJ is now changed to
> something like:
>
> typedef struct PJconsts {
>        int     datum_type; /* PJD_UNKNOWN/3PARAM/7PARAM/GRIDSHIFT/WGS84 */
>         double  datum_params[7];
>         double  from_greenwich; /* prime meridian offset (in radians) */
>         int do_type; // where do_type selects latlong, longlat or geocentric
>         PROJ *libpj;
> } PJ;
>
> Your new pj_init is now rewritten using much of the code in libproj4's
> proj_init except that it checks to see if the non-projections are selected
> and bypasses calling proj_init with its input arguments and processes needed
> arguments to setup one of the three non-projections.  If a projection is
> needed then proj_init is selected and and the returned pointer is put into
> libpj.  I think the new pj_fwd and pj_inv are obviously modified.  Of course,
> pj_free needs mods as well.

Gerald,

Well, a few small complications include:
 o The need for the libpj structure even for non-projections to hold
    the ellipse information.
 o The issue of sharing the string parsing code.  Do we duplicate?

> If you gotta use +init, which I think should be modified to a DBMS SQL lookup,
> then use it in the modified pj_init.

I am agreeable to this being an "upper layer issue".

> The longer this issue is put off the greater the pain of correcting the
> problem is going to be.  I do think we need to bit the bullet and solve it
> once and for all.  Otherwise it remains a festering sore.

OK, I'm convinced.   I'm prepared to work on this in the evenings
in January.  Could you go ahead and rename the entry points and
structure for libproj4?  Then I'll proceed to alter a new generation of
the high level library to use it for all the projections work.

I'm reasonably convinced we will encounter some unanticipated
problems, but I'm sure we can address them as they come up.

Frank writes:
> would likely dig into some of the Krovak,

Gerald writes:
> What is the problem with Krovak?

I think it is related to the axis orientation.   I am *wanting* to
add +axis directives to the coordinate system description to
support different axis orientations instead of creating a new
projection type for alternate axes.

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