Here is my suggestion for handling ellipsoid issues:
If the implementer of the transformation interface needs to move from
a target spatial reference system that does not use the ellipsoid of
the pivot spatial reference system we provide a helper class called
something like SevenParameterEllipsoid transformation that he can use
in his implementation internally. We could even create some built-in
parameters for common ellipsoids.
I still think the performance cost necessary for use of a common
ellipsoid as part of the "pivot" spatial reference system is worth the
simplicity it allows. But maybe I am wrong on this issue.
If I am incorrect, would we need to add an elliopsoid parameter to our
translation methods?
SS
On 9/10/07, Stefan Steiniger <[EMAIL PROTECTED]> 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.
>
> right.. so we need to be aware that we do not convert if the ellipsoid
> stays the same - on the other hand.. it is just "some math".. and if
> avoid rounding, then things should be the same for dx=(0,0,0)
>
> stefan
>
> > 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
