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.
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
