Application: gvSIG desktop

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.