analysemeetwaarde voidable (waarde + eenheid), fout in XSD

[sjaakd]

Type issue

De analyse waarde is volgens de specifcatie:

Voor IMBRO/A-gegevens mag de waarde ontbreken wanneer het attribuut limietsymbool aanwezig is. 

Melding

De gemeenschappelijke XSD is analysewaarde afgebeeld op een gml:MeasureType. Bij een gml:MeasureType mag de waarde leeg zijn. Echter de uom niet. Dit lijkt niet in lijn met de catalogus

Beoordeling

-

Betrekking op

catalogus / XSD

Workaround

-

[AnnitaVijverberg]

Han, ik betrek jou ook even bij deze vraag omdat hij op het raakvlak zit van catalogus en XSDs.

Het veld analysemeetwaarde geeft de gemeten waarde of de rapportagegrens en is altijd gevuld. Indien het veld limietsymbool gevuld is (met < of >) betekent dit dat de waarde in het veld analysemeetwaarde de rapportagegrens is. Stakeholders hebben aangegeven dat bij historische data er soms wel limietsymbool aanwezig is maar geen waarde.

Vandaar de uitwerking in de catalogus met de regel bij analysemeetwaarde: "Voor IMBRO/A-gegevens mag de waarde ontbreken wanneer het attribuut limietsymbool aanwezig is." Han, klopt dit met wat er in de XSD staat?

[AnnitaVijverberg]

reactie Han: Mijns inziens is de regel "Voor IMBRO/A-gegevens mag de waarde ontbreken wanneer het attribuut limietsymbool aanwezig is." Als zodanig correct omgezet in de XSD.

Ter informatie:

Definition: Het in het laboratorium gemeten gehalte of de waargenomen waarde van de parameter. Wanneer het limietsymbool aanwezig is, mag hier de rapportagegrens geregistreerd worden in plaats van de gemeten waarde. Explanation: De bronhouder mag bij een gemeten waarde die kleiner is dan de waarde van het attribuut rapportagegrens of bij een waarde die groter is dan de hoogste grenswaarde besluiten of hij de gemeten waarde aanlevert of niet. Wanneer de bronhouder de gemeten waarde niet aanlevert, wordt in dit attribuut de rapportagegrens geregistreerd. De analysemeetwaarde wordt uitgedrukt in een meeteenheid. De meeteenheid is afhankelijk van de waarde van het attribuut parameter. De aan te leveren meeteenheid is vastgelegd in de referentietabel Parameterlijst. Alleen de prefix, het voorvoegsel van de eenheid in de parameterlijst mag afwijken. Staat er bijvoorbeeld ug/l in de parameterlijst, dan is mg/l ook toegestaan of als mS/m in de parameterlijst staat, is uS/cm ook toegestaan. Een dimensieloze waarde heeft een meeteenheid 1 (cijfer 1). Voor IMBRO/A gegevens kan het voorkomen dat de waarde van het gegeven ontbreekt. In dat geval is er wel een limietsymbool aanwezig dat aangeeft dat er gemeten is en dat de gemeten waarde lager (of hoger) is dan de grenswaarde. LimitSymbol Definition: Symbool dat aangeeft of de gemeten waarde kleiner is dan de rapportagegrens, ofwel groter is dan de hoogtse grenswaarde die gerapporteerd wordt. Explanation: Het gegeven is alleen aanwezig wanneer bij het attribuut analysemeetwaarde niet de gemeten waarde is opgegeven maar in plaats daarvan de rapportagegrens.

[AnnitaVijverberg]

Sjaak: Het gaat er om wat precies de waarde is? Is dit slechts de “getalswaarde” of is die “getalswaarde + meeteenheid”.

De formulering is ambigue. Het type is geduid als een “getal”, echter in de uitwerking is het een “eenheid + getal”. Dus, volgens mij klopt het domein-type niet.

Han heeft dit type vertaald als “measureType”, wat een waarde + een getal is. Door deze nillable te maken mag de waarde worden weggelaten. De eenheid is echter verplicht.

We weten dus niet wat we moeten doen met de casus “mogelijk geen waarde”. De eenheid opslaan? Uitgeven? Of is de XSD fout.

[AnnitaVijverberg]

Han: Annita, mag ik het volgende voorstel doen:

