Michael,
I avoided the return type as I don't want to have the extra object
creation, I consider the double[] array parameter to be a temporary
array used just for the one or more operations, rather than the actual
storage of the ordinates. By this I mean when calling an operation you
must expect the values of that array to change. If you don't want that
then create another array before calling the operation.
I would probably also use a List<CoordinateOperation> internally within
the ChainedOperation class but provide constructors for the array and
List forms.
Paul
Michaël Michaud wrote:
> Hi Paul,
>
> That's close to what I can imagine.
> Can you explain why you choosed to return void instead of double[]. To
> avoid object creation ?
> Returning a double[] would have been clearer for me, but may be
> returning void is more efficient...
>
> getInverseOperation is not limited to Projection. Datum transformation
> (usually translation or helmert transformation) are also invertible (in
> the general case). May be getInverseOperation should be available in the
> main CoordinateOperation interface along with a boolean isInvertible
> method. In fact, I don't know exactly why we should use a
> getInverseOperation from a CoordinateOperation instead of implementing
> and instanciating the inverseOperation as a first class object.
>
> I like ChainedOperation.
> My version used a List instead of an array, but I'm ok with an array.
>
> Michael
>
> Paul Austin a écrit :
>
>
>> How about the following interface? The ordinates array has the same
>> semantics as ordinates in a JTS CoordinateSequence. The values in the
>> ordinates array are modified in place by the CoordinateOperation.
>>
>> public interface CoordinateOperation {
>> void perform(double[] ordinates);
>> }
>>
>> For projections you may have an interface such as the following as a
>> convenience to get both the forward and inverse operations.
>>
>> public interface Projection {
>> CoordinateOperation getOperation();
>> CoordinateOperation getInverseOperation();
>> }
>>
>> A chained operation may look like the following.
>>
>> public class ChainedOperation implements CoordinateOperation {
>> private CoordinateOperation[] operations;
>>
>> public void perform(double[] ordinates) {
>> for (CoordinateOperation operation : operations) {
>> operation.perform(ordinates;
>> }
>> }
>> }
>>
>> Paul
>>
>> Paul Austin wrote:
>>
>>
>>
>>> I've come up with a very simple interface for projection algorithms. The
>>> purpose of this is to be model neutral (not tied to JTS), as such it is
>>> not for use by end users but instead for use in higher level libraries
>>> that would work on JTS geometries.
>>>
>>> public interface Projection {
>>> void forward();
>>>
>>> void reverse();
>>>
>>> double getX();
>>> void setX(double x);
>>>
>>> double getY();
>>> void setY(double y);
>>>
>>> }
>>>
>>>
>>> To perform a forward projection the code would be as follows.
>>>
>>> projection.setX(lonDegrees);
>>> projection.setY(latDegrees);
>>> projection.forward();
>>> x = projection.getX();
>>> y = projection.getY();
>>>
>>>
>>>
>>> Reverse projection would be similar.
>>>
>>> projection.setX(xMetres);
>>> projection.setY(yMetres);
>>> projection.reverse();
>>> lonDegrees = projection.getX();
>>> latDegrees = projection.getY();
>>>
>>> NOTE: The interface is not thread safe.
>>>
>>> The design goals were it must be simple and not require any temporary
>>> objects.
>>>
>>> A JTS wrapper for this would have the following two basic methods
>>>
>>>
>>> public Coordinate forward(double x, double y, double z) {
>>> projection.setX(x);
>>> projection.setY(y);
>>> projection.forward();
>>> Coordinate coordinate = new Coordinate(projection.getX(),
>>> projection.getY(),z);
>>> forwardPrecisionModel.makePrecise(coordinate);
>>> return coordinate;
>>> }
>>>
>>> public Coordinate reverse(double x, double y, double z) {
>>> projection.setX(x);
>>> projection.setY(y);
>>> projection.reverse();
>>> Coordinate coordinate = new Coordinate(projection.getX(),
>>> projection.getY(),z);
>>> reversePrecisionModel.makePrecise(coordinate);
>>> return coordinate;
>>> }
>>>
>>> plus a number of other methods to deal with all the JTS Geometry types,
>>> see attached for full implementation. Note that there could be a
>>> performance optimization for coordinate sequences to directly deal with
>>> the Projection interface.
>>>
>>> Most projections go to/from Geographics to a Cartesian system to go from
>>> one Cartesian to another Cartesian you would need a chained projection
>>> which goes from one to another.
>>>
>>> The last piece in the puzzle is to have a ProjectionFactory that can
>>> create projections from EPSG srid codes. There can be many factory
>>> implementations, e.g. one to wrap FME, one to wrap the Java Projection
>>> Library, one for JUMP specific projections and one for GeoTools. You
>>> would then interact with an instance of the factory to create your
>>> projections and then use either the Projection interface or the
>>> JtsProjection wrapper.
>>>
>>> What do you guys think?
>>>
>>> Paul
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>>
>>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>>
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
