Hi again The software from which the CRS is coming from is Terralib (http://www.terralib.org/), for which we have developped a GeoTools DataStore (we intend to release it to the GeoTools community as soon as it is ready to go). The library is C++ by the way, we made the plugin using JNI.
In reality, we ourselves are messing with Terralib's WKT generation to fix it and put it up to par with EPSG standards, but the parameters come from Terralib. Terralib does not have an EPSG database and works with a set of known CRSs, for which it stores parameters. However, as I said in a previous e-mail, it stores parameters in a different manner (e.g., flattening instead of inverse flattening). So, in the end it has these numbers which ARE exact, but needs to write them to a text WKT file. Unfortunately, if for instance it uses all possible digits and writes down the exact number, then GeoTools won't like it, because the EPSG official value only has a certain level of precision. Yeah, one solution to the issue would be to mess around some more with the Terralib code and compute the correct EPSG code for the CRS overall (which it doesn't do right now), but I'm not entirely sure that is always possible without having the EPSG database itself to look it up considering all the CRS's parameters. If that's an easy task (I'm not so familiar with how EPSG codes are generated), then I guess it would be the right solution in my particular case. Is it? However, in a general way, I still think it's odd that writing numbers with a much-too-high precision makes the CRS unrecognizable. Thinking about it, if the value comparison within GeoTools considered only the level of precision defined in the EPSG database, then anyone could make it work by writing the numbers with a high precision. I guess that kind of change could be made to DefaultEllipsoid.equals() for this particular case, but maybe some other comparisons would need to be updated too. What do you think? Thanks again Milton Andrea Aime wrote: > Milton Jonathan ha scritto: >> Hello again, and thanks a lot for the fast feedback! >> >> Well, in my really humble opinion, if the guy stated that the code is >> EPSG:6618, then that is what he wants, regardless of any imprecisions >> in the WKT. If he wanted something else, why put the code? >> >> Looking at things from my perspective, I think it makes some (but >> little) sense to enforce Datum names, if that is a standard, but I >> agree that checking the parameters when the name differs makes a lot >> more sense. >> But I really think that enforcing the numbers in a text file to have >> exactly the same precision as in the EPSG database is kinda out of >> control. In my particular case, the software that generates the WKT >> has the flattening and computes its inverse to output the WKT, meaning >> that all those numbers are floating points with a lot of digits after >> the point. Since different CRSs have different official precisions, I >> think there is no way one can guarantee that the WKT will work in >> GeoTools unless each number is printed with a different precision >> according to the official EPSG values. Kinda complicated, in my opinion.. > > What is the software that is generating correct EPSG ids without correct > parameter values? Please understand that a minor difference in the datum > parameters leads to many meters of error in reprojections. > > I come in contact with a lot of .prj files but most of the time the > authority ids are missing or referencing another authority (ESRI), > whilst the params are usually true to the EPSG database. > > Cheers > andrea > > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
