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

[Sunburned Surveyor]

Michael wrote: "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.
"

It seems from Michael's statement that we are dealing with two types
of transformations. The first requires no datum transformation, but
some other more simpler transformation. (Example: California State
Plan Coordinates Metric to California State Plane Coordinates Survey
Feet.) The second requires a datum transformation. (Example: NAD83 to
NAD27.)

It seems you could have code that could check the source and
destination CRS definitions to see if the first simpler type of
transformation was possible. If not, a pivot datum like WGS 84 would
be used by default. At least, this is how I thought about designing
things when I was considering my own projection library.

Maybe this is the solution Michael was describing?

I imagined an interface that looked like this:

public interface TransformationInterregator
{
public abstract boolean isSimpleTransformationPossible(CrsDefinition
source, CrsDefinition dest);

public abstract boolean isVerticalDatumChangePossible(CrsDefinition
source, CrsDefinition dest);
}

That might be a little crude. But the idea is to check for the
possibility of using a simple transformation before using a
transformation with a datum conversion.

SS

2010/1/18 Martin Davis <mbdavis at refractions.net>:
> 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
>
> _______________________________________________
> Proj4j mailing list
> Proj4j at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/proj4j
>