GeoServer

Hi,

>I don't really want to include four megs of epsg definitions, so I think >we should just leave off the bounding box generation.

I'd really like to have access to EPSG definitions within GeoServer

OK, I know it's rather a geotools problem and I plan to give them a hand when EPSG SQL files are fixed.

Still don't if the best solution is to provide an XML file (à la Thuban) or provide a full Java DBMS driver (maybe HSQL). Well... maybe we should have both See : http://jira.codehaus.org/secure/ViewIssue.jspa?key=GEOT-46

Please note that XML or native Java DBMS files can certainly get benefit from compression since data are quite redundant.

(Auto ?)generating a latlon bounding box for a given DataStore would be very helpful to me.

p.b.

Oh, I certainly agree that epsg definitions in GeoServer would be a great thing, and automatic lat/long box generation would be awesome. I just don't see us getting there for 1.2.0. I think geotools epsg stuff needs to shake out. I think my ideal would be a nice interface in geotools with various implementations. Then GeoServer users could just choose which jars to include in their server. If they wanted full epsg db, they could put that in as a java db, if they just knew exactly which epsg defs they needed they could put in a few flat files of those. If they had access to a database with the definitions (which would actually probably be the case with most geoserver users, as it's damn easy to get those in postgis), then they could use those. And yes, once this is done we can get reprojecting wfs and wms, which would be quite nice. So yeah, I feel we should wait and see with gt2's coordinate stuff, it'd be great if you helped them out, could use some good people to think it all through.

Hi,

>Oh, I certainly agree that epsg definitions in GeoServer would be a >great thing, and automatic lat/long box generation would be awesome.

Fine. So... "fix" rather than "get rid" ?

> I just don't see us getting there for 1.2.0.

I'm afraid Geotools won't make it for this version

> I think geotools epsg stuff needs to shake out.

Yeah

>I think my ideal would be a nice interface in geotools with various >implementations. Then GeoServer users could just choose which jars to >include in their server. If they wanted full epsg db, they could put >that in as a java db

Yes. There are basically 2 approaches :

1) Use the DBMS readers in the cts module and provide the EPSG DB in this module.

• : module size increase
• : (at least) one jar file for the JDBC driver
• : if you want native Java DBMS you need (at least) one more jar file
• : should be in sync with official EPSG DB

+ : genericity
+ : possibility to share the JDBC driver with other modules (PostGreSQL, Oracle or wathever RDBMS)

2) Create an EPSGDB module (ie an epsg.jar file) in Geotools :

+ : loaded only on specific request

• : should be in sync with official EPSG DB as well

The main question is which format for this DB ?

• SQL
• Native Java DBMS files
• XML

Whatever the choice (although XML would require some development to convert the SQL DB), we could expect good compression results. Access would of course rely on JarInputStream or similar.

>And yes, once this is done we can get reprojecting wfs and wms, which >would be quite nice. So yeah, I feel we should wait and see with gt2's >coordinate stuff, it'd be great if you helped them out

I agree. Feel free to postone resolution of this issue.

Cheers,

p.b.

This silly thing still isn't fixed to really give the latlong bounding box. I'm optimistically moving to 1.2.0. Maybe I'll figure out how to do this...

This is a top priority for 1.3

Linked to GEOS-147, as they are very similar, but have different and good comments.

Close this if/when it's done.

I added CRS support to the Generate BBox button. Unfortunately, the .properties EPSG files are worthless if you want to do ellipsoid xforms, so its not really that useful. Hopefully geotools will add an embedded DB with the projection that will add more info.

These issue has been in resolved state for at least one month (quite a bit, a lot more than one month). Batch transitioning them to closed state