gvSIG bugs #3266: Incorrect axis order on WMS 1.3.0 for some CRSs - Application: gvSIG desktop - gvSIG

gvSIG bugs #3266

Incorrect axis order on WMS 1.3.0 for some CRSs

Added by Cesar Martinez Izquierdo about 9 years ago. Updated about 9 years ago.

Status:

Closed

% Done:

Priority:

Normal

Spent time:

Assignee:

Cesar Martinez Izquierdo

Category:

WMS

Target version:

2.2.0-2307 (rev. org.gvsig.desktop-2.0.94)

Severity:

Major

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

When loading WMS 1.3.0 layers using projected CRSs that use reverse axis order (norting-easting instead of easting-norting) the coordinates are managed incorrectly.

For instance, if the layer Corine Land Cover 250m 1990 [CORINE_CLC90_250m] is loaded using EPSG:3035 from the WMS "http://pegasosdi.uab.es/ogc/wms", the correct bounding box in CRS:3035 is EPSG:3035 (xmin=1500000.0, ymin=900000.0, xmax=7400000.0, ymax=5500000.0) but the parsed one is (xmin=900000.0, ymin=1500000.0, xmax=5500000.0, ymax=7400000.0)

As a consequence, the layers on these CRS are drawn in a wrong position (sometimes not drawn at all). The list of CRS (currently) using reverse axis order is available on this CSV: https://github.com/mapserver/mapserver/blob/branch-7-0/mapaxisorder.csv
From these CRS, all the projected (non geographic) CRSs incorrectly managed.

This is a regression compared with gvSIG 1.12, as this bug was fixed for 1.12.

Related issues

Associated revisions

Revision 3325
Added by Cesar Martinez Izquierdo about 9 years ago

WMS: Correctly manage projected CRSs using non-xy axis order (e.g. EPSG:3035). Add an UI checkbox to make this behaviour customizable by user. Fixes #3266.