Blauw gebouw

Meldingen geo-standaarden

Op deze pagina vind je een overzicht van meldingen die zijn gedaan over standaarden die Geonovum beheert. Door in het zoekveld een standaard te selecteren, kan je de status van meldingen bekijken. Heb je zelf een melding gedaan, dan kan je ook zoeken op het ID-nummer van jouw melding.
Wil je juist een melding doorgeven aan ons? Ga dan naar onze helpdesk

  • WELT-252
  • Status
    Wachten op Support

Wijzigingsverzoek attribuut Bronobject ID

Aanleiding wijziging
Het attribuut bronobjectID is vooral bedoeld om REV-json datasets te kunnen koppelen met locaties/inrichtingen in een bronsysteem. Aangezien een REV-json dataset bij wijzigingen compleet aangeleverd moet worden, ligt het voor de hand dat voor verschillende onderdelen van deze dataset hetzelfde bronobjectID aanhouden. In het bronsysteem van onze omgevingsdienst (OpenWave van de ODR) zal waarschijnlijk het inrichting nummer gekozen worden als het te gebruiken bronobjectID. Dit is alleen relevant voor de locatie. Door de ingevulde waarde in het veld 'bronobjectID' automatisch over te nemen, is bij raadplegen van elk EV-object (locatie, EV-activiteit, referentie of EV-contour) duidelijk bij welk bronobjectID (locatie of inrichting) dit hoort. Eventueel zou het optionele veld 'bronobjectID' uit EV-objecten EV-activiteit, referentieEVContour en EVContour verwijderd kunnen worden, tenzij bronsysteem leveranciers het gewenst vinden dat dit toch zo blijft staan in het IMEV. Verwachting is dat bronhouders het niet nodig vinden om verschillende bronobjectID's per niveau in te vullen.

Er zijn ook tegenargumenten:
https://github.com/Geonovum/imev-werkomgeving/issues/95#issuecomment-1462087255

Voorgestelde wijziging
Attribuut bronobjectID verplaatsen naar LocatieEVActiviteit.

https://user-images.githubusercontent.com/80040145/223688675-795e67fe-f4bb-4e51-a2ab-51058c44646d.png

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

Prioriteit
midden
De wijziging is niet noodzakelijk, omdat het geen verplicht attribuut is, maar wel gewenst om onnodige vulling te voorkomen.

Toelichting
Er zou ook overwogen kunnen worden het te verplaatsen naar naar subtype LocatieActiviteit van LocatieEVActiviteit. In dat geval zou het dan niet gelden voor andere subtypes als Buisleidingstelsel en LocatieBasisnet.

  • WELT-251
  • Status
    Wachten op Support

Wijzigingsverzoek attribuut 'hoeveelheidVuurwerk' op VIII A/B

Beschrijving

Aanleiding wijziging
Het gaat om het attribuut ‘hoeveelheidVuurwerk’ op de volgende twee activiteiten:

· VIII-A Explosieaandachtsgebied vuurwerk voor opslag van categorie F4 – detail
· VIII-B Explosieaandachtsgebied vuurwerk voor opslag van categorie F1, F2, F3, of pyrotechnische artikelen voor theatergebruik van categorie T1 of T2 - detail

Het attribuut ‘hoeveelheidVuurwerk’ wordt uitgevraagd op activiteit niveau. Als gebruiker geef je hier als het ware een totale hoeveelheid vuurwerk van alle bewaarplaatsen, bufferbewaarplaatsen en/of bewerkingsruimten op één locatieactiviteit. Dit is voor de gebruiker van de Invoer Module niet gewenst.

Bijvoorbeeld: Het is mogelijk dat er 2 buffers staan op 1 locatieactiviteit. 1 buffer bevat 500 kg vuurwerk en 1 buffer bevat 1000 kg vuurwerk. Op dit moment moet je het getal 1500 invoeren op activiteitniveau. Als gebruiker wil je deze aantallen opvoeren per buffer.

Voorgestelde wijziging
Attribuut hoeveelheidVuurwerk verplaatsen van subtypes voor opslag van vuurwerk van het abstracte type BKLActiviteit naar (nieuwe) subtypes van ReferentieEVContour. In geval van Bewaarplaats en SamengesteldeReferentie moeten het nieuwe referentie types worden, want de oude worden ook voor andere activiteiten dan vuurwerkopslag gebruikt. Bufferbewaarplaats en Bewerkingsruimte kunnen hetzelfde objecttype blijven omdat die volgens de definitie specifiek voor vuurwerkopslag zijn.

https://user-images.githubusercontent.com/80040145/223678826-58042588-0614-44d5-b4c7-1d3a0c83b8ca.png

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? Ja
  • Heeft het impact op het json-schema? Ja
  • Is het backwardscompatibel? Nee
  • X-, Y- of Z-wijziging: X
  • WELT-250
  • Status
    Wachten op Support

Bewoording van enumeraties niet consequent

Aanleiding wijziging

De waardes in de enumeraties voor hoeveelheden en grootheden zijn niet consistent.

Voorgestelde wijziging

