Hi Micheal, 1. The reason I chose not to use an array of doubles as a parameter as an argument or return type is that what order do you pass in the parameters is it lon, lat or lat, lon for geographics. I did consider having getLat/getLon but that would be even more confusing.
In respect to using Coordinate this is a low level API not intended to be use by mere mortals so I went with memory efficiency over ease of use. I guess I just negated my argument to using double[] as that fits the mold of a low level API. 2. I'm flexible with the name CoordinateOperation could be fine. 3. 3D coordinates are supported, just at a higher level than the actual projection, as the z value is not projected the projection does not need to know about it. The library to do JTS conversions would need to make sure the z and any other ordinate values are copied to the resulting geometry. Landon brought up a good point about forward v.s. reverse transformations, I have it setup so that I support a forward and reverse methods, their could be an argument that there would only be one double[] transform(double[]) operation and have separate Classes for the forward v.s. reverse transformation. Paul Michaël Michaud wrote: > Hi Paul, > > I have some questions and remarks about your proposition : > > 1 - why do you use a setX setY method in the interface instead of > something like > Coordinate transform(Coordinate) > Coordinate inverseTransform(Coordinate) > or > double[] transform(double[]) > double[] inverseTransform(double[]) > I you don't want to be Coordinate implementation dependant > I also think that having separate setX, forward() and getX method may > not be very safe from a programmer point of view, because if you do > those operations in different places in the code, it may be hard to know > if the transformation has been done when comes the time to use the > getX/getY method. > I'm curious to know why you separated set, transform and get methods > > 2 - second point is about semantic > Projection is not appropriate as it is reserved to mathematical > transformation from the geographic coordinates to a plane. > In GeoAPI (geotools, epsg...), things are generally named as follows : > > CoordinateOperation : any operation on coordinates (it should be the > name of your interface) > > * Coordinate transformation (involving a Datum cahnge - > transformation is based on estimated parameters) : many useful > transformations involve a datum change (transformations from old > local datums to new international datum) > * Coordinate conversion (not involving any Datum change - conversion > is a mathematic transformation) > o Projection : most conversion operations are projections > > 3 - JTS and OpenJUMP can use 3D coordinates, and I think that the > coordinate operation package must be able to deal with those 3D > coordinates (transform altitudes to ellpsoidal heights for example). > > my 2 cents > > Michael > ------------------------------------------------------------------------- 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
