Ideally I think we wouldn't have to define where to stop dividing. We could have one just include several authorities on the classpath somehow.
Wasn't Martin going to work on some sort of fallback authority factory? I think ideally we could define a 'fallback order' or some such, and let one include multiple hsql databases.
Does anyone know the viability of having multiple hsql db's on the classpath at once? Like we'd always ship with EPSG database plus the standard non-EPSG database, as two separate jars. And then in GeoServer /uDig have another jar, perhaps initially empty, that one can add custom projections to (the web admin tool would work against this). So for an upgrade one would just copy the jar over.
I think that'd be the ideal in terms of workflow, anyone got a nice implementation for it? How to store multiple hsql databases?
But yes, in general I'm +1 on switching to hsql.
Chris
Paul Ramsey wrote:
For adding "custom" projections, could we avoid trying to add them to the same HSQL database as used by the EPSG data? This sounds like an odd request, but it flows from my need to support "standard non-EPSG" systems.
So the projections I need to support are not really "custom", in that the user doesn't add them. And they aren't really standard, in that the EPSG won't have them either.
I am thinking in terms of workflow:
- EPSG updates their database, how do I add that new stuff to my (udig|geoserver)?
- I add 12 new custom projections to my (udig|geoserver) then I upgrade my software. Do I have to add my custom stuff again? How do I avoid that?
- A new non-EPSG standard projection is found (maybe ESRI adds a new one), where do we add that in geotools?
So, that leaves me wanting almost three different authorities...
- A real EPSG authority. (HSQL)
- A custom authority. (HSQL, but it ships with nothing in it)
- A standard-non-EPSG authority (WKT, HSQL, something?)
Or perhaps four or five authorities...
- A standard ESRI-but-not-EPSG authority.
- A catchall standard-but-neither-ESRI-nor-EPSG authority.
Where to stop dividing?
P
Justin Deoliveira wrote:
I dont think there is anything stopping us from changing over, and from
what I understand it is the better way to go. Does anyone else see any
issues?
Were there any other changes to the code base on wcs that required the
the change to hsql?
-Justin
Alexander Petkov wrote:
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
-------------------------------------------------------------------------
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
!DSPAM:1003,44eb64b5156242223018498!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org