Voordruk

  • < 420 kPa
  • ≥ 420 kPa

Categorie aantal bevoorradingen

  • ≤ 5
  • > 5

reactietijdNoodstop

  • ≤ 5 s
  • > 5 s

hoeveelheidsklasse stikstofgehalte

  • [N2] < 5%
  • 5% ≤ [N2] ≤ 10%
  • [N2] > 10%
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, want enumeraties worden aangepast
  • Is het backwardscompatibel? Nee
  • X-, Y- of Z-wijziging: Y
  • WELT-249
  • Status
    Wachten op Support

KwetsbaarGebouw aanpassen aan BAG

Aanleiding wijziging
Het gewenste proces voor het bijwerken van kwetsbare gebouwen en locaties (KGL) in het REV is niet helemaal in lijn met het IMEV.

https://user-images.githubusercontent.com/80040145/220386405-9b24e2d1-8beb-4f88-969e-57d03af34339.png

Voorgestelde wijziging
Informatie die al in de BAG zit moet uit het IMEV gehaald worden, behalve de ID's waarmee een koppeling gelegd kan worden naar de BAG-objecten. Dat betekent verwijderen van de volgende attributen bij het object KwetsbaarGebouw:

  • geometrie
  • gebruiksdoeleinden
  • oppervlakte

En toevoegen:

  • pandidentificatie: IdentificatieBAG {0..1}
    * gebruiksdoeleindenInDetail: CharacterString {0..*}

    Het attribuut adresseebaarObjectIdentificatie kan blijven want dat gaat over het adres en niet over het pand. Een pand kan meerdere adresseerbare objecten bevatten. De kardinaliteit moet daarom naar {0..*}. Als een kinderdagverblijf in een pand zit waar ook andere adressen in zitten wil je wel weten welk adres bij dit specifieke kwetsbare object hoort. Omdat onbekend is waar in het pand dit kinderdagverblijf zit, is ook de geometrie van het pand nodig. Die kan dan gevonden worden met het BAGPandID.
    Volgens de definitie van een KwetsbaarGebouw in het BKL kan het ook om een woonwagen of woonschip gaan. In dat geval is er geen sprake van een BAG-pand en daarom is de kardinaliteit {0..1}

    .
    Het attribuut "gebruiksdoeleindenInDetail" wordt toegevoegd omdat de gebruiksdoeleinden in de BAG ontoereikend zijn om de kwetsbaarheid aan te geven.

https://user-images.githubusercontent.com/80040145/226675568-c6facf3c-2446-4b55-83dd-69c89108f19d.png

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
Voorstel oplossing
Zie hierboven
  • WELT-248
  • Status
    Wachten op Support

Opnemen verschillende enumeraties voor F4 en F1F2F3T1T2

Aanleiding wijziging
In het IMEV 1.3 bestaan o.a. de volgende objecttypen:

OpslagVuurwerkF4 (VIII-A Explosieaandachtsgebied vuurwerk voor opslag van categorie F4);
OpslagVuurwerkF1F2F3T1T2 (VIII-B Explosieaandachtsgebied vuurwerk voor opslag van categorie F1, F2, F3, of pyrotechnische artikelen voor theatergebruik van categorie T1 of T2).
Beide objecten hebben de enumeratie ' CategorieVuurwerk' met de waarden:

T1;
T2;
F1;
F2;
F3;
F4;
gegevenInTransitie.
Als gevolg hiervan is het bijvoorbeeld toegestaan om in het REV de 'OpslagVuurwerkF4' met elke waarde uit de enumeratie 'CategorieVuurwerk' op te voeren, zoals 'T1'.
Dit is onjuist en komt de kwaliteit van de REV data niet ten goede.

Voorgestelde wijziging
Neem een aparte enumeratie op in het IMEV voor 'Opslag-Vuurwerk-F4': ' CategorieVuurwerkF4' met cardinaliteit 0..1 en de waarde:
F4.
gegevenInTransitie
Neem een aparte enumeratie op in het IMEV voor 'Opslag-Vuurwerk-F1F2F3T1T2': 'CategorieVuurwerkF1F2F3T1T2' met cardinaliteit 0 .. * en de waarden:
F1;
F2;
F3;
T1;
T2;
gegevenInTransitie.
Laat de enumeratie ' CategorieVuurwerk' vervallen.
Impactanalyse
Wie gaat er wat van merken? Dataleveranciers van buisleidingen, 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? Alleen niet als oude aanlever bestanden waarden gekozen hebben die hier niet aan voldoen
X-, Y- of Z-wijziging: Y

  • WELT-247
  • Status
    Wachten op Support

Aanpassingen aan LocatieEVActiviteit in v1.3 ook doorvoeren op Buisleidingstelsel

Aanleiding wijziging
Aanpassingen zoals gedaan aan LocatieEVActiviteit in v1.3 zijn niet doorgevoerd op Buisleidingstelsel.
Dat is niet consequent.

Voorgestelde wijziging
Dezelfde aanpassingen aan LocatieEVActiviteit in v1.3 ook doorvoeren op Buisleidingstelsel.
Het betreft toevoegen locatieomschrijving en aanpassen kardinaliteit kvkNummerExploitant van 1..1 naar 1..*

