[Proj4j] An approach to working together

[Martin Davis]

Fred,

Sorry that you've found that you can't simply use the current Proj4J
codebase.  Perhaps it will be worth revisiting this decision once
Proj4J has stabilized and become more proven in use.  It seems to me
like there's got to much more common code than there is differences in
approach (100 complex projection classes far outways any structural
code that's been changed, I think!)

Anyway, your proposal of simply sharing algorithm fixes sounds fine,
and quite workable.  The core projection code should be very portable
between both systems, I expect.

Ideally you can provide test cases which exhibit failure cases (and
prove that the bug has been fixed).  I will add these to the Proj4j
test suite whereever possible - this is very important to allow
regression testing going forward.

I don't think there are any projections which should be ignored.  I
seem to recall that there's some strange issues around the
OrthographicAzimuthalProjection - perhaps to do with it being out of
synch with the original Proj4 code.  But it would be nice to have this
tested and fixed as needed.

I don't rule out interest in projections with no inverse and
sphere-only projections.  Probably some comparison should be done with
PROJ4, CSMAP and GeoTools to see if they are provided there.  It would
be nice to support any and all projections, but priority must be given
to code which will be most likely to be used.

Look forward to the first round of bug fixes!

You might have a look at Albers - I think I fixed a bug or two in there.

Martin


On Mon, May 31, 2010 at 6:42 PM, Fred Pospeschil
<f.w.pospeschil.t.r at charter.net> wrote:
> Martin,
>
> In looking over our previous emails it appears that the overall approach you
> need for your CRS work is considerably different than what I need for my
> project.  However, we both need properly functioning projection code.  Given
> that thought, I tried to bring your code into my GUI test environment.  That
> turned out to be a fools errand due to the way your CRS needs have caused
> considerable/significant changes to most all of Jerry's files.  Working
> with, or around, these changes appears to require more work than it is
> worth.
>
> Thus, I propose the following approach to cleaning up Jerry's projection
> files.
>
> On a projection file by projection file basis, I will send you the results
> of my testing and any fixes I have been able to make.  When I have made
> changes to Jerry's projection file I will attach a copy of the file.
>
> You will do whatever you can to resolve the error condition/conditions and
> attempt to verify the correctness of my changes.  I would like your fixes to
> be applied to the file I send you and you return to me.  However, I can work
> with the corrections as they exist in your file - which you will forward to
> me.
>
> Similarly, if your testing reveals errors you will let me know of the errors
> and any fixes you develop.
>
> Any fixes you send will be re-tested in my GUI environment and the results
> forwarded to you.
>
> Are there any projections in which you have no interest and I should ignore?
>
> Are you interested in projections which do no have an inverse capability?
>
> Are you interested in projections which support only the SPHERE ellipsoid -
> if you can call it that?
>
> Let me know if there is anything here that works for you.
>
> Fred
>
>
>
> _______________________________________________
> Proj4j mailing list
> Proj4j at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/proj4j
>
>