I would like more options rather than less; Derby has been rolled into the standard Java 6 install so it may be applicable to more users. I would *love* to tell applet developers to use Derby (enabling us to retire the epsg-wkt plugin).
Martin are you still up for a break out IRC session scheduled for this week? It looks like Thursday would be bet for me. One thing I would like to revisit with you is putting some sanity checks on the epsg modules so we can have more of them on the classpath with out conflict. Failing that I would like to limit the binrary download to *epsg-hsql* (not understanding that the epsg modules can conflict is a common user mistake). I would like to ensure that geotools can work out of the box (where people dump all the jars into their IDE and start hacking). Cheers, Jody Jody Martin Desruisseaux wrote: > 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 > ------------------------------------------------------------------------- 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
