|
History
| Log In
|
|
|
|
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.
+ : genericity 2) Create an EPSGDB module (ie an epsg.jar file) in Geotools : + : loaded only on specific request
The main question is which format for this DB ?
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...
Linked to
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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Critical
Get rid of (or fix) generate Bounding Box button
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 
>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.