-----Messaggio originale-----
Da: Andrea Aime [mailto:aaime@anonymised.com]
...
> What about having Geoserver reading the CRS (or at least trying to)
> from the data, then presenting this to the user (in the web admin
> interface) as a proposed (recommended, change-this-at-your-own-risk,
> etc.) SRID, then having the user accept the default value or
> specifing a different one. After having set the SRID, Geoserver
> should assume data are in the specified SRID (guessed or
inputed from
> the user, it's the same). This seems much more intuitive for me.This does not work for data that has a CRS which cannot be mapped
to an EPSG number. There are quite a bit around. That's why we decided
to trust eventual built-in projection information more than the user,
most of the time data producers know better than users about
projections
(your issue with gt2-image is a bug).
We could solve this by creating a little wizard that allows
users to insert the native WKT among the user provided CRS (see
http://docs.codehaus.org/display/GEOSDOC/Custom+projection+def
inition+in+Geoserver+1.5.0+%28onwards%29)
creating a new EPSG code (there is a free range for custom
extensions).
Something like that. You can read my sentence with "CRS definition" instead of "SRID".
The main issue is to have Geoserver read the CRS information (SRID or not) from the data, then presenting them to the user, but leaving to the user the (optional) last word. This last word could be to choose a standard SRID or to input a custom WKT (with a wizard, like you're already developing).
The not intuitive thing is to have a page where I can put a SRID that Geoserver apparently takes into consideration but that it ignores, in some cases.
About Geoserver trying to read the CRS from data straight on,
would you wait more than 5 seconds on a top notch PC (Intel
Core Duo 2) each time you configure a new Coverage? That's about the
time it takes to scan the EPSG database doing parameter comparisons,
when the original data does not have an EPSG code inside...
Take a two years old PC and these times doubles easily. That would
be unacceptable to me. In my original implementation I did not have
the "lookup SRS" button, geoserver tried to lookup the SRS before
showing the configuration page to the user,
but could not stand the wait each time I had to configure a new
coverage.
I agree. For this reason I would let to the user the choice to have Geoserver take a guess about the CRS.
Maybe I said that in an ambiguous manner: with "having Geoserver read the CRS from data" I meant only reading the SRID from metadata (if present), not doing the full WKT comparison.
> I did some other tests, and there seems to be a problem with the
> Coverage Editor page (besides what I've already written about, the
> wrong 4326 lookup with no prj file):
>
> - tif+tfw+prj files (EPSG in the prj: 3003) - create CoverageStore,
> all ok - create Coverage, all ok: it reads the 3003 SRID - hit
> submit, apply, save, all ok - edit the coverage configuration again,
> change the SRID in EPSG:26591, press submit: it doesn't update the
> WKT text (leave the 3003 one) - press apply, save: on disk the
> info.xml reports the new SRID 26591, but the web page still
shows the
> 3003 WKT - press load on the web admin - enter the Coverage Editor
> again: now there is the correct SRID (26591) and its WKTThere is indeed something wrong... when you press submit the
Coverage editor page should close... Anything in the geoserver logs?
My fault, I wasn't enough detailed. When I press submit (after changing manually the SRID) the Coverage Editor page closes correctly; then I return to it and the WKT is not changed. It seems to me there is a refresh problem: the configuration on xml file changes but the configuration active in memory keeps the same. Infact, if I hit "load", it gets refreshed (and I see the consistent WKT). I hope this is clearer, sorry for that.
Cheers,
Fabio