[Proj4j] Re: Proj4j and cts

[Martin Davis]

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