-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
View Services TG - Deprecate WMS 1.1.1 #172
Comments
Sub-group meeting on 06.05.2024: 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). |
Sub-group meeting on 11.11.2024: To better understand the impact of this change proposal, the Sub-group proposed to clarify the meaning of deprecation. Deprecation (of WMS 1.1.1) means that the standard will no longer be supported by the INSPIRE technical infrastructure. Specifically, it means that the mention to the standard will be formally removed from the View Service TG, and as a consequence support for it may not be guaranteed in the Reference Validator and the Geoportal (in this specific case, the Validator already does not support it). Data providers can still use WMS 1.1.1, but they have to make sure that it complies with the INSPIRE legal framework. With this additional clarification, the Sub-group asks the INSPIRE community to provide feedback on the change proposal. |
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
#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
INSPIRE-MIF/helpdesk-validator#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.
The text was updated successfully, but these errors were encountered: