Application: gvSIG desktop

GeoServer version 2.5.1

Tiene pinta de ser el mismo que el 2584, ya arreglado en los últimos builds.

Hi Victoria,
this issue usually happens with Geoserver WMS configured with "all supported EPSG projections" (see the service capabilities), a good crash test for gvSIG jCRS extension. In fact, there are a lot of "I cannot get the transformation between EPSG:4326 and EPSG:..." messages in the gvSIG.log, so it's very useful in order to debug jCRS. It occurs also with the latest build (BN 2233) and the updated EPSG Registry (#2306). So it's not due to the lack of CRSs in gvSIG, but to the jCRS extension which is not able to manage all the (relatively) new coordinate operation methods aliases (see also #1371, #2596, #2624 and #2664) and consequently the transformation parameters between several CRSs.
ASAP I'll try to create a new ticket with a list of all these methods in order to verify which of them are actually supported or not by the jCRS extension.

Without reinventing the wheel, updating the GeoTools libraries used in the jCRS extension could be the solution. They should be kept separated from the org.gvsig implementations in order to be updated regularly, just like the EPSG Registry.

I made a mistake with the build number where the bug seems to be fixed!!!! Sorry, It's the last one: 2.1_2233.

Victoria Agazzi wrote:

Hi Antonio, thanks for your comments. I really do not investigate about, only opened the bug in order to have it to test later by the Japanese enterprise that had the problem.

On the last build (2233) it seems to be fixed.
Bye!

IMHO this bug is not fixed yet, because I can reproduce it with BN2234 too. Maybe the specific case you reported is solved, because the server configuration was adjusted declaring only few supported CRSs in the meanwhile. But it's impossible to verify it without its URL. :) However, if you deploy a GeoServer WMS configured with "all supported EPSG projections", you'll obtain the same issue for sure.

Severity: Blocker

For instance, here's a public WMS using GeoServer that returns this kind of issue.
URL: http://sitap.beniculturali.it:8080/geoserver/apar.public/wms
GetCapabilities: http://sitap.beniculturali.it:8080/geoserver/apar.public/wms?service=wms&request=getcapabilities

From its capabilities:

<!--All supported EPSG projections:-->
<CRS>AUTO:42001</CRS>
<CRS>AUTO:42002</CRS>
<CRS>AUTO:42003</CRS>
<CRS>AUTO:42004</CRS>
<CRS>EPSG:WGS84(DD)</CRS>
<CRS>EPSG:2000</CRS>
<CRS>EPSG:2001</CRS>
<CRS>EPSG:2002</CRS>
...
<CRS>EPSG:42102</CRS>
<CRS>EPSG:42306</CRS>
<CRS>EPSG:42101</CRS>
<CRS>EPSG:42305</CRS>
<CRS>EPSG:42304</CRS>
<CRS>EPSG:42303</CRS>
<CRS>CRS:84</CRS>

What's happen? When we connect to this service, gvSIG downloads the capabilities and then verifies if it supports all these CRSs! But we know that not all CRS (and their relative operation methods) are actually supported in gvSIG (in Proj.4 and GDAL too!). IMHO this strategy is highly inefficient (especially when we have a very long list of CRSs supported by the service), because this check is made before that the user choose the CRS. Instead, I'd let the user to choose the CRS before and gvSIG to verify if this CRS is supported after. If the CRS is convertible in the Proj4 format and we can retrieve its transformation parameters successfully, then we can load the WMS layer, else a warning should appear saying that the selected CRS is not supported inviting the user to retry again choosing another one or close the wizard.