Michael wrote: "JtsTransformFactory.createCoordinateConversion("EPSG:3005",
"EPSG:26910");
to be able to manage other crs databases."
Good point Michael.
Michael wrote: "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. ;-)"
I knew you were going to say that. :]
It seems that CoordinateOperation doesn't really indicate to me that
something is happening with transformations between spatial reference
systems. But this really isn't that important. I guess I'm more easily
confused that others. :]
SS
On 9/10/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> 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
>
-------------------------------------------------------------------------
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
