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

Reply via email to