• De gegevenscatalogus is techniek onafhankelijk.
• Op dit moment hebben alleen een mapping naar XML/XSD; een tweede of andere mapping, bijvoorbeeld naar Json, is een toekomstige mogelijkheid.
• Binnen de XML/XSD mapping wordt een “Getal” in het conceptueel model gemapt naar een GML “Measure”.
• Daarbij is een XML-attribuut uom verplicht.
• Bij de meetwaarde van een eigenschap uit de parameterlijst is er altijd sprake van een gemeten parameter (via de kolom ID van de tabel ParameterLijst). Dus is er ook een default eenheid.
• Als er een waarde is, dan mag volgens de GAR catalogus de aangeboden eenheid afwijken van de default eenheid voor zover het gaat om de prefix.
• Als er geen waarde beschikbaar is voor de meetwaarde, wordt de default eenheid toch ingevuld.
• Ten allen tijde wordt in de uitgifte de ingenomen waarde voor de eenheid uitgegeven.
• Als we in de toekomst een andere mapping dan XML/XSD kiezen/toevoegen, dan zal op dit gedetailleerde niveau een eenduidige mapping gedefinieerd moeten worden.

[AnnitaVijverberg]

Sjaak: Han, je maakt een aanname. Je gaat voorbij aan hoe gemakkelijk dit is te realiseren door het bouw team. En.. aan wat je functioneel zou willen. Laat Annita svp daar eerst op antwoorden.

[AnnitaVijverberg]

Vanuit een gebruiker (aanleverend en afnemend) is het het meest logisch dat als er geen meetwaarde is, dat er dan ook geen eenheid is. Vanuit aanleveren (het betreft hier overigens gegevens uit DINO, daarvan is bekend dat deze situatie zich soms voordoet): er is geen waarde bekend en daarmee ook niet welke eventuele eenheid. Aanleveren van alleen een eenheid is onlogisch. Vanuit uitgifte: als de waarde van de meting ontbreekt, geeft de default waarde van de eenheid geen informatie. Het is niet aangeleverd en hoeft ook niet uitgeleverd te worden. Zo heb ik het vanuit de catalogus bedoeld.

[AnnitaVijverberg]

We laten dit issue open staan om in een volgende versie van de catalogus te verduidelijken dat bij ontbrekende waarden ook de eenheid niet aangeleverd wordt.

[sjaakd]

Kunnen we de XSDs aanpassen om de functionele bedoeling te respecteren.? Dan kan de catalogus in de volgende versie dit oppakken zoals dit Annita wordt voorgesteld.

[HanWelmer]

Ik zal de XSD's aanpassen. Niet het logisch model. Berichtencatalogi en voorbeeldberichten zal ik nalopen om te zien of die ook aangepast moeten worden.

[HanWelmer]

brocommon uitgebreid met complexType MeasureNillableType, opdat dit mechanisme naast in GAR ook in SFR en BHR-P gebruikt kan worden (huidige catalogi geven aan dat dit mechanisme daar ook nodig zal zijn). Zie versie 3.0.5 van brocommon.xsd in pull request https://gdngithub01.gdnnet.lan/BRO/bro_common_xsd/pull/59.

[HanWelmer]

garcommon.xsd aangepast van versie 0.7.1 naar 0.7.2:

Changed type of analysisMeasurementValue from gml:MeasureType to brocom:MeasureNillableType. Also changed some sample messages to exemplify this construct.

Please note the annotated documentation for this type in brocommon.xsd: use of this type requires 2 business rules on any element using this type.

Zie pull request https://gdngithub01.gdnnet.lan/GM/gar_xsd_wsdl/pull/24

[HanWelmer]

brocommon.xsd, garcommon.xsd en voorbeeldberichten gekopieerd naar de publieke github. Zie https://github.com/BROprogramma/GAR/tree/148cbedb0d3190e00bccc5b7982533040cf52f0e

[HanWelmer]

Berichtencatalogus innamewebservice en berichtencatalogus uitgiftebservice bijgewerkt. in confluende en nieuwe PDF-bestanden gegenereerd en opgenomen in de publieke GitHub.

Zie https://wiki.gdnnet.nl/display/BSta/GAR+Berichtencatalogus+innamewebservice Zie https://wiki.gdnnet.nl/display/BSta/GAR+Berichtencatalogus+uitgiftewebservice Zie https://github.com/BROprogramma/GAR/tree/138947c36ea15c057c1be0144b89a1570e837193