search

INSPIRE-MIF / technical-guidelines

Community for the discussion of change proposals to the INSPIRE Technical Guidance documents.
https://inspire-mif.github.io/technical-guidelines
26 stars 15 forks source link

View Services TG - Deprecate WMS 1.1.1 #172

Open MarcoMinghini opened 4 months ago

MarcoMinghini commented 4 months ago

Change proposal description

This change proposal aims at deprecating the use of WMS 1.1.1 to provide INSPIRE View Services.

Addressed TG

View Services TG

Location

All occurrences of WMS 1.1.1 in the View Service TG should be removed, thus leaving WMS 1.3.0 as the only WMS version allowed. A commit showing the exact sections to be removed is available here; in addition, Annex A and Annex B should be completely removed.

Issue faced

WMS 1.1.1 is an old standard, published by the OGC in 2002 and then soon (2006) updated with WMS 1.3.0. As such, it is currently rarely used in INSPIRE, since almost all WMS software implementations provide support for version 1.3.0 by default. In addition, the View Services TG (drafted more than ten years ago), while still allowing the use of WMS 1.1.1, already recommended the use of WMS 1.3.0. Finally, in constrast to WMS 1.3.0 which uses XML Schema, WMS 1.1.1 uses Document Type Definition (DTD) and DOCTYPE, which should not be allowed for security reasons (see here). See also a discussion about WMS 1.1.1 support in the ETF (on which the INSPIRE Reference Validator is based) here.

Proposed solution

Remove all occurrences of WMS 1.1.1 in the View Service TG.

Pull request

https://github.com/INSPIRE-MIF/technical-guidelines/pull/171

Additional information

Relevant legislation

Impact on IR

No impact on IR.

Impact on INSPIRE validator

The INSPIRE Reference Validator currently uses ETF 2.0, which does not trigger the securirty exception described here (relevant to ETF 2.1). However, the Validator only supports validation against WMS 1.3.0. When a WMS 1.1.1 service is validated, the Validator automatically changes the request to use version 1.3.0 of the service: if this exists, the validation is performed without issues; if this is not available, the Validator triggers an error (see this issue in the Validator helpdesk).

Linked issue

https://github.com/INSPIRE-MIF/helpdesk-validator/issues/1018

Impact on INSPIRE XML schemas

No impact

Impact on INSPIRE code lists

No impact

Change proposer

Joint Research Centre (JRC)

References

All relevant links were provided above.

fabiovinci commented 3 months ago

Sub-group meeting on 06.05.2024: the Sub-group discussed the change proposal and decided not to accept it, for the time being. DE will add feedback on reasons to keep WMS 1.1.1 as comments on this issue, and all other sub-group members are invited to further share their views on the proposal.

JRC recommends to provide comments on the change proposal itself, independently of the current situation in terms of adoption of WMS 1.1.1 in a specific country.

hogredan commented 3 months ago

In Germany, some federal states provide their data only through WMS 1.1.1, as it has proven itself and is considered to be more reliable than WMS 1.3.0.

In the older OGC specifications, the order of the axes of the coordinate reference systems (CRS) used was fixed. For geographic coordinates this was always lon/lat (longitude, latitude), for the mapped systems east/north (right value/high value). This fixed specification considerably simplified the development of clients. The CRS was always specified in the form EPSG:{epsgcode} (e.g.: EPSG:4326).

This handling was already intensively discussed at OGC level in 2000, as there was a contradiction with the precise definition of CRS in the EPSG registry: the entry in the EPSG registry sometimes contains different specifications for the axis sequence, depending on the respective CRS!

In order to find a solution here, the newer specifications state that the respective entry in the EPSG registry is relevant for the axis sequence to be used. The clients must therefore resolve this information first. Either they have a local copy of the EPSG registry or they determine the axis sequence via an online query.

If, for example, a WMS 1.1.1 is used in an application together with a WMS 1.3.0 in EPSG:4326 (geographical coordinates), the application must convert the BBOX parameter differently in each case (WMS 1.1.1 requires the sequence lon/lat and WMS 1.3.0 requires the sequence lat/lon).