XML/GML voor IM Metingen

De meeste internet communicatie vindt plaats via gestandaardiseerde berichten op basis van de zogenaamde eXtensible Markup Language (xml). Een voorbeeld van xml is deze webpagina die onder de ‘motorkap' in een xml-variant (html) is opgeslagen. In het xml-formaat is ‘ID' de sleutel. Het voordeel van dit xml-bericht is dat de betekenis van wat er wordt uitgewisseld automatisch gekoppeld wordt aan de inhoud. Hiermee kan automatisch worden gecontroleerd (gevalideerd) of de inhoud van een bericht overeenkomt met de standaard. Dit gebeurt op basis van een xsd-schemabestand. Hieronder staat meer informatie over xsd’s en welke xsd-bestanden de Aquo-standaard kent en hoe deze bestanden werken.

De Geography Markup Language (gml) is een ISO 19136 standaard, waarin specifiek voor geometrieën (punten, lijnen en vlakken) uitbreidingen zijn opgenomen. In de praktijk wordt er echter nog regelmatig gekozen om geografie op basis van ESRI-shapefiles (.shp files) uit te wisselen. Voor de uitwisseling binnen het WVP waarbij IMWA Waterveiligheid gebruikt wordt is gekozen voor het shape-formaat. Oorspronkelijk was voor de uitwisseling via het CDL van HWH gekozen voor XML/GML uitwisseling, sinds de realisatie van Keten2020 is dat echter GeoPackage geworden.

Reden om te kiezen voor GML als standaard formaat:

  • Gml is een open standaard die op de ‘pas toe of leg uit' lijst is opgenomen, evenals Aquo zelf. Daarmee is het voor overheden een verplichting deze te ondersteunen. Daarnaast vragen de geografische basisregistraties, zoals de BRO en BGT en de Europese Kaderrichtlijn INSPIRE, allemaal om services die de informatie in gml- formaat aanbieden. Het shape-formaat is, hoewel veel gebruikt, een merkgebonden (ESRI) standaard. Overigens is de specificatie wel uitvoerig beschreven en vrij beschikbaar.
  • Het is bij shapefiles niet mogelijk om ‘geometrieën' te mixen. Het is bijvoorbeeld niet mogelijk om waterlopen (lijnen) en meren (vlakken) in één bestand uit te wisselen. Maar ook niet om meetpunten en waterlichamen in één bestand te stoppen. Hierdoor raken onderlinge relaties ‘kwijt'. In het gml-formaat is het wel mogelijk om meerdere geometrie typen op te nemen. Ook is het mogelijk om een enkel object meerdere geometrieën te geven (bijvoorbeeld weergave als lijn én vlak bij een waterloop).
  • Shapefiles zijn gericht op het overbrengen van geometrieën. Andere eigenschappen (attributen) kunnen alleen via een excel-achtige tabel worden gekoppeld. Is een attribuut complex, een verwijzing naar een ander object of komt het meervoudig voor, dan biedt het shape-formaat hier eigenlijk geen goede oplossing voor. Vaak wordt dit dan via een truc uitgewisseld, waarbij informatie bewust dubbel wordt uitgewisseld waardoor de ontvanger het bestand weer moet ontwarren. Het gml-formaat biedt alle mogelijkheden die ook in een relationele database beschikbaar zijn.
  • Shapefiles zijn niet heel strikt in de inhoud van velden / veldtypen. Er is ook geen definitie beschikbaar van de inhoud van een veld. Als daar bijvoorbeeld een vaste lijst voor geldt dan kan niet (automatisch) gecontroleerd worden of deze ook daadwerkelijk is toegepast. Gml-berichten zijn te valideren op hun structuur en inhoud. Zowel ontvanger als verzender van informatie komt makkelijker achter eventuele fouten.

Nadelen van GML:

  • Hele complexe (gelaagde) structuur van definitie van elementen.
  • met XML meng je data en structuur door elkaar.

Voorbeelden

Het XML/GML-formaat is voor IM Metingen gedefinieerd. Voor het uitwisselen van metingen is dit voorbeeldbestand beschikbaar gesteld:

Voor dit Aquo-model is tevens een XSD schemabestand beschikbaar voor de validatie. Het xsd-bestand van IM Metingen verstrekt het IHW niet aan derden. Wanneer u dit document wenst te ontvangen, kunt u contact opnemen met SIKB Helpdesk.

