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
Previous comments
7
SE - Sweden (invited by kristpet (disabled))
02 May 2019 11:21:59
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)
NO - Norway (invited by kristpet (disabled))
03 May 2019 10:01:39
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
FI - Finland1 (invited by kristpet (disabled))
03 May 2019 10:19:04
Transboundary identifies are very difficult to maintain. The depth of the lakes is available only for a few lakes.
The suggested changes are agreed.
PL - Poland1 (invited by kristpet (disabled))
03 May 2019 14:42:59
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.
IT - Italy (invited by kristpet (disabled))
03 May 2019 15:58:20
sizeValue: values had to be calculated from the geometry - we agree
meanDepth: can be dropped
PT - Portugal (invited by kristpet (disabled))
03 May 2019 18:05:08
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.
SI - Slovenia (invited by kristpet (disabled))
03 May 2019 21:52:47
Regarding the question "Should this information be reported in 2022?„ we do not oppose to the deletion of GML data elements "relatedZoneTransboundaryIdentifier, sizeValue, meanDepth".
You cannot post comments to this consultation because you are not authenticated. Please log in.
Previous comments
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.
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.
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.
Regarding the question "Should this information be reported in 2022?„ we do not oppose to the deletion of GML data elements "relatedZoneTransboundaryIdentifier, sizeValue, meanDepth".