Open MarcoMinghini opened 4 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.
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).
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.