Voorbeeld bestand XML IM Metingen



XSD pagina hieronder (Moet ik nog verder bewerken): xsd-bestand

Een xsd-bestand (xsd: XML Schema Definition) definieert hoe de structuur van een xml-uitwisselbericht eruit ziet. Daarbij is de relatie met de Aquo-modellen als volgt: in de modellen is (logisch) uitgewerkt welke objecten of klassen welke relaties met elkaar hebben en welke eigenschappen elk object heeft.

Het Aquo-model kan worden gezien als een mensleesbaar diagram. Het xsd-bestand geeft aan hoe dit model technisch gezien uitgewerkt wordt in een xml-bestand. Het xsd-bestand is dan ook een machineleesbaar bestand waarin is uitgewerkt welke objecten of klassen voorkomen met daarbij hun kenmerken en onderlinge relaties. Het zelfbeschrijvende aspect van een xml-bericht is dan ook altijd dat in de header van het bericht staat volgens welke structuur het bestand is opgemaakt.

Het doel van een xsd-bestand

Middels het xsd-bestand kunnen partijen onafhankelijk controleren of een xml-bericht juist gestructureerd is en of er gebruik is gemaakt van geldige domeinwaarden. Ook kan het xsd gebruikt worden om een eigen database te mappen naar een xml-structuur. Er zijn verschillende applicaties beschikbaar die deze conversie op basis van een xsd-bestand uit kunnen voeren. Deze stap vergt vaak wel enig nadenken, maar in elk geval wordt de naamgeving van de elementen door de software geregeld.

Beheer In het beheer van de Aquo-standaard wordt het technisch model (xsd) telkens opgebouwd vanuit het logische model. In het logische model worden de wijzigingen bijgewerkt en vervolgens feitelijk “fysiek” uitgewerkt in het technische model.

Ontwikkelingen

In het verleden werd in het Uitwisselmodel Aquo (UM Aquo) xsd voor elk van de attributen of eigenschappen, waar een domeinwaarde achter zat, via een apart schemabestand aangegeven welke domeinwaarden geldig waren.

In de huidige situatie, bij het gebruik van URN’s als verwijzing naar domeinwaarden in het xml bestand, hoeft u de domeinwaarden niet meer te importeren, maar kunt u in plaats daarvan een verwijzing opnemen naar een register met een sleutel die de bedoelde waarde uniek identificeert (URN). Het grote voordeel hiervan is dat vervallen domeinwaarden (dus met oude data) nog steeds uitgewisseld kunnen worden.

Een ander voordeel is dat niet langer alleen gebruikt gemaakt kan worden van de geldige domeinwaarden volgens de Aquo-standaard, maar ook van andere standaarden. Indien u een verwijzing naar een ander register opneemt, bijvoorbeeld het register van beschermde dieren in de UK, dan kunt u de gegevens over dat diertje (volgens het Engelse register) nog steeds volgens de structuur van Aquo uitwisselen.

Wijzigingen op de structuur van een Aquo-uitwisselformaat verlopen via een update van de Aquo-standaard en de bijbehorende wijzigingsprocedure.

Uniform Resource Name

De verwijzing naar de naam van het register met in dat register een unieke identificerende sleutel zal gebeuren op basis van URN's (Uniform Resource Name). Hierin wordt de bedoelde waarde geïdentificeerd door een namespace (in onderstaande voorbeelden Aquo en een voorbeeld UKHO), een aanduiding van het register binnen die namespace en de eigenschap die de waarde uniek identificeert. In de Aquo xml uitwisselbestanden is gekozen voor het gebruik van het ID voor het uniek indentificeren van een waarde.

Voorbeeld: de grootheid “temperatuur”.

urn:aquo:parameter:ID:1522 Voor een fictieve uitwisseling naar het UK Hydrographic Office, zou men bij wijze van spreken ook kunnen verwijzen naar de geldige (fictieve) waarde in het register van die partij:

urn:UKHO:quantity:ID:1234

N.B. Bij biotaxa wordt in URNs géén gebruik gemaakt van ID’s, maar van de namen van de biotaxa.

Voorbeeld: de brasem.

urn:aquo:biotaxon:naam:Abramis brama

N.B. Er dient wel een service geïmplementeerd te zijn die een URN om kan zetten naar een URL, waarop er meer over een domeinwaarde gelezen kan worden.