[Geoserver-users] R: R: R: R: R: Problems with EPSG lookup

-----Messaggio originale-----
Da: Andrea Aime [mailto:aaime@anonymised.com]

Well, this is a hole in the tiff+tfw approach we're trying to
fix, that is, tfw does not provide CRS information.
A new wiki page is needed to guide people using image + tfw files.
Do you have time to write one? :slight_smile:

I would be glad to do that. In the next days I'll menage to accomplish the task.
May I edit directly the wiki pages or have I to send a document to someone?

There are a few cases here that make us still want to have that page:
* data without CRS -> you have to provide us one (the gt2-image is
   buggy in this respect)
* data with a CRS that cannot be mapped to any known EPSG code.
   Here you have to choose one since the standard tells us
that we have
   to advertise an EPSG code, possibly one with little
trasformation cost
   compared to the native one.
* data with a CRS that can be mapped to EPSG codes, but only after a
   5-10 search in the EPSG database. This happens when the
WKT does not
   provide an EPSG code, but just the projection parameters.
   I guess you would not want to wait for the search to be fully
   performed if you already know the code, hence the lookup
SRS and the
   possibility for you to input by hand.

Ah, I guess I need to add a user page explaining the ins and
outs of this way of doing things. I've tried to make
Geoserver work in most situations, the result is not really
as straightforward as I'd like.
Any suggestions on how to improve it?

Well, I agree it was a good idea to have the software doing its job and reading the CRS definition from the data. But maybe the actual situation is a bit too much rigid, and not much intuitive, at least for the normal/new user (like me).

I mean: now Geoserver reads the CRS from the data, and take that as good AND the user cannot change it. The user can supply (via web admin interface) another CRS and Geoserver traslate on the fly from the "native" guessed CRS to the user chosen CRS. Right? In this way, if there is not a native CRS, the user can supply one (not sure what the gt2-image bugs can cause in this case).

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.

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 WKT

Am I confused or there something wrong?

If this is a defect, I can fill a Jira issue. With this I have 3 issues to file about WCS, but Jira seems broken (at least on geoserver project) , when I hit "Create a new issue" I get this:

500 Servlet Exception

java.lang.NullPointerException
  at com.atlassian.jira.plugin.webresource.JiraWebResourceIntegration.getBaseUrl(JiraWebResourceIntegration.java:42)
  at com.atlassian.plugin.webresource.WebResourceManagerImpl.getStaticResourcePrefix(WebResourceManagerImpl.java:182)
  at _jsp._500page__jsp._jspService(includes/decorators/stylesheettag.jsp:12)
  at com.caucho.jsp.JavaPage.service(JavaPage.java:60)
  at com.caucho.jsp.Page.pageservice(Page.java:570)
  at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:159)
  at com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:115)
      [...]

Cheers,

Fabio

Fabio Da Soghe ha scritto:

-----Messaggio originale----- Da: Andrea Aime
[mailto:aaime@anonymised.com]

Well, this is a hole in the tiff+tfw approach we're trying to fix,
that is, tfw does not provide CRS information. A new wiki page is
needed to guide people using image + tfw files. Do you have time to
write one? :slight_smile:

I would be glad to do that. In the next days I'll menage to
accomplish the task.

Cool :slight_smile:

> May I edit directly the wiki pages or have I to

send a document to someone?

You can create a new wiki page under http://docs.codehaus.org/display/GEOSDOC/Data+Loading.

...

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+definition+in+Geoserver+1.5.0+(onwards))
creating a new EPSG code (there is a free range for custom extensions).

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 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 WKT

There is indeed something wrong... when you press submit the
Coverage editor page should close... Anything in the geoserver logs?

Cheers
Andrea