Jody wrote: "Frank W also had the idea of sharing conformance code (test cases etc...). I would recommend starting by sharing the test cases (maybe set up a quick facade so that the test cases could talk to each library in turn?)"
You may have to explain thise test cases to me in a little more detail. I 'm guessing that you mean a test that starts with one coordinate, performs a transformation on the coordinate, and tests the transformed coordinate to see if it meets an excpected value. Jowy wrote: "Long term setting up a common referencing library (counterpoint to JTS) would be a good subject to a code sprint. We do need to recognize up front that referencing should be a little bit away from JTS, GeoTools for example has a second Geometry implementation in addition to JTS." Agreed. We need to recognize that not all projects will use JTS. I think we can have a common CRS transformation code that operates on a generic x,y,z or even just x,y coordinate Object. We can add utility code to the library that can convert from these generic Coordiante objects to and from more specific Geometry classes. This is the approach I took with the deegree transformation code, as it didn't operate directly on JTS Geometry objects. Michael wrote: "Something I'd like to add about cooperation with other projects (because I feel somewhat guilty not to play the integration card) : Geotools, Deegree and OJ are three different projects and it is not easy to pick-up code from one project, put it in another and realize later than the former one has evolved... Code sharing is easy, when some parts of a project is mature, independant and stable (as JTS is), otherwise, sharing code can quicky drive to forks and confusion (not worst than duplication, but not much better...)." This is an excellent point Michael. I hope we can avoid some of these problems by determining a road map for each individual CRS library. This would be a key element of any collaboration plan, as I believe our goal to have a single shared library, at least at a lower level, must be realized over the course of months or a couple of years. The only way this works is if each project can guide the evolution of their own CRS libraries towards the common goal. Thanks for all the comments. I hope that the conversation will continue. I'd like to get some input from Paul and the deegree folks. I may also post a short message to the OSGeo Discussion list. The Sunburned Surveyor On Fri, May 2, 2008 at 10:52 AM, Michael Michaud <[EMAIL PROTECTED]> wrote: > > Sunburned Surveyor a écrit : > > Michael wrote: " I'm on the way of writing a new library for > > coordinate transformation, > > and I'm interested by your experience, as my goal is to manage properly > > 3D and grid-based transformations, not only projections and BW > > transformations." > > > > Is there any way you could integrate this code into the CRS > > transformation library written by deegree? I'm nearly done > > incorporating their CRS code into a simple transformation for > > OpenJUMP. I think everyone would benefit from consolidated efforts on > > projection code. > > > You're right to invite me to consolidate existing code instead of > reinventing the wheel. > I will be totally honnest, and tell you that writing transformation code > again is *not* very reasonable, but it is very *formative* for me. > I did not start from any existing code, but I have begun several years > ago with epsg database and OGC in mind, and after many refactorings, the > general architecture of my code is quite close to deegree's one (and > probably not so far from geotools). > My immediate goal is to have a library able to make usual coordinate > transformations + specific transformations which are very useful in > France but not yet supported by other libraries without customization. > After that, I'll see the problem of consolidation with deegree's code > and the problem of integration into OpenJUMP / OrbisGIS. Nothing is done. > > Something I'd like to add about cooperation with other projects (because > I feel somewhat guilty not to play the integration card) : Geotools, > Deegree and OJ are three different projects and it is not easy to > pick-up code from one project, put it in another and realize later than > the former one has evolved... Code sharing is easy, when some parts of a > project is mature, independant and stable (as JTS is), otherwise, > sharing code can quicky drive to forks and confusion (not worst than > duplication, but not much better...). > > Michaël > > > > > I'm trying to talk Paul Austin into the same thing! :] > > > > Maybe we could set up an informal group to promote collaboration on a > > unified Java library for spatial reference systems and spatial > > reference system transformations? We could use the deegree code as a > > starting point and could build from there. We might even get GeoTools > > involved down the road... > > > > We really need to work together more. We could accomplish a great deal > > for everyone this way. > > > > I hope it is at least worth dicussing the possibility. > > > > The Sunburned Surveyor > > > > On Fri, May 2, 2008 at 7:41 AM, Michael Michaud <[EMAIL PROTECTED]> wrote: > > > >> Hi Peppe, > >> > >> As you mention, bursa-wolf transformation is not always enough to make > >> precise transformation between old local reference system and new > >> spatial reference system. > >> The advantage is that it relies on a set of only 7 parameters and a well > >> known algorithm. > >> To do more precise transformations, countries often use grids to "adapt" > >> the BW parameters locally or to apply corrections on the results. > >> In France, if old system coordinates are transformed towards the new > >> system with a BW transformation (indeed a simple translation), one get a > >> precision of 1-2m (5m at worst), which is not that good. > >> It is now recommended to use a grid to interpolate precise parameters > >> which makes it possible to get a precision of a few centimeters. > >> I don't know what is the system used in USA, but I know that Canada and > >> Australia also use grid based transformations (or corrections?) based on > >> NTV2 grid format. > >> I'm on the way of writing a new library for coordinate transformation, > >> and I'm interested by your experience, as my goal is to manage properly > >> 3D and grid-based transformations, not only projections and BW > >> transformations. > >> > >> OJ warping tool : you did an interesting remark about using warping tool > >> to calculate local parameters. In the cases I know, precise parameters > >> are interpolated on a regular grid, which is enough to have a good > >> precision. Using another type of interpolation (with warping tool) may > >> be useful if BW parameters are given for some random places. Is this the > >> case for Italia ? Are BW parameters associated to a precise place or to > >> regions ? > >> > >> The error you oberved between WGS84 and ED50 is very important. I > >> checked the BW parameters recommended in France between those systems, > >> and I found values which are about half the error you observed. Did you > >> make sure that you applied the transformation in the right direction > >> with the right sign ? > >> > >> Michaël > >> > >> Giuseppe Aruta a écrit : > >> > >> > >>> Hi, > >>> I did a test with the CTS plugin. > >>> As control I used Taspunto, a software for Italian coordinate > >>> transformation edited by Italian government. This software doen't use > >>> formulas for transformation but on a grid of points (1500) in the > >>> Italian territory and surroundings. It is considered to give an > >>> accuracy of less than 1 metre. > >>> Finally, opening all files with OJ and using Edgar plugin, I was able > >>> toI define that EPSG parameters for helmet transformation gave an > >>> error between 0.5-2 metres on mainland (continental Italy). Close to > >>> easter side of Italy (Puglia) the error is almost of 8 metres. > >>> Now 0.5-2 metres is more than acceptable, since EPSG spec gave an > >>> accuracy of 4 metres. > >>> I think that Edgar plugin works, at least between WGS84 and ROMA40. > >>> So I wiull prepare an (un)official config file for Italian > >>> transformation with the BW par. 1) Italy mainland, 2) Italy Puglia, 3) > >>> Italy Sardinia and 4) Italy Sicily. > >>> Nothing to do between WGS84 and ED50, the error is still of 400-600 > >>> metres (any idea?) > >>> > >>> Regards > >>> > >>> Peppe > >>> */Giuseppe Aruta <[EMAIL PROTECTED]>/* ha scritto: > >>> > >>> Hi all, > >>> working around Edgar Soldin's Coordinate transformation plugin I > >>> finally reached the (un)-famous problem of setting Bursa-Wolf > >>> parameters (BW) for the tranformation between different > >>> datum/projections. > >>> I realize that the problem is not so simple as it is shows: > >>> 1) despite the EPSG official archive on net > >>> (http://www.epsg-registry.org/) and other informations, there is > >>> no unique BW parameters even between the same transformation. > >>> For instance, searching on EPSG register, EPSG1660 (transformation > >>> from Italian ROMA40 to WGS84) I had the official parameters for > >>> Italy mainland with a maximum error of 4 metres. > >>> Well, I tested these parameters in some places "mainland" in > >>> Italy, I had an errror even of 60 metres, for instance, in > >>> Southern Italy > >>> More than this I discover that some regions/areas defined their > >>> own parameters. > >>> This happens becaue the transformation between ROMA40, ED50 e > >>> WGS84 is not correlated by geometric relations or simple > >>> math but by comparing coordinates of some points within different . > >>> > >>> > >>> The resault is this: > >>> > >>> Edgar's plugin works fine but people need to know the BW > >>> parameters for the area of their interest. And sometimes this is > >>> not easy to do..... (in respect to EPSG, geotools, etc). I image > >>> this is a common problem in Europe > >>> > >>> ************************************************************ > >>> > >>> I will go anyway to write the tutorial page about projections on > >>> wiki since this could be useful for who is interested. I will also > >>> put on wiki some modified cs.conf (configurations) files > >>> optrimized for local transformation (Umbria-Tuscany, South Tyrol > >>> and Campania-Basilicata). > >>> Note that there is no problem with transformation between crs that > >>> don't BW parameters (eg. WGS84 to WGS84/UTM..) to be used for GPS > >>> fanatics! > >>> > >>> ********************************************************** > >>> The bulk of my letter is the follow notes: > >>> Since OpenJUMP has some warping tools (Warp and even New affine > >>> transformation). Is it possible to calculate local Bursa-Wolf > >>> parameters using these tools on some reference points? Does > >>> somebody thought about before? > >>> This probabily could be an interesting area of research (for > >>> pratical usage) of OpenJUMP: A way or a plugin that calculate > >>> local Bursa Wolf parameters. > >>> > >>> I pass these questions expecially to Europian collugues since this > >>> maybe is acommon pronblem: Gauss (Kruge, Boaga, etc) vs WGS84 or > >>> ETRS89 > >>> > >>> *************************************** > >>> > >>> Regards and thanks for the answers > >>> > >>> Peppe > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> Tante idee per la salvaguardia del pianeta su > >>> Yahoo! for good > >>> > >>> <http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52436/*http://it.promotions.yahoo.com/forgood/environment.html>.------------------------------------------------------------------------- > >>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > >>> Don't miss this year's exciting event. There's still time to save > >>> $100. > >>> Use priority code J8TL2D2. > >>> > >>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________ > >>> Jump-pilot-devel mailing list > >>> Jump-pilot-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> Tante idee per la salvaguardia del pianeta su > >>> Yahoo! for good > >>> <http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52436/*http://it.promotions.yahoo.com/forgood/environment.html>. > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> ------------------------------------------------------------------------- > >>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > >>> Don't miss this year's exciting event. There's still time to save $100. > >>> Use priority code J8TL2D2. > >>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> 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 the 2008 JavaOne(SM) Conference > >> Don't miss this year's exciting event. There's still time to save $100. > >> Use priority code J8TL2D2. > >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > >> _______________________________________________ > >> 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 the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > 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 the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > 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 the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
