[mapserver-dev] INSPIRE compliancy - A request for comments on a
possible RFC
relet
thomas.hirsch at statkart.no
Fri Oct 22 04:36:59 EDT 2010
Dear all,
As we have discussed at FOSS4G between us (Statens kartverk, Norway) and
parts of the development team, we would like to highlight some issues with
regards to compliancy with the European INSPIRE directive and a possible
approach to tackle these. We formulated these as a draft RFC, and would be
looking forward to any comments.
A PDF is provided for better readability.
http://osgeo-org.1803224.n2.nabble.com/file/n5661761/MS_RFC_INSPIRE.pdf
MS_RFC_INSPIRE.pdf
===========================================================
MS RFC: INSPIRE COMPLIANCY
===========================================================
Date: 2010/10/22
Authors: Thomas Ellett, Pål Kristensen, Thomas Hirsch
Contact: Pal.Kristensen at statkart.no
===========================================================
Purpose
To enable the production and operation of INSPIRE compliant WMS services. We
propose to achieve this through the creation of a new ‘container’ layer
mechanism that acts as an advanced group layer and through two smaller
changes to the GetFeatureInfo mechanism, the rendering of classes within
layers and multilingual GetCapabilities and GetMap error responses.
The INSPIRE Directive entered into force on the 15th May 2007, and contained
a set of regulations designed to ensure that the ‘Spatial data
infrastructures of the member states are compatible and useable in a
community and transboundary context’. The directive states that common
implementing rules be adopted (initially by 9th map 2011), among these is
the Network Services Implementing Rules which contains the following
document pertaining to view services.
http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_View_Services_v2.12.pdf
At the moment Mapserver would not allow member states to adhere to the rules
set out in the document above. This RFC sets out to highlight the issues and
possible solutions to this problem.
===========================================================
Issues
===========================================================
Issue 1 Layer structure
This first issue is mainly caused by the single geometry limitation of the
mapserver layers and the strict layer structure dictated by the Data
Specifications. For instance a mapserver service created for the Hydrography
theme in Annex 1 would traditionally look like this:
Hydrography*
Service Name
Hydrography_physical_waters*
Group Name
HY.PhysicalWaters.Waterbodies*
Group Name
Watercourse*
Group Name
Watercourse_Linestring+
Physical Layer
Watercourse_Polygon+
Physical Layer
StandingWater*
Group name
StandingWater_Point+
Physical Layer
StandingWater_Polygon+
Physical Layer
The layers marked * are those defined in the INSPIRE Data Specification and
in the WMS domain related to as ‘Named Layers’, thus allowed in the
Capabilities document and called through the GetMap, GetFeatureInfo and SLD
mechanisms. The layers marked + should not be seen or called at any point.
Currently this service would not be INSPIRE compliant. The Watercourse and
StandingWater elements should be at the lowest level in the service, but
because of the one geometry per layer restriction of Mapserver, this is not
possible.
Traditional use of the group layer function advertises the _Linestring,
_point and _polygon layers in the capabilities document which is illegal in
the INSPIRE context. In addition, GetFeatureInfo responses show the bottom
layer names (_Linestring, _Polygon, _Point) as the feature type name and
not the Group layer names.
An option that fixes the capabilities document issue is to use the
‘invisible’ layers patch. This patch adds the attribute ‘REQUIRES’, meaning
that you can tie one layer to another while at the same time hiding the
layer using the “REQUIRES” attribute using “ows_hidden_layer” “true”. This
leads to a technically correct GetCapabilities response as you can hide all
single geometry base layers, but means that only one geometry type can be
queried in a GetMap or GetFeatureInfo request.
Issue 2 Scale/Generalisation
Initially support for multi-geometry layers was considered, with some kind
of keyword at the class level to make the class geometry dependent. However,
whilst that would solve the Layer Structure issue above, it would not solve
the issue of generalization.
The INSPIRE data specifications are scale independent,meaning that the
services will have to (should) cover a large scale range. In all probability
this would necessitate connecting to 2 or more databases (1 for large scale
data and at least 1 more for medium or medium/small scale data). This would
lead to identical layers that connect to different data sources. The
following mapfile structure assumes that mapserver supports multi-geometry
layers.
HY.PhysicalWaters.Waterbodies*
Group Name
Watercourse*
Group Name
Watercourse_LargeScale+
Regular Mapserver Layer
Watercourse_MediumScale+
Regular Mapserver Layer
Watercourse_SmallScale+
Regular Mapserver Layer
StandingWater*
Group name
StandingWater_LargeScale+
Regular Mapserver Layer
StandingWater_MediumScale+
Regular Mapserver Layer
StandingWater_SmallScale+
Regular Mapserver Layer
We can see from this structure that even if a multi-geometry solution was
found, the generalization problem would lead to the same problems as in
issue 1, with different scale layers instead of different geometry layers.
Therefore the proposal in this document is for the creation of a new
mechanism called a Container layer which would in essence be an extended
group layer with specifications regarding the handling of the different
requests (GetMap, GetLegend, GetFeatureInfo, SLD) through aggregation of
data from sublayers.
===========================================================
PROPOSED SOLUTION
===========================================================
We perceive a Container layer to enable infinite nested layers within a
service without compromising the data returned through any of the OWS WMS
requests. A container layer would be able to contain other container layers
and be contained itself. For compatibility with existing mapfiles, it should
not be a replacement for the group layer mechanism.
To allow correct returns of WMS requests, the container layer must have
access to routines and mechanisms that enable it to distribute requests to,
and aggregate responses from, its sublayers. An example of how the solution
might look for the INSPIRE Hydrography example is below, with an example of
how the actual container layer structure could be:
Hydrography*
Service Name
Hydrography_physical_waters*
Container Layer
HY.PhysicalWaters.Waterbodies*
Container Layer
Watercourse*
Container Layer
Watercourse_LINESTRING+
Regular Mapserver Layer
Watercourse_POLYGON+
Regular Mapserver Layer
Watercourse_POINT+
Regular Mapserver Layer
StandingWater*
Container Layer
StandingWater_LINESTRING+
Regular Mapserver Layer
StandingWater_POLYGON+
Regular Mapserver Layer
StandingWater_POINT+
Regular Mapserver Layer
HY.PhysicalWaters.LandWaterBoundary*
Container Layer
LandWaterBoundary*
Container Layer
LandWaterBoundary _LINESTRING+
Regular Mapserver Layer
LandWaterBoundary _POLYGON+
Regular Mapserver Layer
LandWaterBoundary _POINT+
Regular Mapserver Layer
Layers marked + would be hidden from the capabilities document and this
would be controlled by a keyword at the relevant layer level.
Ows_hidden_layer could maybe be used for this purpose.
The nesting structure found above is important because of the aggregating of
results within the GetFeatureInfo requests. However, whilst the position of
the container layers is important, the position of the regular mapserver
layers (for instance the LandWaterBoundary_LINESTRING, _POLYGON and _POINT
layers) is not - due to the new keyword, INCLUDELAYER, created for the
containers. The order of regular layers in this new section must define the
return values, not their position in the mapfile.
Container Layers
LAYER
NAME “HY.PhysicalWaters”
TYPE container
STATUS ON
INCLUDELAYER
#Comment: Layers below should be in their draw order (top layer
first) regardless of position within the mapfile.
”Layer_Name” “HY.PhysicalWaters.Waterbodies”
”Layer_Name” “HY.PhysicalWaters.LandWaterBoundary”
END
METADATA
“Wms_Title”
“Wms_Abstract”
END
END
LAYER
NAME ’HY.PhysicalWaters.Waterbodies’
TYPE container
STATUS ON
TEMPLATE “HTML_Template.html “
MAXSCALE 400000
METADATA
“wms_title” “Hydrography Physical Waters : Waterbodies”
“wms_abstract” “Any known inland waterway body.”
“wms_keywordlist” “Watercourse, River, Stream, Lake, Reservoir”
“wms_extent” “4.768847, 58.876896, 12.540137, 60.836029”
”wms_srs” ”EPSG:4258 EPSG:4326 EPSG:32633”
“wms_include_items” “all”
“wms_authorityurl_name” “Statens_kartverk”
“wms_authorityurl_href” “http://statkart.no”
“wms_identifier_authority” “Statens_kartverk”
“wms_identifier_value” “hy.pw_waterbody”
“ows_metadataurl_type” “iso19115”
“wms_metadataurl_format” “text/html”
“ows_metadataurl_href” “LINK TO CSW”
END
INCLUDELAYER
#Comment: Layers below should be in their draw order (top layer
first) regardless of position within the mapfile.
”Layer_Name” “Watercourse”
”Layer_Name” “StandingWater”
END
END
LAYER
NAME ’Watercourse’
TYPE container
STATUS ON
TEMPLATE “HTML_Template.html “
MAXSCALE 400000
CLASSGROUP “INSPIRE:DEFAULT”
INCLUDELAYER
#Comment: Layers below are regular mapserver layers and contain the
actual data connections.
”Layer_Name” “Watercourse_POLYGON
”Layer_Name” “Watercourse_LINESTRING”
”Layer_Name” “Watercourse_POINT”
END
CLASS
TYPE polygon
GROUP “INSPIRE:DEFAULT”
STYLE
COLOR 0 50 0
OUTLINEWIDTH 2.2
OUTLINECOLOUR 100 100 100
END
STYLE
OUTLINEWIDTH 1
OUTLINECOLOUR 50 50 50
END
END
CLASS
TYPE Line
GROUP “INSPIRE:DEFAULT
SCALE <100000
STYLE
OUTLINEWIDTH 2.2
OUTLINECOLOUR 50 100 100
END
END
CLASS
TYPE Line
GROUP “INSPIRE:DEFAULT
SCALE >=100000
STYLE
OUTLINEWIDTH 2.2
OUTLINECOLOUR 50 50 50
END
END
END
===========================================================
OWS WMS Requests
===========================================================
How the new container layers responds to standard WMS requests is open to
debate but what we consider the most important functions are detailed below.
GetCapabilities
* The BBOX response should either return a manual value at the container
level or a calculated value based on collation of lowest level layers.
* All layers to be visible unless “ows_hidden_layer” “true” is stated at the
regular mapserver Layer Metadata level (this function to follow the
developments in
http://trac.osgeo.org/mapserver/wiki/HidingLayersInOGCWebServices
* All container layers to be in the same order as in the mapfile, and all
regular mapserver layers to be shown in the order they’re in in their parent
container layer.
* The same nested structure should be used for container layers and their
sublayers as for the current group layers mechanism and their sublayers.
GetMap
* When a request arrives to the container layer, it should distribute the
same request to all layers in the ‘INCLUDELAYER’ section.
* All layers found in the INCLUDELAYER section at the container layer level
to be rendered in the order they’re specified . This is true for container
and regular mapserver layers alike.
GetFeatureInfo
* When a request is made, the container layer should distribute the request
to all layers within the ‘INCLUDELAYER’ section.
* Response should be a concatenation of all results from all visible
sublayers of the nested tree.
* Response should be correctly formatted for plain text and gml output
* Name of featuretype to be taken from the lowest level container layer
GetLegendGraphic
* Aggregate GetLegendGraphic responses for all sublayers to a single
graphic. Each individual legend item to have the name of the lowest level
requestable parent container layer. (e.g in the example above, the
WaterCourse_Point graphic would have the name Watercourse)
* Have 3 options for outputting of legend, in order of priority:
o If an SLD link is provided in the request use this
o If symbology through Class Styles is provided within the container
layer and no SLD link provided use this.
o If no SLD link or container level symbology is provided use the
symbology defined at the regular mapserver layer level and aggregate into
single output. If scale is supplied at the class level print the scale range
above the symbol.
Requests containing SLD links or bodies
* When an SLD request is made the sublayers are rendered through the
creation of rules with point, line and polygon symbolisers.
* SLD would reference the lowest level containers and render using the point
above.
* Need to fix ticket #462 so that describefeaturetype works correctly so
that user styles can be attempted to be created
These functions may or may not have to be tweaked in their format to work
with the existing architecture and/or existing functions, but they are the
minimum requirement for the container layer concept to work.
Files affected
* To be discussed.
Other Developments
Along with this RFC, two tickets will be created to ensure that mapserver
will be INSPIRE compliant.
1. The creation of a mechanism to solve the issue of multilingualism,
probably using the ‘_iso_639-2/B_alpha_3’ syntax (e.g ‘_en’) to add new
metadata attributes where applicable. These would then be used depending on
the value of the ‘LANGUAGE=’ parameter in the getcapabilities request.
(Could also extend to GetMap error messages and GetLegendGraphic responses)
2. Extend the GetCapabilities response document to include several INSPIRE
specific elements not currently specified within WMS 1.3.0 specification.
These include:
a. Resource Type
b. Resource Locator
c. Spatial Data Service Type
d. Temporal Reference
e. Conformity
f. Metadata Point of Contact
g. Metadata Date
h. Metadata Language
Finally, as stated above, there is a dependency on the suggested RFC at
http://trac.osgeo.org/mapserver/wiki/HidingLayersInOGCWebServices
--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/INSPIRE-compliancy-A-request-for-comments-on-a-possible-RFC-tp5661761p5661761.html
Sent from the Mapserver - Dev mailing list archive at Nabble.com.
More information about the mapserver-dev
mailing list