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
