I want to add some comments to this conversation. I hope that I don't
really confuse things. I think Paul is heading in a great direction
with his interface, and I believe Michael is adding some important
things to the conversation.
First, I agree with Paul on avoiding the JTS Coordinate object at a
low level. We really need to work on primitive values like doubles,
and not JTS Coordinate objects. This will allow for wider adoption of
our library. Work with doubles and provide wrappers or utility methods
for JTS. I'd prefer to see all of our low-level coordinate
transformation code packaged in a single JAR, without a dependency on
JTS. We can this have a separate JAR that depends on JTS.
Secondly, I agree with Michael on using z values. I think we should
carefully consider methods that accept the Z value as a ordinate. As
Michael pointed out this is an important parameter in some
transformations.
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.)
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.
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
