Re: [Geotools-devel] Re: [udig-devel] Re: CRS - "Bursa wolf parameters r

[Bryce L Nordgren <bnordgren@xxxxxxxxx>]

> 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