[Proj4j] Re: Comparison of GeoAPI, CTS and GeoTools?

[Martin Davis]

Good summary, Michael.  It pretty much corresponds to my impression of 
GeoAPI - the core structure is very good, but there are probably quite a 
few classes which will never by used by 80% of all use cases.  So 
perhaps there's room for a "GeoAPI-Lite" profile which simplifies things 
where possible, but still follows the basic concepts.

Agreed 100% about simplifying the Parameters API!

re CoordinateOperation carrying a source and target CRS.  This seems 
like a good design to me.  As for MathTransform, that looks like 
over-generalization to me.  They suggest that MathTransform could be 
used for things like AffineTransforms and Perspective Transforms.  
Maybe, but this seems to be out of the scope of Proj4J.  I think it's 
simpler just to provide a CoordinateTransform which merges more or less 
merges CoordinateOperation and MathTransform.

re the separation of CoordinateTransform from CRS definition.  Yes, I 
totally agree.  This effectively decouples the definition of a 
particular transformation from its use.  You'll notice that Proj4J has 
started down this road.  This was initially done to allow caching 
transformation definitions, but it will also serve to allow this 
decoupling.  I guess I need to go further and provide a 
CoordinateTransformFactory definition, though.  This is a clear 
extension point for Proj4J - clients could implement their own 
CoordinateTransforms (including the ability to specify different 
transforms between a given CRS pair).

Michaël Michaud wrote:
> Martin Davis a écrit :
>> Michael,
>>
>> Inspired by your work on CTS, I decided it would be worth looking at 
>> GeoAPI to see whether it could provide a model for the future design 
>> of Proj4J.  It certainly seems to be very complete and thorough.
> Yes it is.
>> One question I have is:  you mentioned that GeoTools had a lot of 
>> classes, which made it complex to use.  Is this complexity due to 
>> following GeoAPI?  And if so, does that mean that there should be 
>> some caution around trying to follow the GeoAPI model too closely, 
>> since it is likely to introduce unnecessary complexity?
> I just had a look at GeoAPI with your question in mind. Currently, CTS 
> and GeoAPI are quite close if one consider the main part of the model 
> (I grabbed many things from GeoAPI and EPSG model while developping 
> CTS). I do not think there is much useless complexity in GeoAPI. Just 
> some parts which are not mandatory for the general case (may be useful 
> for corner cases), and probably some dependencies to other parts of 
> the geoapi or to other (not yet standard) libraries like units :
>
> parameter package : I'm not convinced by the utility of 11 classes to 
> manage parameter values. I'm quite happy with my Measure class (may 
> need one more Parameter class to handle gracefully parameter names). 
> But I must have a closer look at GeoAPI about that.
>
> referencing package : factory hierarchy seems a bit complex. Not sure 
> it is useful to have factory subclasses for each subelement (datum, 
> ellipsoid....) I think most of time, we need to build a complete CRS 
> from one format/vendor/authority
>
> crs package : not much to say. 2/3 CRS seem very useful to me 
> (compound, geocentric, geodetic, geographic, projected, vertical), 
> others match specific needs (I'm not sure about ImageCRS, first time I 
> see that)
>
> cs package : not sure we need this hierarchy. I just implemented one 
> class to wrap axis and units. Although it seems that most cs classes 
> have no proper method
>
> datum package : not much differences between CTS and GeoAPI
>
> operation : my CoordinateOperation is more like MathTransform as it 
> has no reference to sourceCRS and targetCRS. Wonder if it should have...
> I think many concrete classes of CoordinateOperation (or 
> MathTransform) are needed, but I don't understand why so many 
> interfaces are needed (may be a nice design to handle projection 
> properties like conformal, equalsarea...).
>
> There is an important question here :
> In proj4, we get crs definitions, and each crs contains one set of 
> parameters to build the transformation to WGS84 which is the pivot CRS 
> (simple, but difficult to implement different transformations for the 
> same source and same target CRS)
> In EPSG (and GeoAPI model), transformations are first class instances 
> with a source and a target CRS, so that it is easy to define several 
> transformations from one CRS to another (I think it is well suited to 
> build transformations from EPSG database)
> In CTS, I followed a third approach where transformations are 
> determined from CRS definitions (as for proj4), but where each datum 
> can include several transformation definitions toward any other datum. 
> That way, one can use direct transformation between two local systems 
> without  converting coordinates to wgs84. Not sure it is the simplest 
> approach. GeoAPI has a clear separation between CRS definition and 
> CoordinateTransformation, which,I think, is a good thing.
>
> Michaël
>
>> One change to Proj4J I do intend to make is to change the 
>> CoordinateSystem class to be CoordinateReferenceSystem.  This follows 
>> the distinction made in GeoAPI, which seems to be a good idea.  
>> Whether an explict CoordinateSystem is required is another question - 
>> Proj4 doesn't support different CSes, so maybe it's not necessary 
>> right now.
> Yes, using CRS instead of CS is a good idea. I think you'll have to 
> deal with axis order or axis units at a point (even with proj4), but 
> may be you can include CS properties directly in CRS definition if you 
> don't want to add a class .
>
> Michaël
>>
>> Martin
>>
>

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