Stefan,
I always liked getNorthing() and getEasting over getX and getY myself.
It must be a surveyor thing!
Still, getX and getY work to, as long as this is explained in the
Javadoc or developer documentation.
SS
On 9/10/07, Sunburned Surveyor <[EMAIL PROTECTED]> 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