Impactanalyse

  • Wie gaat er wat van merken? *Dataleverancier en 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? *Ja*
  • X-, Y- of Z-wijziging *Y*
Voorstel oplossing
Dezelfde aanpassingen aan LocatieEVActiviteit in v1.3 ook doorvoeren op Buisleidingstelsel.
Het betreft toevoegen locatieomschrijving en aanpassen kardinaliteit kvkNummerExploitant van 1..1 naar 1..*
  • WELT-246
  • Status
    Wachten op Support

Validatiematrix bijwerken

Bij deze de bijgewerkte validatiematrix (bijlage). Hierbij het verzoek deze bij te werken.

  • WELT-245
  • Status
    IN BEHANDELING

Specificatie van toegestane OW-objecten in TPOD voorbereidingsbesluit en TPOD projectbesluit

In de huidige versies van TPOD voorbereidingsbesluit en TPOD projectbesluit is in het hoofdstuk over het annoteren van het tijdelijk regelingdeel met OW-objecten verwezen naar TPOD omgevingsplan en TPOD omgevingsverordening. Daarmee wordt de indruk gewekt dat alle OW-objecten die in omgevingsplan respectievelijk omgevingsverordening gebruikt kunnen worden, ook voor een voorbereidingsbesluit en het tijdelijk regelingdeel van het projectbesluit gebruikt kunnen worden. Inmiddels is gebleken dat er OW-objecten zijn waarmee een voorbereidingsbesluit c.q. projectbesluit niet geannoteerd kan worden, gezien de bepalingen van de Omgevingswet over de inhoud van die instrumenten. Daarom is het wenselijk om in deze TPOD’s niet meer te verwijzen naar andere TPOD’s, maar in de TPOD’s te specificeren welke OW-objecten mogen worden gebruikt.

Voorstel oplossing
Voorgesteld wordt om in TPOD voorbereidingsbesluit niet meer te verwijzen naar TPOD omgevingsplan en TPOD omgevingsverordening en in TPOD projectbesluit niet meer te verwijzen naar TPOD omgevingsplan, maar in die TPOD’s te specificeren welke OW-objecten mogen worden gebruikt. Heel concreet komt dat laatste op het volgende neer:
* In TPOD voorbereidingsbesluit en TPOD projectbesluit wordt een productmodel opgenomen: een UML-diagram met de in dat omgevingsdocument te gebruiken OW-objecten

* In het voorbereidingsbesluit dat een omgevingsplan wijzigt met voorbeschermingsregels mogen de volgende OW-objecten niet gebruikt worden:
** Juridische regel van het type Omgevingswaarderegel
** Omgevingswaarde
** Pons

* In het voorbereidingsbesluit dat een omgevingsverordening wijzigt met voorbeschermingsregels mogen de volgende OW-objecten niet gebruikt worden:
** Juridische regel van het type Omgevingswaarderegel
** Juridische regel van het type Instructieregel
** Omgevingswaarde

* In het tijdelijk regelingdeel waarmee een projectbesluit een omgevingsplan wijzigt mogen de volgende OW-objecten niet gebruikt worden:
** Juridische regel van het type Omgevingswaarderegel
** Omgevingswaarde
** Pons
  • WELT-244
  • Status
    IN BEHANDELING

Citeertitel in BesluitMetadata en RegelingMetadata - Cardinaliteit in TPOD-standaard

In STOP is in zowel de BesluitMetadata als in de RegelingMetadata het gegeven Citeertitel een optioneel gegeven. Dat is in de TPOD’s overgenomen. In de TPOD’s wordt t.a.v. Citeertitel in de RegelingMetadata aanbevolen om dat gegeven te gebruiken; t.a.v. Citeertitel in de BesluitMetadata wordt aanbevolen om dat gegeven niet te gebruiken.

Inmiddels is gebleken dat de Citeertitel van Regeling én van Besluit voor de DSO-viewer een heel bruikbaar gegeven is om regelingversies van elkaar te kunnen onderscheiden en voor diverse zoekfuncties. Het is wenselijk om in de TPOD-standaard het gegeven Citeertitel in BesluitMetadata en RegelingMetadata verplicht te stellen.

Voorstel oplossing
Een aantal softwareleveranciers heeft aangegeven dat zij de Citeertitel (nog) niet in hun software hebben geïmplementeerd en dat zij dat niet op korte termijn gepland hebben. Daarom wordt voorgesteld om dit in twee stappen op te lossen:

- Stap 1: Citeertitel in BesluitMetadata en RegelingMetadata is in STOP en TPOD’s een optioneel gegeven, in de TPOD’s wordt aanbevolen het gegeven te gebruiken
(en uitgelegd waarom en hoe).
- Stap 2: Citeertitel in BesluitMetadata en RegelingMetadata is in STOP optioneel en in de TPOD's verplicht.

Geen updates meer missen?

Automatisch op de hoogte blijven? Meld je aan voor één van onze nieuwsbrieven.