[Geoserver-devel] [ HSQL vs WKT for epsg definitions]

jive · August 23, 2006, 8:05am

I have one warning and then I am all for it.

The HSQL database is unpacked somewhere magic right now, for GeoServer I think we need to unpack this into a temporary file (something that even a J2EE application can expect access to).

We may also wish to set up a fallback WKT based authority based on a crs.properties file in the data directory, so people have a smooth way to support there own stuff. Like paul I think this would provide a seperatation between the formal EPSG database and the custom values provided by the user.

Jody

-------- Original Message --------
Subject: [Geoserver-devel] HSQL vs WKT for epsg definitions
Date: Tue, 22 Aug 2006 12:39:56 -0600
From: Alexander Petkov <greenkov@anonymised.com>
To: Geoserver-devel <geoserver-devel@lists.sourceforge.net>

What are the chances of abandoning the use of the wkt gt jar in favor
of the hsql one (the epsg-hsql jar is currently used in the WCS
branch)?

If we resort to using the HSQL database for storing projection data,
we could add a web UI where one can define custom projections
(currently starting to work on that, thanks for adding support for
community modules!!).

The WKT jar on the other hand does not allow that easily--not w/o
unpacking the archive, modifying the epsg.properties file, re-creating
the archive and restarting the geoserver instance.

Simone also has expressed some frustration with the use of WKT, as it
is intrinsically incorrect and does not define an authority for many
objects other than crs (which he needs for geotiffs).

So what does everyone think about using the HSQL database exclusively?

Thanks,
Alex

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Alexander_Petkov · August 23, 2006, 2:26pm

On 8/23/06, Jody Garnett <jgarnett@anonymised.com> wrote:

I have one warning and then I am all for it.

The HSQL database is unpacked somewhere magic right now, for GeoServer I
think we need to unpack this into a temporary file (something that even
a J2EE application can expect access to).

I forget the scenario on Windows--I think It was in user's temp
directory, somewhere within "My Documents" under jetty. On Linux is
unpacked in /tmp under jetty, or in $CATALINA_HOME/temp under tomcat.

We may also wish to set up a fallback WKT based authority based on a
crs.properties file in the data directory, so people have a smooth way
to support there own stuff. Like paul I think this would provide a
seperatation between the formal EPSG database and the custom values
provided by the user.

I don't know how useful this fact would be--codes above 32706 (IIRC)
are officially designated for people to define their own stuff in the
EPSG database.

Alex

pramsey · August 23, 2006, 5:02pm

Alexander Petkov wrote:

We may also wish to set up a fallback WKT based authority based on a
crs.properties file in the data directory, so people have a smooth way
to support there own stuff. Like paul I think this would provide a
seperatation between the formal EPSG database and the custom values
provided by the user.

I don't know how useful this fact would be--codes above 32706 (IIRC)
are officially designated for people to define their own stuff in the
EPSG database.

If people's custom stuff is mixed into the same database as the EPSG records, then upgrading the (software|epsgdatabase) becomes hard. If it is segregated, then it becomes possible to do updates without throwing away the custom data every time.