gvSIG bugs #2970
GeoServer WMS with "all supported EPSG projections"
Status: | Closed | % Done: | 0% | |
---|---|---|---|---|
Priority: | Normal | Spent time: | - | |
Assignee: | - | |||
Category: | WMS | |||
Target version: | 2.4.0-2829 (rev. org.gvsig.desktop-2.0.195) | |||
Severity: | Critical | Add-on version: | ||
gvSIG version: | 2.1.0 | Add-on build: | ||
gvSIG build: | Add-on resolve version: | |||
Operative System: | Add-on resolve build: | |||
Keywords: | Proyecto: | |||
Has patch: | Hito: | |||
Add-on name: | Unknown |
Description
There are some GeoServer WMS services that support all the EPSG projections in their capabilities. So gvSIG checks all the CRSs "supported" by the service after getting the capabilities and before the user can choose the WMS layer and all its related settings. This is very annoying, because the user has to wait some minutes until he's able to load a WMS layer... perhaps.
From #2659#note-14:
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.
Associated revisions
refs #2970, remove check for supported CRS in WMS
History
#1
Updated by Joaquín del Cerro Murciano almost 10 years ago
- Target version deleted (
2.1.0-2259-rc3)
#2
Updated by Antonio Falciano about 9 years ago
gvSIG 1.12 works fine with such kinds of WMS services, while gvSIG 2.1 and 2.2 not. There are a lot of Can't get proj4 string or I cannot get the transformation between... errors that freezes the application and ...force the users to use other clients.
#3
Updated by Antonio Falciano over 8 years ago
This issue is also present in gvSIG 2.3... IMHO it's very critical because it seems like an infinite loop on CRSs combination, as we can in the console or in a piece of log file.
#4
Updated by Antonio Falciano about 7 years ago
- Target version set to 2.4.0-2850-final (rev. org.gvsig.desktop-2.0.220)
- File 2970.patch
added
Has patch: Yes
I attach a patch in order to skip the unnecessary CRS bottleneck that blocks GeoServer WMS with "all supported EPSG projections". Result: there will be CRS related warnings/errors only when the user selected CRS (and/or its transformation to WGS84) is not supported.
#5
Updated by Antonio Falciano about 7 years ago
- Status changed from New to Fixed
#6
Updated by Joaquín del Cerro Murciano about 7 years ago
- Target version changed from 2.4.0-2850-final (rev. org.gvsig.desktop-2.0.220) to 2.4.0-2829 (rev. org.gvsig.desktop-2.0.195)
Parche metido.
#7
Updated by Álvaro Anguix about 7 years ago
- Status changed from Fixed to Closed