[Proj4j] Re: Proj4j and cts

[Martin Davis]

Michael,

Some replies to your questions:

- by "PROJ4 definitions" I mean the "+name=value" strings that are used 
to specify coordinate systems in PROJ4.  It sounds like CTS already 
supports these, which is good (although this is a bit of a continuum, 
since there are many, many parameters in PROJ4)

- by "PROJ4 catalog artifacts" I mean the files in the nad directory, 
which form the catalog of named coordinate system definitions which 
PROJ4 knows about.  I'd like to preserve the ability to use these 
directly, since there's a lot of work encapsulated in them.  But I 
realize that you'd need to be able to extend this or have some other 
mechanism for specifying more complext transformations.

- 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.

- 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!

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.

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
- Use same model for supporting classes such as Datums, Units, 
Ellipsoid, etc

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.

Martin



Michaël Michaud wrote:
> Hi Martin,
>
> Thank you for answering and taking time to have a look at CTS.
> After a second look at CTS and Proj4J, I realized that actually, cts 
> complexity is about  halfway between Proj4J and GeoAPI.
>
> @Erwan: I attached a document I wrote this week-end to help 
> understanding CTS main features.
> @Martin: maybe you'll be interested as I included a few comments about 
> our library differences
>
>> Thanks for the note.  Collaborating on proj4j sounds like an 
>> interesting possibility.  It would be great to get some other 
>> developers involved.
>> I gave cts a quick look.  It looks like there are a lot of 
>> similiarities, for sure (as you'd expect since they both address the 
>> same domain).  It looks like cts is somewhat more sophisticated in 
>> its design - for instance, the Coordinate Operation concept (if I 
>> understand it) looks like a more elegant design than proj4j currently 
>> has.
> Yes cts design was mainly inspired from EPSG database model and OGC 
> specifications (but I felt free to implement what I think is important 
> without any constraint).
>> My main personal goal for proj4j is to keep development and design as 
>> simple as possible, since I don't have a lot of time to work on it, 
>> nor a desire to spend a lot of hard thinking in debugging complicated 
>> coordinate system code.  That's why I'm trying to track proj4 as 
>> closely as possible, so that any bugs can hopefully be fixed by 
>> referring to the original code.  That said, Java really requires (and 
>> encourages) a much nicer design than the original C code, and I've 
>> started down that path somewhat as you've seen.
> Proj4J design is actually very simple, which is a good point. I'll try 
> to argument why a richer model is useful, but I want also to keep cts 
> simple. Maybe some details can be simplified, hidden, or simply 
> abandonned if they are proved not to be useful (working with Erwan's 
> team and/or you can help to make this kind of decision.
>> More specifically, I'd really like to preserve the following:
>> - support for PROJ4 CS definitions
> What do you mean by definitions ? CTS will read proj4 file containing 
> crs (this is where I started from for crs definitions). But I don't 
> want to be limited by those definitions. I don't know proj4 model very 
> well, but I think it lacks some features which are defined in more 
> sophisticated models like the one of EPSG (explicit definition of axis 
> order, compound crs with an altitude reference system, explicit 
> transformation, which is not fully determined by a source and a target 
> crs definition...)
>> - support for PROJ4 CS catalog artifacts
> What is a catalog artifacts ?
>> - ultimately, ability to support PROJ4 datum transformations (some of 
>> which are grid based, similar I presume to the french transformation 
>> requirements)
> Yes this is a requirement for us. Initially, official french 
> grid-based transformation used a special algorithm which is not 
> implemented in any open-source library and which I added to cts (being 
> able to implement a transformation algorithm which is not described in 
> proj4 or even EPSG and to make it available to the end user is a think 
> I'd like to preserve). Now, IGN provides a grid in the NTv2 format, 
> allowing to use algorithms available in recent versions of proj.4.
>> - use of PROJ4 projection transformation algorithms
> I implemented 2 or 3 projections useful in France and added an adapter 
> to be able to use the very complete proj4 projection library. Don't 
> know yet if this adapter is fully efficient, or if it is better to 
> re-write projection code one after the other.
> What is the process you intend to follow to keep projection code in 
> sync with proj4. Is jhlabs keeping its code in sync ? Will you do ? 
> Using automatic processes or coding and debugging by hands when a bug 
> appears in the bug proj4 bug tracker?
>> - minimize the complexity of internal design and end-user API
> Yes, that's where cts may learn from proj4J. If you noticed specific 
> parts of cts which seem incompatible with this goal, please tell me.
>> Are these viable if your code is merged with Proj4J?
> Up to a certain point.
>> Maybe the best way forward is for you to review the two code bases 
>> and report on how much change would be required to Proj4J in order to 
>> support your requirements.  Then this report can be taken forward to 
>> the project PSC for discussion about whether this is a viable direction.
> Yes that's where I should go. As I have not much time to spend on this 
> project, I'll check with Erwan what he thinks and how we can go on.
>> Hope that helps.  Feel free to email if you have any further 
>> questions/ideas before you look into this.
> Sure, thanks for that.
>
> Michaël
>>
>> Martin
>>
>> Michaël Michaud wrote:
>>> Hi Martin,
>>> Before talking to you about technical stuff, I wish you a happy new 
>>> year.
>>>
>>> I'd like to ask you some questions about the proj4j library, but 
>>> first, let me explain
>>>
>>> Writing coordinate transformation code has occupied me for a long 
>>> time. I wrote a cts library, refactored it several times but never 
>>> found the time to finalize it and to incorporate it into OpenJUMP.
>>> Last version is on 
>>> http://geosysin.iict.ch/irstv-trac/browser/branches/libs/cts
>>> (an old webstart version is available on 
>>> http://michael.michaud.free.fr/geodesie/JTransfoCoord.html, not a 
>>> great piece of code, but just working for some useful french 
>>> transformations)
>>>
>>> My motivations :
>>> No java code available to do grid-based french transformations
>>> A fantastic coord transformation library available 
>>> (geotools/geoapi), but with a steep learning curve, so steep that I 
>>> never could find time to learn and participate (to be 100% percent 
>>> honnest I had also more fun to write new code from scratch than to 
>>> "learn" geotools api).
>>>
>>> Today, my friend Erwan Bocher from OrbisGIS and his team are ready 
>>> to start their coordinate transformation module, starting from my 
>>> library.
>>> The advantage they have to use my library is that french 
>>> transformations can be managed quite well, and we can work together 
>>> quite easily if technical points arise.
>>>
>>> But I try to follow your excellent work, and discovered quite 
>>> recently that you lead the proj4j project as an OsGeo metaCRS 
>>> subproject.
>>>
>>> I think that a good cooperation could be a better bet than creating 
>>> a third library (I think about mine as the third one as it has not 
>>> yet any status)
>>> In my point of view, my library architecture is quite close to 
>>> proj4j. Maybe a bit more complex with a bit more features (ready for 
>>> grid-based transformations, compound 3D transformations...), but 
>>> much less complex than Geotools or Geotoolkit. Actually, it has a 
>>> dependency to jhlabs projection library and another one to 
>>> jgridshift library.
>>> I have absolutely no claim about code quality, and I have a great 
>>> trust in your experience.
>>>
>>> That's why I would be very happy if you could take time to have a 
>>> look at my library, if you could say if, and how it, or some part of 
>>> it, could be merged into proj4j, and if a collaboration with Erwan's 
>>> team and myself would be possible (I read proj4j project goals, and 
>>> I think ours are very close except managing at least Ntv2 grids is a 
>>> minimum requirement for french transformations).
>>>
>>> Any advice will be warmly welcome.
>>> I want to give Erwan the best advice for the development of 
>>> OrbisGIS, and I'm sure that what will be good for OrbisGIS will also 
>>> be good for OpenJUMP.
>>> I did not do, myself, a complete comparison of proj4j and cts 
>>> libraries, but if I can give you some more details, let me know.
>>>
>>> Thank you for your patience
>>>
>>> Michaël
>>>
>>>
>>>
>>>
>>>
>>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022