[Proj4j] Re: Proj4j and cts

[Sunburned Surveyor]

It is good to see this conversation going on!

Martin wrote: "I have avoided mutating the input points in Proj4J so
far, but I'm coming round to thinking that maybe this is a better way
to go."

I am glad to hear this. I already started refacotring a branch Proj4J
to use getters and setters for X, Y, and Z access. I'm not sure when I
may get back to this work. Might be after my workshop materials
deadline of January 22.

Can someone tell me what "CTS" is?

The Sunburned Surveyor

2010/1/14 Martin Davis <mbdavis at refractions.net>:
> Comments inline below...
>
> Michaël Michaud wrote:
>>>
>>> - As for keeping code in synch with PROJ4: I don't think JHLabs is
>>> maintaining his codebase any more.  My plan was simply to keep things in
>>> synch manually.  There's not too much change in PROJ4 I don't think, and in
>>> any case I don't think automation is a realistic possiblity.
>>
>> Until now, I did not spent too much efforts on projection code, as jhlabs
>> offers a java way to access the impressive PROJ4 library. It could be a good
>> idea, at some point, to rewrite the code for a better integration in cts or
>> whatever the name, but this is a low priority (can be considered as a
>> maintenance task).
>
> Yes, agreed.
>>>
>>> - re complexity of design.  Perhaps we can both learn from each other!
>>>  It seems like there's an irreducible amount of complexity required to
>>> implement a given set of projection capabilities - PROJ4J and CTS have
>>> perhaps simply chosen slightly different sets of functionality to aim at.
>>>  Looking at your code I don't see anything which jumps out as being
>>> needlessly complex.  In fact, quite possibly some things are simpler or at
>>> least better thought out, since you presumably started with a true OO design
>>> from the beginning, whereas Proj4J is trying to evolve to a proper OO design
>>> from an highly non-OO beginning!
>>
>> I've a bit of work there to dive into Proj4J and to make propositions to
>> make it evolve towards CTS where it is possible.
>
> Ok, I'll look forward to seeing some ideas come out of this.  I will also
> try and look at CTS to see how Proj4J can evolve towards it. There's a lot
> of flexibility here on the Proj4J side - the exposed class model has been
> pretty much completely dreamed up by myself, so there's no legacy
> compatibility issues.  And I certainly don't claim to have the best class
> model for CRSes!
>>>
>>> One thing that strikes me about the CTS design is the use of double[] as
>>> the representation for a Coordinate value.  It seems to me it would be
>>> better to model this as a class.  That would be more communicative, would
>>> provide a place for methods associated with manipulating and querying
>>> coordinate values and metadata, and would allow using Javadoc.
>>
>> This choice arose after a discussion on OpenJUMP list. As coordinates
>> manipulation is a central part of the computation, I wished it to be as
>> light as possible, as efficient as possible, independant from any library
>> and easy to integrate in other libraries (like JTS) without casting
>> overhedad. This is not a requirement for CTS. If wraping doubles in a
>> coordinate (or position) class has no big performance penalty, I'm ready to
>> change. What about immutability ? cts uses double[] which is mutated during
>> transformation.
>> Would be great to hear other advices (or better, to make unit tests).
>
> In my (limited) experience, there's no advantage to using double[] rather
> than a custom class from the point of view of integration with existing
> code.  I think most clients would have to copy the ordinates in and out of
> the their own structures in any case.
> There's no reason a custom class can't be mutable.  (eg the JTS Coordinate
> class).  I have avoided mutating the input points in Proj4J so far, but I'm
> coming round to thinking that maybe this is a better way to go.  Although
> I'm not crazy about the fact that in CTS points can potentially change
> dimension during the transform call.  Is that really necessary?  Can't you
> just rely on the user to provide the required dimensionality in the input?
>
>>> Would an alternative be to harmonize the two libs at some point short of
>>> full integration?   I can see the following levels of harmonization:
>>> - Use same CoordinateOperation (Transformation?) interface
>>
>> Hope we can reach this step. I propose to open another thread to gather
>> comments about current cts interface
>
> Sounds good.  Look forward to seeing it.
>>>
>>> - Use same model for supporting classes such as Datums, Units, Ellipsoid,
>>> etc
>>
>> This is a big part.  I think it can be quite easy on Ellipsoid and Units.
>> May be a bit more difficult for Datum. What about a CoordinateSystem (axis
>> definition) distinct from the CRS (Datum + CS) ?
>
> I wasn't aware of the OGC distinction between CS and CRS.  The use of the
> name CoordinateSystem in Proj4j is arbitrary right now.  It sounds like this
> should be renamed to CoordinateReferenceSystem to align with OGC, right?
>>>
>>> I presume the goal here would be to allow projects to use a combination
>>> of the two libraries - Proj4J for its breadth of projections, and yours for
>>> it's more sophisticated datum transformations, where required.  Not sure if
>>> this is realistic - but it sure seems silly to both be creating numerous
>>> nearly identical classes.
>>
>> I agree compatibility is the main issue. Integration or merge may follow.
>> I'm not convinced considering sophisticated datum transformation code as an
>> optional module is an easy way to go. At some point, a good integration is
>> needed, or difficult transformation problems will have to be decided and
>> managed by the end-user instead of the library/designer.
>
> Yes, agreed, ultimately.  I was thinking of short to medium term, to be able
> to get started on moving towards integration.  Although - wouldn't it be a
> good goal to provide an extension point to allow custom data transformations
> to be defined fairly easily - and this would be a good test case for that
> capability?
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> Proj4j mailing list
> Proj4j at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/proj4j
>