[Proj4j] Re: Proj4j and cts

[Sunburned Surveyor]

Thanks for the explaining Michael. I decided to help Martin with
Proj4J, but as usual, I am more trouble than I am worth. :]

I think it would be great to get a good coordinate transformation
library that we could share among FOSS Java GIS projects.

SS

2010/1/14 Michaël Michaud <michael.michaud at free.fr>:
> Hi Landon,
>>
>> Can someone tell me what "CTS" is?
>>
>
> It stands for Coordinate Transformation Service. I have developped this
> library for several years, but it's not yet production ready. I'd like to
> finalize it with the help of OrbisGIS team, but before that, we would like
> to study a possible merge with Proj4J, or at least to assure a good
> interoperability.
> Thanks to Erwan, source code is visible on
> http://geosysin.iict.ch/irstv-trac/browser/branches/libs/cts
>
> Michaël
>>
>> 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
>>>
>>>
>>
>>
>>
>
>