Stefan Steiniger a écrit :
>on 2:
>
>i think you both know transformations but just for completeness:
>in: BC Albers x,y + (h) = height over geoid)
>=> inverse-project x,y (+ h) to lat,lon + dh (dh = height over ellipsoid)
>(note: don't know how we will handle geoids)
>=> convert latlon+dh(NAD83) to geocentric x,y,z(NAD83)
>=> transform from xyz(NAD83) to xyz(WGS84/ETRS89 in europe?)
>=> convert xyz(WGS84) to latlon+dh (WGS84)
>=> project latlon+dh(WGS84) to UTM(zone) x,y,h
>
>
Good description Stefan,
It shows that for such transformation (with two different datum), the
central transformation is the one from datum1 - geocentric coordinates
to datum2 - geocentric coordinates.
Handling geoids is not easy. It appears that even for transformations
from system1 + altitude to system2 + altitude (same altitude system but
2 geographic datums), one may need to convert altitudes to ellipsoidal
height (based on the geoid description) as the height variation may
change the result for lat and lon..(only needed for a precision of mm or
cm).
Michael
>i think it was that way? Was it?
>
>notes:
>a) as first or final transformation may be added a local adjustment
>(e.g. this is for instance possible in Finland. They introduced such
>adjustment by a helmert transformation to let coordinate differences not
>to be too large)
>b) there may be speific formulas (as for the Swiss Projection) that work
>differently than the standard formulas to convert between x,y and lat/lon
>
>stefan
>
>Paul Austin schrieb:
>
>
>>Landon,
>>
>>1. For your point 3, I think defining a simple interface is essential
>>for what we are trying to do. This will allow us to do things such as
>>chaining of operations together which I'll cover in response to your
>>point 4. The key is to make the interfaces as simple as possible so as
>>to make it easy for people to use and re-use them. I would also not use
>>abstract base classes, instead I would have concrete classes that can be
>>parameterized for different implementations of that Projection (e.g.
>>there would be a say UTM class that would be parameterized on the UTM
>>zone rather than a UTM11, UTM10 classes). I would at a higher level have
>>some kind of factory that given a SRID would return the appropriate
>>implementation for end users to use.
>>
>>2. For your point 4 regarding the intermediate format, I do agree on
>>this in principal but not necessarily using the same approach. My vision
>>would be to support this via Chained operations. For example to go from
>>BC Albers (srid 3005, NAD83) to UTM Zone 10(srid 26910. NAD83) I would
>>have a chained operation consisting of BcAlbersToGeographics and
>>GeographicsToUTM(10). Now if you wanted to change between Ellipsoid then
>>you may have in the middle say a WGS84ToNAD83 operation in the middle.
>>
>>Paul
>>
>>
>>Sunburned Surveyor wrote:
>>
>>
>>>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
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>-------------------------------------------------------------------------
>>>>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
