>I don't see a way around the cost of moving to a geographic "pivot" >spatial reference system while preserving a single-interface API >simplicity. That is something I would really love to see. To me the >wasted CPU cycles are less evil than an API where the client code >needs to determine a chain of transformations. > > Hi, may be the misunderstanding is you speak about the client code and I think about the developper's code (I'm not sure what you mean by client code). I agree the public api should be as simple as createCoordinateOperation(from, to) I just tried to hint at some of the stuff which has to take place behind the scene and which will need a little more than tranform from projection to lat/lon and from lat/lon to another projection. I'm also convinced one can keep things quite simple, otherwise, I would have adopted geotools since a while :-)
Michael >I will try to fall back to my other analogy again: > >If you were designing a currency transformation interface you would >sometimes (maybe often) deal with transformations between currencies >with a lot of similarities. For example, maybe the two currencies deal >only with a single "unit" of currency and fractional portions of that >single unit. Like the US dollar and US cents. It would be very easy to >convert from that currency to another currency with a single "unit" of >currency and fractional portions of that single unit. But you might >decide to do some "wasted" steps in that transformation to have a >single interface that also supports more complex currency conversions. > >Does that analogy really stink? Maybe I need to try thinking of another one... > >SS > >On 9/10/07, Paul Austin <[EMAIL PROTECTED]> wrote: > > >>Michael, >> >>I agree with all you said. I guess my statement there was regarding a >>particular type of CoordinateOperation. >> >>Paul >> >>Michaël Michaud wrote: >> >> >>>Paul Austin a écrit : >>> >>> >>> >>> >>>>Landon, >>>> >>>>Agreed each CoordinateOperation class should only know how to go in >>>>either the direction Geographics->ProjectedSystem or >>>>ProjectedSystem->Geographics. It should not need to know about any other >>>>systems. >>>> >>>> >>>> >>>> >>>> >>>Coordinate operations are not just Geographics->Projected and >>>Projected->Geographics. This is only the projection part (first and last >>>operation of Stefan's transformation chain). >>>Many operations involve a datum change. When you go from a local datum >>>to wgs84 for example, you must consider that the new coordinate system >>>has another origin, another orientation, and the ellipsoid you will use >>>to calculate lon and lat has another shape ! This transformation has no >>>common point with a projection, but most people do not differentiate >>>both operations. >>>If you want to apply the pivot principle, you have to say : each >>>CoordinateReferenceSystem has to know how to go from and to Geocentric >>>WGS84, but again, it may be much calculations for cases where only one >>>local datum is involved. >>> >>>Michael >>> >>> >>> >>> >>>>Paul >>>> >>>>Sunburned Surveyor wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Paul wrote: "My vision for end user code. >>>>> >>>>>JtsTransform transform = >>>>>JtsTransformFactory.createCoordinateConversion(3005, 26910);" >>>>> >>>>>I like it! >>>>> >>>>>My concerns are about how the layer underneath this works. I think a >>>>>system where the steps necessary for the transformation are left to >>>>>the implementer of a projection and not the code provided with the "to >>>>>and from" spatial reference systems is the best. >>>>> >>>>>Here is another way of saying it: In an ideal system the code >>>>>performing the actual transformation should have no idea of what the >>>>>eventual destination spatial reference system is. It should only need >>>>>to know how to get a coordinate from itself to the pivot spatial >>>>>reference system. >>>>> >>>>>SS >>>>> >>>>>On 9/10/07, Paul Austin <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Landon, >>>>>> >>>>>>My vision for end user code. >>>>>> >>>>>>JtsTransform transform = >>>>>>JtsTransformFactory.createCoordinateConversion(3005, 26910); >>>>>> >>>>>>Paul >>>>>> >>>>>>------------------------------------------------------------------------- >>>>>>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
