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