Working with so many smart people can really be a pain. :] Michael wrote: "To take an even more trivial example, imagine you just have to change the length unit (meter to feets) or the angle unit (degrees to grads) : transforming the local data to wgs84 before any operation would be a very heavy transformation compared to what is really need."
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. 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
