Table of contents
- 2. REPORTING AT SURFACE WATER BODY LEVEL (SCHEMA SWB)
- 2.3. Pressures and impacts on surface waters
- 2.4. Ecological status and exemptions
- 2.5. Chemical status of surface waters, exemptions and Mixing Zones
- 3. REPORTING AT GROUNDWATER BODY LEVEL (SCHEMA GWB)
- 3.3. Pressures and impacts on groundwater
- 3.4. Quantitative status of groundwater and exemptions
- 3.5. Chemical status of groundwater and exemptions
- 4. MONITORING (SCHEMA MONITORING)
- 5. PROTECTED AREAS (SCHEMAS SWB AND GWB)
- 6. REPORTING AT MS LEVEL: COMPETENT AUTHORITIES, RBDS AND SUB-UNITS (SCHEMA RBDSUCA)
- 7. REPORTING AT RBD/SUB-UNIT LEVEL FOR SURFACE WATER (SCHEMA SWMET)
- 7.3. Methodologies classification ecological status and potential
- 7.4. Methodologies classification chemical status
- 7.5. Overall management objectives (nutrients, river continuity)
- 7.6. Definition of significant pressures and impacts
- 7.7. Methodologies exemptions
- 8. REPORTING AT RBD/SUB-UNIT LEVEL FOR GROUNDWATER (SCHEMA GWMET)
- 8.4. Definition of significant pressures and impacts
- 8.5. Methodologies exemptions
- 9. REPORTING AT RBD/SUB-UNIT LEVEL FOR RBMP (SCHEMA RBMPPOM)
- 9.4. Water abstractions and exploitation of water resources
- 10. PROGRAMME OF MEASURES REPORTED AT RBD/SUB-UNIT LEVEL (SCHEMA RBMPPOM)
- 10.2. Targeted questions on basic measures and other aspects
- 10.3. Estimates of cost of measures
- 10.4. Co-ordination of measures in international RBDs
- 10.5. Progress with and achievements of the programme of measures for the first planning cycle
- 11. REPORTING AT RBD/SUB-UNIT LEVEL FOR ECONOMIC ANALYSIS AND COST RECOVERY (SCHEMA RBMPPOM)
- Overview of comments presented at WG DIS
- WISE spatial data presentation at WG DIS
WISE spatial data presentation at WG DIS
Slide 1
Slide 2
Slide 4
Reference data sets
The 5 datasets are needed and used.
- Can the RiverBasinDistrict dataset
be derived from the SubUnit dataset? - Can an agreement be reached
on the inclusion/exclusion of
coastal waters and territorial waters? - Are all attributes needed (and reported)?
-
The 5 datasets are needed and used. SE: Yes. All datasets are used Can the RiverBasinDistrict dataset be derived from the SubUnit dataset? SE: No. We do not agree Can an agreement be reached on the inclusion/exclusion of coastal waters and territorial waters? SE: We are of the opinion that coastal and territorial waters have to be included Are all attributes needed (and reported)? -
- Yes, the RBD dataset can be derived from the SubUnits by the EEA
- Coastal waters and territorial waters should be included
- No opinion on the attributes. We deliver what are asked, if we have the data
-
Groundwaterbody and surface waterbody can locate in the border of RBDs or the location can be entirely in the other RBD. The water body is administrate by one RBD.
The validation rules should accept this exceptional.
There is no monitoring site in each water body
Coastal waters should be included in the river basin district. Territorial waters should not.
-
Slide 1-4
RiverBasinDistrict feature class should be combined with SubUnit feature class. Code list should distinguish feature type (RBD or SU) within one layer. Countries which have only RBD’s need to duplicate same areas for SU layer sake. It is additional work with little to no value.
-
- Can the RiverBasinDistrict dataset
be derived from the SubUnit dataset? Yes - Can an agreement be reached
on the inclusion/exclusion of
coastal waters and territorial waters? Coastal waters should be included; territorial water should not be included - Are all attributes needed (and reported)?
- Can the RiverBasinDistrict dataset
-
- Can the RiverBasinDistrict dataset be derived from the SubUnit dataset?
Yes, the RiverBasinDistrict dataset can be derived from the SubUnit dataset. In Portugal these datasets are coincident.
- Can an agreement be reached on the inclusion/exclusion of coastal waters and territorial waters?
Only Coastal waters should be included.
If we have the data, we will reporte when are solicited.
-
1.Regarding the question "Can the RiverBasinDistrict dataset be derived from the SubUnit dataset?" we do not agree with the proposal. Preparation of management plans on River basin district level represents fundamental provision of Water framework directive. Preparation of more detailed sub-units and sub-plans is not a requirement of the Water framework directive which in paragraph 5 of article 13 states that “River basin management plans may be supplemented by the production of more detailed programmes and management plans….”. Further more, we suggest to delete SubUnit dataset or, to be more consistent with Water framework directive, to make the reporting of SubUnit dataset optional.
2.Regarding the question "Can an agreement be reached on the inclusion/exclusion of coastal waters and territorial waters?" we explain that in accordance with our national legislation coastal waters and territorial waters are defined as beeing a part of the River basin district. Therefore we are obligated to report them regardless of the proposal on inclusion/exclusion.
Slide 6
Should this information be reported in 2022?
- relatedZoneTransboundaryIdentifier
reported in only 0.3% of the water bodies - sizeValue
values had to be
calculated from the geometry - meanDepth
only 6.4% of the lakes
-
relatedZoneTransboundaryIdentifier (reported in only 0.3% of the water bodies) SE: We support that the rational behind the necessity of such an identifier. sizeValue (values had to be calculated from the geometry) SE: It has to be clear on which base the sizeValue is calculated, generalisation levels can prove to be problematic when calculating size meanDepth (only 6.4% of the lakes) SE: It is not necessary for WFD reporting (but for SoE reporting is it a requirement) -
- We need to keep the relatedZoneTransboundaryIdentifier in case we will change the IDs
- We wish to keep sizeValue. The information on scale should be in the metadata
- meanDepth can dropped
-
Transboundary identifies are very difficult to maintain. The depth of the lakes is available only for a few lakes.
The suggested changes are agreed.
-
Slide 6-8
relatedZoneTransboundaryIdentifier, sizeValue, meanDepth, relatedToIdentifier, catchmentArea, maximumDepth – those attributes should be removed from schema. PL will not provide them in 2022 reporting and looking back on the 2016 reporting, this might be the case for many o other MS.
purpose – duplicates should be avoided whenever it is possible. It is far more difficult to provide proper data quality when you need to keep track in how many places to update/correction is needed. This may lead to inconsistency of database and thus decrease its overall credibility.
-
- sizeValue: values had to be calculated from the geometry - we agree
- meanDepth: can be dropped
- sizeValue: values had to be calculated from the geometry - we agree
-
- sizeValue
values had to be calculated from the geometry
We disagree with "sizeValue" to be calculated from the geometry. The sizeValue have to be calculated in projected coordinate system of each country.
- meanDepth
only 6.4% of the lakes
We are of the opinion that the information is not necessary. We don't have available the meanDepth for the water bodies.
- sizeValue
-
Regarding the question "Should this information be reported in 2022?„ we do not oppose to the deletion of GML data elements "relatedZoneTransboundaryIdentifier, sizeValue, meanDepth".
Slide 8
Should this information be reported in 2022?
- relatedToIdentifier
reported in only 0.7% of the sites - purpose
duplicate with relation
to the descriptive data in the XML - catchmentArea
only 33% of the sites on rivers - maximumDepth
only 22% of the sites
-
relatedToIdentifier (reported in only 0.7% of the sites) SE: Yes. We are of the opinion that the information is necessary purpose (duplicate with relation to the descriptive data in the XML) SE: No. We are of the opinion that the information is not necessary catchmentArea (only 33% of the sites on rivers ) SE: It is not necessary for WFD reporting (but for SoE reporting is it a requirement) maximumDepth (only 22% of the sites) SE: It is not necessary for WFD reporting (but for SoE reporting is it a requirement) -
- relatedToIdentifier should be kept
- purpose should be dropped, since it is a duplicate
- catchmentArea should be kept
- maximumDepth could be dropped
-
Spatial Data Schemas.
Spatial data schemas should be simplified. Approach depicted in slide 6 and 8 is far more optimal than the current one. Using the nomenclature from INSPIRE schemas would make it a lot easier to map data sets in ETL tools for INSIRE. WaterBodies, RBD’s, SU’s should have AM theme elements as its core. MonitoringStations should have EF theme elements as its core.
-
- relatedToIdentifier: can be dropped
- purpose: duplicate with relation to the descriptive data in the XML - can be dropped
- catchmentArea: can be dropped
- maximum depth: can be dropped
- relatedToIdentifier: can be dropped
-
- purpose
duplicate with relation to the descriptive data in the XML
We are of the opinion that the information is not necessary, because this is in XML.
- catchmentArea
only 33% of the sites on rivers
We are of the opinion that the information is not necessary.
- maximumDepth
only 22% of the sites
We are of the opinion that the information is not necessary.
- purpose
-
Regarding the question "Should this information be reported in 2022?":
- We do not agree with deletion of GML data elements "relatedToIdentifier" and ""relatedToIdentifierscheme". This GML data elements are important for Slovenia because of our widely spread karstic characteristics of the land (for example, a monitoring site for monitoring the quality of ground water bodies can be spatially located on the adjacent water body due to flow characteristic in the karstic area. In these cases, the data element "relatedToIdentifier" gives an important information on the interconnection of the monitoring site and ground water body)
- We do not oppose the deletion of GML data elements "purpose, catchmentArea, maximumDepth"
- In case that the element "catchmentArea" would not be not deleted (still a subject of next reporting) we suggest that "catchment area" refers to surface water bodies and not to monitoring sites.
-
SE: We are of the opinion that it would be preferable if the same identity series is used in both cases.
-
SE: We are of the opinion that it would be preferable if the same identity series is used in both cases.
we agree with SE
-
-
We agree with SE
-
Regarding "euMonitoringSiteCode vs. eionetMonitoringSiteCode" it is our opinion that in the WFD reporting exercise "euMonitoringSiteCode" shoud be used.
Slide 11
SurfaceWaterBodyCentreline
- Currently it is optional
- Could it be reported
for lakes and reservoirs?
-
Currently it is optional SE: The information is already requested and not optional Could it be reported for lakes and reservoirs? SE: Yes. We are of the opinion that is can and should be reported -
- Centreline was not optional
- Yes, Norway wish to report this
-
Centerline should be kept optional.
In Finland there are some lakes without the connection for river network and those they cannot get centerline.
-
- the SurfaceWaterbodyCentreline is not optional
- Yes, it is imprtant to keep it
-
- Currently it is optional
In WISE GIS Guidance (Version 6.0.6) the representation of the centrelines of surface water bodies is requested.
- Could it be reported for lakes and reservoirs?
We are of the opinion that is can and should be reported.
-
Regarding SurfaceWaterBodyCentreline it is our opinion that the reporting should remain "optional".
GroundWaterBodyHorizon
- This is a complex dataset.
- Is it really necessary?
- WG Groundwater
-
Is it really necessary? WG Groundwater SE: We agrees that the WG Groundwater need to be adressed concering this issue before deciding on the way forward -
- This is a complex dataset.
Yes, we agree.
- Is it really necessary?
Is it necessary to to mapping representation
-
Water bodies of groundwater in Slovenia most often represent a vertical sequence of two or more horizons or open or closed aquifers (with cold or warm groundwater). This information is important for the purpose of assessment and interpretation of the status of waters. It is our opinion that reporting of spatial data, regarding groundwater horizons, represent additional administrative burden.
-
SE: NitrateVulnerableZone is already reported through the Nitrates Directive.
SE: drinkingWaterProtectionArea coincides with WaterBody geometries
SE: We have not reported any designatedWaters
-
If MS has already reported spatial data under other reporting oblication, the data should not be reported again.
-
- We wish to keep bathingWaters
- We wish to keep designatedWater
- We wish to keep drinkingWaterProtectionArea
- We wish to keep VulnerableZone
-
For bathinhgWaters, nitrateVulnerableZone and sensitiveArea have already reported spatial data under other reporting oblication. So the data should not be reported again.
-
Regarding the reporting of ProtectedArea we strongly support simplification to avoid duplication of data.