Wijzigingsverzoek eenheden toevoegen (SDIMEV-35 en 81)

[PB-GNM]

Wijzigingsverzoek:
In het IMEV zijn de eenheden van maatvoering niet gemodelleerd, ze staan genoemd in de toelichting,
bv.:
tag="description" value="De uitwendige diameter van de buisleiding in millimeters."
description: 'Netto explosieve massa (NEM) in kg.'
Is het mogelijk om naast type Realeen Unit’ toe te voegen zoals m., kg. ?
–
Janne Verstappen

[PB-GNM]

Nu is het opgeslagen in de definitie:

[PalmJanssen]

werkgroep:

• meeteenheid is cruciaal om te weten;
• inventariseer of bij elke maatvoering de eenheid in de definitie is opgenomen;
• je kan dan de eenheid in de catalogus opzoeken
• de informatie over meeteenheid zou je ook in de data willen zien. Dit kan met aanpassing in JSON waarbij de eenheid als vaste info bij een maatvoering is gedefinieerd. Informeer bij Geodan

[PalmJanssen]

Inventarisatie maatvoering eenheid in definitie.

• bijna overal is de eenheid in de definitie opgenomen.
• eenheid ontbreekt bij:
• aandachtgebied:afstand
• prcontour:afstand
• windturbine:ashoogte
• rotordiameter
• vermogen
• zwaartepunt
• nominaaltoerental
• lengtegondel
• breedte gondel
• hoogte gondel

[PalmJanssen]

Zet ze als voorstel allemaal op meters. Type is real. Dus bijvoorbeeld 5,65 meter is mogelijk.

[PalmJanssen]

• aandachtgebied:afstand: meters
• prcontour:afstand: meters
• windturbine:ashoogte : meters
• rotordiameter: meters
• vermogen : megawatt
• zwaartepunt: meters
• nominaaltoerental : herz
• lengtegondel : meters
• breedte gondel: meters
• hoogte gondel : meters
• massaGondel: kilogram (ton is geen si eenheid)

[PB-GNM]

Gesloten, omdat het verwerkt is in versie 1.2 en omdat die versie goedgekeurd is.

[PB-GNM]

Opnieuw ingebracht door Geodan
In het IMEV zitten attributen ('grootheden') die een waarde moeten krijgen. Deze waarden hebben vaak een eenheid,
De eenheden van grootheden in het REV staan zijn vaak verwerkt in de definitie van een attribuut en of het gegevenshandboek.

Het volledig, duidelijk en op een bruikbare manier aangeven van de eenheden in het IMEV is belangrijk. Allereerst zorgt het ervoor dat de kwaliteit van de opgeslagen
gegevens in het REV omhoog gaat, en kan het daarmee ongelukken in de praktijk voorkomen. Bronhouders weten dan zeker in welke eenheid hun gegevens moeten worden aangeleverd.
Het op een bruikbare manier aangeven van de eenheden maakt het eenvoudiger en minder foutgevoelig voor softwareleveranciers om de juiste eenheden aan te geven bij inputvelden.
Iedere leverancier hoeft deze dan niet uit de attribuut beschrijvingen te halen en apart te implementeren, hetgeen foutgevoelig is. Wanneer eenheden evt aangepast moeten worden, kan dat consistent gebeuren bij alle softwareleveranciers wanneer eenheden op een bruikbare manier worden aangeleverd.

Voorstel is om voor elke grootheid die in het IMEV wordt gebruikt, de eenheid op een volledige, duidelijke en
bruikbare manier in het IMEV op te nemen, en niet onvolledig en verborgen in een omschrijving en verspreid over meerdere bestanden.

Wellicht is dit toch mogelijk door het als een apart attribuut het IMEV op te nemen.
Het apart aanbieden van eenheden levert voordelen op en zou het goed zijn dit te overwegen:

• Software leveranciers kunnen de eenheden makkelijk inladen ipv uit de omschrijvingen te moeten halen. Dit is veel werk en foutgevoelig;
• Wijzigingen in eenheden / nieuwe attributen met eenheden kunnen ook eenvoudig ingeladen worden.

[PB-GNM]

Aanleiding wijziging

Het alleen melden van de eenheden in de definitie is foutgevoelig. Softwareleveranciers kunnen het hierdoor niet automatisch opnemen in hun software.

Voorgestelde wijziging

Opnemen van eenheden als apart attribuut heroverwegen.

Impactanalyse

• Wie gaat er wat van merken? Dataleveranciers, Softwareleveranciers
• Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
• Heeft het impact op het json-schema? Ja
• Is het backwardscompatibel? Nee
• X-, Y- of Z-wijziging: X of Y?

Prioriteit

midden

Toelichting

Deze wijziging is eerder door de expertgroep beperkt tot het opnemen in de definitie.
zie #31 (comment)
en #31 (comment)

[PB-GNM]

In de expertgroep van 17 mei is besloten om te adviseren om deze wijziging niet door te voeren.
Het voordeel is minimaal omdat het al in de definitie beschreven staat en opslaan in een apart attribuut zou leiden tot veel dubbele opslag.

[PB-GNM]

Tijdens het softwareleveranciersoverleg van 7 juni is er geen bezwaar geuit tegen het niet doorvoeren van deze wijziging.

[PB-GNM]

Adviesgroep 13-9-2023 heeft besloten deze wijziging niet door te voeren.