gvSIG bugs #1141
Problem loading WMS 1.3.0 servers using EPSG:4326 and other CRSs
| Status: | Fixed | % Done: | 100% | |
|---|---|---|---|---|
| Priority: | Normal | |||
| Assignee: |  Francisco José Peñarrubia | |||
| Category: | - | |||
| Target version: | - | |||
| Severity: | Add-on name: | Unknown | ||
| gvSIG version: | 1.12.0 | Add-on version: | ||
| gvSIG build: | Add-on build: | |||
| Operative System: | Add-on resolve version: | |||
| Keywords: | Add-on resolve build: | |||
| Has patch: | Yes |
Description
When loading WMS 1.3.0 layers using EPSG:4326 projection, maps are distorted, or not displayed and even sometimes CRS errors arise (depending on the area we are zooming in). I attach snapshots showing the behaviour.
You can test the problem by loading any of the following services:
http://wsinspire.geoportail.lu/services/inspire/OI/Mapserver/WMSServer
http://ogc.larioja.org/wms/request.php
http://pegasosdi.uab.es/ogc/wms
Explanation of the problem:
WMS 1.3.0 defined that bounding box has to be provided in the real order in which the CRS is defined by EPSG database. That means that for EPSG:4326 the coordinates order must be (latitude, longitude) instead of (longitude, latitude). By contrast, WMS 1.1.1 didn't specify this behaviour, so it was widely implemented using the typical order used on GIS applications (longitude, latitude). The same applies to some other projections such as 3035.
This change on WMS 1.3.0 has not been implemented in gvSIG till now, which is sending wrong requests and producing distorted maps and errors. I attach a patch that implements the right behaviour on gvSIG 1.3.0. The changes are really small, but they involve several projects: libProjection, libJCRS, extWMS and libRemoteServices.
Note that this patch corrects the behaviour of WMS 1.3.0 when connecting to most WMS servers (tested with Geoserver, Mapserver 6.0, ArcGIS server), but it may cause wrong behaviour with servers that wrongly implement the standard.
Specifically, connecting to Mapserver 5.6 using WMS 1.3.0 and EPSG:3035 CRS exhibits this problem. This is a bug on Mapserver 5.6 with some projections, and it has been corrected for version 6.0. Note that EPSG:4326 works correctly on Mapserver 5.6. See bug http://trac.osgeo.org/mapserver/ticket/3582 for details.
wms_patch.diff 
(13.1 KB)
error.png - WMS 1.3.0 distortion (105 KB)
behaviour-after-applying-patch.png - Behaviour after applying the patch (198 KB)
History
#1
Updated by Cesar Martinez Izquierdo over 11 years ago
- File error.png added
- File behaviour-after-applying-patch.png added
#2
Updated by Francisco José Peñarrubia over 11 years ago
Hola Cesar.
First of all, gracias por el patch.
Some comments:
- There are some getWKT() methods returning null. (The method has been added automatically). This can be a problem?
- We were aware of this problem, and because some WMS servers was doing bad, we used as a "workaround" the selection of CRS84. I mean, in your first wms, the capabilities says:
<CRS>CRS:84</CRS>
<CRS>EPSG:4326</CRS>
So, if you choose CRS:84, you will get the right images with gvSIG.
Do you think that this patch is still needed? (I suppose yes, but as you know, we are in the final dates for the stable release... so I don't know what will be the decission of the group).
Saludos, y a ver si nos vemos un día de estos!! :-)
Fran.
#3
Updated by Francisco José Peñarrubia over 11 years ago
I revised the other 2 wms and it seems they don't offer CRS:84, so, it makes more sense this patch.
#4
Updated by Cesar Martinez Izquierdo over 11 years ago
Hola Fran,
Regarding getWT() returning null: the method has been added as a way to access the projection definition as text, because the IProjection interface is quite opaque. The javadoc of the method warns that it can return null when the WKT definition is not available. The method has been implemented for the cases it could be done with little effort, but it has been left unimplemented for some classes (that I think are not used or have little use).
The method was already implemented for extJCRS (the most used library nowadays in gvSIG). For libProjection (the old gvSIG projection library, only active when extJCRS is not installed), the method has been implemented for geotools-based projections. I would say that the rest of classes (not geotools-based projection on libProjection) are old code not used anymore, at least they are not instantiated in the tests I performed (or maybe they are instantiated in some corner case I could not discover).
Regarding the patch, it will not solve the problem for EPSG:4326 when using libProjection (instead of extJCRS), because the code in the patch gets the axis order from the WKT, which is wrongly defined on libProjection. But this is a problem of libProjection, which has been not updated for years so it uses very old EPSG definitions (from Geotools 2.1). I don't see a trivial solution for that.
Regarding the inclusion of the patch in trunk... you can delay it after releasing 1.12 if you think it its troublesome to include it (although I would prefer to include it, as I think it is really worthy to solve this bug for 1.12).
Regarding the use of CRS:84: users can use it as a workaround (when available), but I think it is much better to have WMS 1.3.0 properly implemented on gvSIG.
Un abrazo Fran, a ver si se hace algún codesprint y puedo asistir.
César
#5
Updated by Francisco José Peñarrubia over 11 years ago
- Assignee set to Francisco José Peñarrubia
#6
Updated by Francisco José Peñarrubia over 11 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset r38898.
#7
Updated by Francisco Puga over 11 years ago
Kudos to both :)
#8
Updated by Jorge Sanz over 11 years ago
Francisco José Peñarrubia wrote:
Applied in changeset r38898.
Hi all,
As far as I know César has not signed the gvSIG CLA1. I am not 100% sure but I've found an email sent to you 30/05/11 without response so if you sent it to us I have to apologize. I hate to do this AFTERWARDS but we need it. Please César, can you send it to me? You can find it (with PDF versions at the end of the page) at2.
I hope you the maintainers will help me to maintain this procedure or it will be useless.
Best regards.
[1] http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/como-contribuir-en-gvsig/contribuciones-y-parches-al-codigo-de-gvsig/cla-status
[2] http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/como-contribuir-en-gvsig/contribuciones-y-parches-al-codigo-de-gvsig/templates/contributor-license-agreement
#9
Updated by Jorge Sanz over 11 years ago
Jorge Sanz wrote:
Francisco José Peñarrubia wrote:
Applied in changeset r38898.
Hi all,
As far as I know César has not signed the gvSIG CLA1. I am not 100% sure but I've found an email sent to you 30/05/11 without response so if you sent it to us I have to apologize. I hate to do this AFTERWARDS but we need it. Please César, can you send it to me? You can find it (with PDF versions at the end of the page) at2.
Hi
I've just filed César CLA and I'll add him to the CLA status page.
Thank you!!
Jorge
#10
Updated by Álvaro Anguix about 10 years ago
- Project changed from Application: gvSIG desktop to | gvSIG desktop 1