Sunburned Surveyor a écrit :
>Michael wrote: "CoordinateOperation should be the main interface."
>
>O.K. - The only thing I find a little confusing about this is that a
>CoordinateOperation might have nothing to do with spatial reference
>systems. I might be simpling translating all coordinates by a single
>XYZ shift, for example.
>
>
A simple XYZ shift has to do with spatial coordinates, as it is one of
the possible operation
to transform geocentric coordinates from one datum to another. ;-)
Michael
PS : other datum transformations are helmert transformations, with
rotation and scale parameter added to the translation..
>But this probably isn't all that important. We know what we want to
>do, and a Rose by any other name smells just as sweet. :]
>
>Michael wrote; "but geodesy is a bit more complicated than converting feet to
>meters, and converting a coordinate to the central wgs84 may be a waste
>of energy if you just wante to change the projection but stay in your
>local datum (in this case, your local datum with your local ellipsoid
>should be used as the pivot, and coordinates should just be converted to
>this system then reprojected in the new projection."
>
>I didn't think about this case. But perhaps that is a performance cost
>we can accept in the name of simplicity? After all, it would be hard
>to design a "fits-most" or "fits-all" transformation library that
>performs well for all scenarios. I think our "in-between" spatial
>reference system or "pivot" as you call it should work well for just
>the majority of cases.
>
>SS
>
>
>
>On 9/10/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
>
>
>>>Thirdly, I think it may be a mistake to create a separate
>>>CoordinateOperation interface. I believe this will lead us down the
>>>GeoTools path. A path with many interfaces and classes. What we want
>>>to do is pretty simple, provide ordinate values in one system and get
>>>ordinate values back in some other system. Let's do that with just one
>>>interface. This will make things incredibly simple for users of the
>>>library, and will place the burden of the details on the interface
>>>implementers, where I think it should be. We can always provide all
>>>sorts of helper classes and abstract classes that can be used by
>>>implementers. (I was thinking about this last night. It really work
>>>great. For example: I'm working on a Gnomic map projection between the
>>>equator and the north pole. Once this projection is finished I can
>>>create an abstract class. Once the abstract class is complete all
>>>someone else needs to do is change the parameters. The algorithm's
>>>remain the same.)
>>>
>>>
>>>
>>>
>>CoordinateOperation should be the main interface. It will be difficult
>>to avoid completely subinterfaces or abstract classes as there are so
>>many operation families, but I agree things should be as simple as
>>possible. And any programmer should be able to add his transformation
>>implementing directly CoordinateOperation. My example with
>>CoordinateConversion, CoordinateTransformation, CoordinateProjection was
>>just to mention that Projection was not the exact word for the general
>>interface. But I don't say we need as many interfaces.
>>
>>
>>
>>>Finally, I want to address the issue raised in this question of Michael's:
>>>
>>>"I'm not sure how getX, getY avoid the confusion.
>>>IMHO, coordinate order is relative to the coordinate system definition
>>>(source crs and target crs may have different order), and should not be
>>>fixed in the coordinate operation interface (how do you use setX, setY,
>>>getX, getY to convert, say a geo lat/lon coordinate system to a geo
>>>lon/lat coordinate system ?)"
>>>
>>>This is why I think it is really important to define a generic
>>>"in-between" spatial reference system. This really simplifies things.
>>>
>>>
>>>
>>>
>>Yes, this is the best way to go. Indeed, I think most libraries works
>>more or less the way you describe, and the main
>>CoordinatereferenceSystem database (EPSG) define hundreds of datum from
>>a pivot-datum (pivot ?) which is the WGS84.
>>It may be difficult to stick to this principle in some particular cases
>>(if you want to implement two kinds of transformation - let say a
>>precise one and a fast one - from a system to another), but it is the
>>most efficient in the general case.
>>... but geodesy is a bit more complicated than converting feet to
>>meters, and converting a coordinate to the central wgs84 may be a waste
>>of energy if you just wante to change the projection but stay in your
>>local datum (in this case, your local datum with your local ellipsoid
>>should be used as the pivot, and coordinates should just be converted to
>>this system then reprojected in the new projection.
>>
>>Michael
>>
>>
>>
>>>Let's use another analogy that may help:
>>>
>>>We want to write a simple interface that transforms monetary amounts
>>>in different currencies. Would you try to create a group of classes
>>>and interfaces that transform directly from any one currency to any
>>>other currency? Absolutely not! A much simpler system would result if
>>>you chose an "in-between" currency. You would want to choose a common
>>>currency like US Dollars or the Euro. Then your interface would look
>>>something like this:
>>>
>>>public interface transformCurrency
>>>{
>>>
>>>public double getAmountInUSDollars(double argAmountInLocalCurrency);
>>>
>>>public doube getAmountInLocalCurrency(double argAmountInUSDollars);
>>>
>>>}
>>>
>>>I think this "in-between" coordinate system should be a spherical
>>>coordinate system that doesn't involve projections and uses an
>>>ellipsoid that fits the Earth's overall surface well. To me this
>>>spatial reference system would be WGS-84, but there might be others
>>>that work.
>>>
>>>I have attached the interface I am currently using. I think we can
>>>merge it with Paul's interface to come up with something simple that
>>>meets all of our needs.
>>>
>>>The Sunburned Surveyor
>>>
>>>
>>>
>>>
>>>
>>>On 9/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>
>>>>I got used to use North and East (instead x,y which is turned in geodesy
>>>>and math and latlon which is purely geographic)
>>>>
>>>>so what about getNorthCoord and getEastCoord?
>>>>Usually one speakes also from False Easting (and Northing) for the bias
>>>>of the origin point.
>>>>
>>>>i will read the rest of your emails later
>>>>
>>>>stefan
>>>>
>>>>Michaël Michaud schrieb:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Paul
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>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'm not sure how getX, getY avoid the confusion.
>>>>>IMHO, coordinate order is relative to the coordinate system definition
>>>>>(source crs and target crs may have different order), and should not be
>>>>>fixed in the coordinate operation interface (how do you use setX, setY,
>>>>>getX, getY to convert, say a geo lat/lon coordinate system to a geo
>>>>>lon/lat coordinate system ?)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I did consider
>>>>>>having getLat/getLon but that would be even more confusing.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Agree. These methods are ok for classes implementing coordinate
>>>>>operation and expressing transformations from any coord ref sys to a
>>>>>geographic coodinate reference system, but not in the general case.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Sorry, I'm not sure I understood this point. Do you mean that for a low
>>>>>level API, you should have considered double[] as well as getX, getY ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>That's right for projection (mathematical transformation from geographic
>>>>>coordinates to projected coordinates), but not for general coordinate
>>>>>transformations like lat/lon/height to easting/northing/altitude where
>>>>>altitude is determined using lat, lon and a geoid model. Coordinate
>>>>>transformations include also transformation from geographic
>>>>>(lat/lon/height) to 3D geocentric system and geocentric to geographic.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Yes, I'm not sure what is the better way for inverse transformation.
>>>>>Inverse transformation may use :
>>>>>- the same parameters as the direct transformation but with opposite signs
>>>>>- the same algorithm but with different parameters
>>>>>- a different algorithm (ex. geographic 2 projected, projected 2
>>>>>geographic)
>>>>>
>>>>>May be direct and inverse operations must be implemented in separate
>>>>>classes in the genarl case as you suggest, and eventually, some special
>>>>>implementation of coordinate operation may have a "invertible" property
>>>>>to be able to do the inverse transformation without creating a new
>>>>>coordinate operation instance (for ex, prime meridian change).
>>>>>
>>>>>Michael
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>-------------------------------------------------------------------------
>>>>>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
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>/*
>>>>* Project Name: SurveyOS Spatial Reference Systems
>>>>* Original Organization Name: The SurveyOs Project
>>>>* Original Programmer Name: The Sunburned Surveyor
>>>>* Current Maintainer Name: The SurveyOS Project
>>>>* Current Maintainer Contact Information
>>>>* E-Mail Address: The Sunburned Surveyor
>>>>* Copyright Holder: The SurveyOS Project
>>>>* Date Last Modified: Sep 5, 2007
>>>>* Current Version Number: 00.00.01
>>>>* IDE Name: Eclipse
>>>>* IDE Version: 3.2.1
>>>>* Type: Java Class
>>>>*/
>>>>package net.surveyos.sourceforge.srs;
>>>>
>>>>public interface ISRSTransformation
>>>>{
>>>> public double getLocalXOrdinate(double argWGS84Latitude, double
>>>> argWGS84Longitude, boolean argIsEllipsoidHeight);
>>>>
>>>> public double getLocalYOrdinate(double argWGS84Latitude, double
>>>> argWGS84Longitude, double argHeightOrEleveation, boolean
>>>> argIsEllipsoidHeight);
>>>>
>>>> public double getEllipsoidHeight(double argWGS84Latitude, double
>>>> argWGS84Longitude, double argEleveation);
>>>>
>>>> public double getElevation(double argWGS84Latitude, double
>>>> argWGS84Longitude, double argEllipsoidHeight);
>>>>
>>>> public String getSpatialReferenceSystemName();
>>>>
>>>> public boolean isGeoidSupported();
>>>>}
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>-------------------------------------------------------------------------
>>>>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
>
>
>
>
-------------------------------------------------------------------------
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
