From: Bryce L N. <bno...@fs...> - 2005-04-21 16:06:29
|
> Yes. Richard Didier prepared a HSQL database will all EPSG data, bundled > in a JAR file. But there is some aspects of HSQL that make me > uncomfortable: all data are specified as SQL scripts bundled in the JAR, > with thousands on "INSERT INTO ... VALUES ..." statements, which seems > really inefficient to me. But it seems to be the way HSQL work. It is > also my understanding that all data are loaded in memory, which is again > inefficient (why keep 3000+ CRS in memory when we usually uses only a > few of them)? So we have a choice: The 3000+ CRS in memory problem is what was wrong with my textfile CRS factory, and the property file CRS factory. If HSQL doesn't fix that, it better do something else really snazzy. > 2) Either we search for an other database engine (any idea?) This suggestion requires the use of Geotools' CRS & CS abstraction layer. Berkeley DB / J. (Not SQL) 100% Java Geotools creates DB <-> Object bindings Geotools defines indicies on parameters parameters which are commonly searched It manages object caching. It creates portable binary files as persistence mechanism. Upside: Database initialized once, from the authority factory. Authority-specific code is only used to create the database. Utilizes the abstraction layer present in geotools. Not tied to any particular authority. Same code handles multiple authorities. Users deal with same code/classes regardless of authority. Deals only with completely constructed objects. The pre-produced binary CRS database of objects can be screened for accuracy, and errors can be fixed prior to distribution. Very small. Downside: Requires a "native format" authority factory to create the binary authority files for distribution. If you were interested in doing more work, Geotools could implement a GML 3.1.1 CRS datastore, object cacheing, and some sort of indexing scheme to accompilsh the same thing. > >> Direct GeoTools access to the EPSG database is a "great idea" that none > >> has actually implemented. > > It is already implemented and working, since February. It work with > MS-Access database, and should work with PostgreSQL too. I believe it was working long before that. I was using the PostgreSQL interface last spring. Bryce |