Andrea Aime a écrit : > Martin, do you think there is a chance to have a text based authority > providing the same information amount as the database? Maybe using a non > standard, extended WKT?
We could imagine a WKT extension, but I'm not sure if we can put the same amount of information in it. We would have a lot of new objects to define (TemporalCRS, CoordinateOperation, OperationMethod, etc.) or existing object to extend (Datum, CoordinateSystemAxis, etc.). In WKT, the notion of CoordinateSystem is merged with CoordinateReferenceSystem because the former didn't existed in pre-ISO 19111 OGC specification (namely OGC 01-009). One consequence is that there is no way to distinguish a GeocentricCRS using a CartesianCS from a GeocentricCRS using a SphericalCS. Extending the WKT format may not be enough; we may need to modify the existing format as well. I believe that extending the WKT format to provide the same level of information than the EPSG database would be a lot of work. Adding some properties like "area of interest", or "scope" would be relatively easy, but the EPSG database is more than just a few additional properties. Adding CoordinateOperation chains would be a more complicated task for example. If we decide to put this amount of work in a textual representation of CRS, I believe that the energy would be better invested in a XML parser for CRS. The GML representation of CRS can contains much more than WKT. > Just for the record, I have here, sitting on my disk, a clone of > epsg-hsql using H2. A build with standard unit tests take the same time > as HSQL, one with extensive tests is 50% faster that HSQL. HSQL was choosen in part because it was the first one I succeed to setup and get running, and partially because it is shipped with OpenOffice. It is probably not the best choice. I think that Chris Holmes is looking toward H2 for Geoserver, so we should probably uses the same database engine for EPSG. > But overall the same issues remain, the authority is very slow and bulky > if you need just a few of the SRS compared to a stripped down WKT file. Maybe it is slow because of H2 or HSQL database startup time (including classloading)? If so, maybe the impact would be lower if H2 is used anyway by Geoserver for other purpose, since the database engine would be up and running? If it still slower, then a possible approach would be to create the stripped down WKT file on the fly. An (yet another) authority factory decorator could write the most recently used CRS in a property file. In the current state of affairs, we get user request for adding missing CRS in the property files, so the property file is not stripped down anymore (if we don't put the full EPSG content, we will always miss a CRS useful to someone). Using it as a cache generated on the fly would fit better the user's needs. A variant of the above is to serizalize the CRS on the fly rather than writting them in CRS form. Serializing CRS is easy and should preserve all informations, at the opposite of WKT formatting. In any case, I would be nice to commit your H2 variant to Geotools SVN (trunk) if you agree :). > There is also another issue that I'm trying to discuss with the H2 > author here: > http://groups.google.com/group/h2-database/browse_frm/thread/ef14b5a50a3d8961 An other solution would be to select Derby as a replacement of HSQL, instead of H2. If I'm understanding right, Derby would avoid completly the need to write into a temporary directory: http://db.apache.org/derby/docs/10.3/devguide/cdevdvlp24155.html I have seen contradictory statements about Derby performances. Some said that Derby is slower, some said that it is faster in some situations. It seems to depend on our application. The debate is quite similar to the one opposing PostgreSQL to MySQL. Some said that MySQL is faster, but PostgreSQL guys point out that MySQL performs lockings on a table-basis while PostgreSQL performs lockings on a row-basis, and consequently performs better in highly concurrent environments. I have see the same arguments in the H2 vs Derby debate (H2 is faster, but locks whole tables while Derby performs lockings on a row-basis). Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
