[Proj4j] An approach to working together

[Martin Davis]

Fred,

I switched away from Point2D for two reasons:

- reduce the dependencies on external APIs
- allow for further enhancements to the Point datatype to support new
functionality in Proj4J.  An obvious example is to allow a Z ordinate.

It's easy to convert to Point2D if needed - is that an option for you?
 I'm not keen on supporting both in Proj4J, since that widens the
interface.

As for changing how Proj4J handles checking for ellipsoids/spheres,
I'm not quite sure what you mean.  Can you provide a more concrete
example?

Martin

On Wed, Jun 2, 2010 at 8:11 PM, Fred Pospeschil
<f.w.pospeschil.t.r at charter.net> wrote:
> Martin,
>
> Glad you mentioned the Albers projection,  it is one that I found had
> problems.  I am working on my first input to you - on Albers.
>
> I agree that it would be nice if we could all use the "same" code.  One of
> my problems was that you do not use the Point2D.Double for your point type.
> It occurred to me that we might consider overloading to allow the code to
> support both point types.
>
> Additionally, the current code frequently checks to see whether the given
> projection support ellipsoids other than the SPHERE.  Maybe we could look at
> having a CRS Boolean that could be tested to see whether the more advanced
> considerations associated with CRS concerns needed to processed.
>
> Although these things would make the code more complicated it might allow
> for a single "library" which could support a far wider audience.
>
> If you think these ideas might be of use let me know and we can see if we
> can list out some of the criteria, conditions, requirements, etc. that we
> would want to address.
>
> Such a beast might be a challenge to document but it could be worth while.
>
> Fred
>
> From: Martin Davis
> Sent: Monday, May 31, 2010 10:44 PM
> Cc: Proj4j Mail List
> Subject: Re: [Proj4j] An approach to working together
> 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
>>
>>
> _______________________________________________
> Proj4j mailing list
> Proj4j at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/proj4j