Meldingen geo-standaarden

Het aanleveren van twee gegevensgroepen voor intensiteit en snelheid bij SpoordeelGPP en SpoordeelBGE was toegespitst op aanleveringen van Prorail, maar niet handig voor andere leveranciers. Niet alle gegevens zijn relevant en er zit overlap in voor wat betreft snelheid.

Het samenvoegen van de 2 gegevensgroepen IntensiteitgegevensSpoor en SnelheidgegegevensSpoor tot 1 groep IntensiteitgegevensSpoor met de volgende attributen:

<img:intensiteit>
  <img:intensiteit>0</img:intensiteit>
  <img:profieltypeSnelheid>doorgaand</img:profieltypeSnelheid>
  <img:spoorvoertuigcategorie>2</img:spoorvoertuigcategorie>
  <img:dagdeel>nacht</img:dagdeel>
  <img:snelheid>67</img:snelheid>
  <img:remindicatie>false</img:remindicatie>
  <img:treintype>reizigers</img:treintype>
  <img:rijrichting>oplopend</img:rijrichting>
  <img:materieelnaam>MAT64</img:materieelnaam>
</img:intensiteit>

De laatste 3 zijn optioneel en krijgen dus kardinaliteit

.

• Wie gaat er wat van merken? Data providers, software leveranciers, de API, gebruikers
• Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Niet echt, behalve dat de gegevensgroep intensiteit meer omvattend wordt.
• Heeft het impact op het xml-schema? Ja
• Is het backward compatible in de zin van validatie op het schema? Nee, want er verdwijnt een gegevensgroep.
• Heeft het impact op de regels in IMG? Nee
• Heeft het impact op de omgevingsregeling? Ja
• X,Y,Z-wijziging: X

Niet meer toestaan van wijzigingsmethode Intrekken & vervangen als alternatief voor renvooi.

Er zijn twee aanleidingen voor dit voorstel: 1. Uitgangspunt van de STOP/TPOD-standaard is dat voor het wijzigen van tekst gebruik gemaakt wordt van de wijzigingsmethode renvooi. Als tijdelijke alternatieve maatregel was het toegestaan om als alternatief daarvoor gebruik te maken van de wijzigingsmethode Intrekken & vervangen, met de boodschap dat deze mogelijkheid op enig moment zou vervallen. Inmiddels hebben we een verbeterd alternatief, Integrale tekstvervanging. Alle plansoftware is inmiddels overgegaan op Integrale tekstvervanging of op renvooi. Intrekken & vervangen als (tijdelijke) alternatieve wijzigingsmethode is daarom niet meer nodig. 2. Het niet meer gebruiken van Intrekken & vervangen als alternatieve wijzigingsmethode is een vereiste voor het invoeren van functionaliteit die OW-objecten aan Regelingen toekent.

Omgevingsdocumenten hebben de vorm van een regeling die in de loop van de tijd met wijzigingsbesluiten gewijzigd wordt. Uitgangspunt van de STOP/TPOD-standaard is dat de wijzigingsbesluiten voor het wijzigen van tekst gebruik maken van de wijzigingsmethode renvooi: een wijzigingsmethode waarbij in het besluit alleen de onderdelen staan die gewijzigd worden, waarin de verwijderde, gewijzigde en toegevoegde tekst wordt gemarkeerd. De STOP/TPOD-standaard kent daarnaast Intrekken & vervangen, als reguliere methode wanneer een bestuursorgaan een bestaande regeling helemaal wil intrekken en die regeling wil vervangen door een nieuwe regeling. Er is dan zowel juridisch als technisch sprake van intrekken en vervangen. Een voorbeeld is de provincie die de omgevingsvisie Mooi Provincieland intrekt en vervangt door de omgevingsvisie Gaaf Provincieland, waarin geheel nieuw beleid is vastgelegd. Door gebruik te maken van de (reguliere) wijzigingsmethode Intrekken & vervangen (in plaats van de oorspronkelijke regeling in te trekken en geheel separaat de nieuwe regeling te publiceren) wordt benadrukt dat weliswaar sprake is van een geheel nieuwe regeling, maar dat er wel een relatie bestaat tussen de oude en de nieuwe regeling.
Renvooi bleek voor plansoftware erg complex. Daarom hebben we toegestaan dat gebruik gemaakt wordt van Intrekken & vervangen als alternatieve wijzigingsmethode wanneer het toepassen van renvooi technisch nog niet mogelijk is. Met deze methode wordt de juridische wijziging technisch uitgevoerd met Intrekken & vervangen. Deze mogelijkheid is, o.a. in de TPOD's, duidelijk gepresenteerd als tijdelijke alternatieve maatregel, waarvan de toepassing vanaf invoering van Release B niet meer zou zijn toegestaan.
In STOP is Intrekken & vervangen als alternatief voor renvooi niet anders dan regulier Intrekken & vervangen: de aanlevering bestaat uit een intrekking van de oude regeling (waarbij automatisch alle GIO's worden ingetrokken) en een nieuwe regeling waarin de opvolgingsrelatie wordt aangegeven. In IMOW werkt Intrekken & vervangen als alternatief voor renvooi wel anders dan regulier Intrekken & vervangen. Bij regulier Intrekken & vervangen moet het bevoegd gezag alle OW-objecten van de in te trekken regeling beëindigen; de nieuwe regeling krijgt geheel eigen OW-objecten. Bij Intrekken & vervangen als alternatief voor renvooi moeten de OW-objecten die direct met de regeling verbonden zijn (Regeltekst, Divisie, Divisietekst, Pons, Regelingsgebied) voor zover ze in de nieuwe regeling blijven bestaan wel opnieuw aangeleverd worden, maar ze hoeven niet beëindigd te worden. Dit is een uitzondering op de uitgangspunten voor het wijzigen van objecten in IMOW. Door deze uitzondering is het niet mogelijk om OW-objecten aan regelingen toe te kennen, er is dan onduidelijkheid of de OW-objecten bij de oude of bij de nieuwe regeling horen.

Al snel bleek dat Intrekken & vervangen (als alternatieve toepassing) nadelen heeft, met name wanneer bij de regeling een of meer tijdelijk regelingdelen behoren; dan is Intrekken & vervangen niet mogelijk. Daarom hebben we een verbeterd alternatief ontwikkeld, de wijzigingsmethode Integrale tekstvervanging. Aan de STOP-kant wordt bij deze methode niet de regeling maar de regelingversie ingetrokken en vervangen door een nieuwe regelingversie. Aan de IMOW-kant worden bij Integrale tekstvervanging alle uitgangspunten voor renvooi-wijzigen onverkort toegepast; de uitzonderingen die bij Intrekken & vervangen worden gemaakt voor Regeltekst, Divisie, Divisietekst, Pons en Regelingsgebied zijn hierbij niet van toepassing. Integrale tekstvervanging is wel mogelijk als bij de regeling een of meer tijdelijk regelingdelen behoren.

Alle plansoftware is inmiddels overgegaan op Integrale tekstvervanging of op renvooi. Intrekken & vervangen als (tijdelijke) alternatieve wijzigingsmethode is daardoor niet meer nodig. Daarom kunnen we overgaan tot het niet meer toestaan van Intrekken & vervangen als (tijdelijke) alternatieve wijzigingsmethode.
Het gebruik van Intrekken & vervangen als regulier mechanisme om een regeling in te trekken en te vervangen door een nieuwe regeling blijft uiteraard wel toegestaan.

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.

Voorgestelde wijziging
Attribuut bronobjectID verplaatsen van ExterneVeiligheidsObject naar LocatieEVActiviteit.

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

Toelichting
De adviesgroep heeft besloten het niet te doen. Het attribuut is nog maar net toegevoegd en heeft zijn nut nog niet kunnen bewijzen in de praktijk.

Zie ook https://github.com/Geonovum/imev-werkomgeving/issues/95#issuecomment-1462087255 en opmerkingen daarna.

*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*

1 Het voorstel is om bij 'OpslagVuurwerkF1F2F3T1T2 het volgende 'Inrichtingselement' toe te voegen 'Objecttype': Verkoopruimte

2a Om een 'Bewaarplaats' bij 'OpslagVuurwerkF4' te hernoemen naar een 'BewaarplaatsF4' (ivm afwijkend attribuut: 'hoeveelheidNEMBewaarplaats', zie onder)

2b Om een 'SamengesteldeReferentie' bij 'OpslagVuurwerkF4' te hernoemen naar een 'SamengesteldeReferentieF4' (ivm afwijkend attribuut: 'hoeveelheidNEMBewaarplaats', zie onder)

2c Om een 'Bewaarplaats' bij 'OpslagVuurwerkF1F2F3T1T2' te hernoemen naar een 'BewaarplaatsF1F2F3T1T2' (ivm afwijkend attribuut: 'hoeveelheidVuurwerkBewaarplaats', zie onder)

2d Om een 'SamengesteldeReferentie' bij 'OpslagVuurwerkF1F2F3T1T2' te hernoemen naar een 'SamengesteldeReferentieF1F2F3T1T2' (ivm afwijkend attribuut: 'hoeveelheidVuurwerkBewaarplaats', zie onder)

3a. om het attribuut 'hoeveelheidVuurwerk': Niet te verplaatsen maar te behouden bij: OpslagVuurwerkF4; Het voor OpslagVuurwerkF4 te hernoemen naar: 'hoeveelheidNEMLocatie'; De definitie aan te passen van 'Hoeveelheid vuurwerk (als Netto Explosieve Massa in kg)' naar 'hoeveelheid Netto Explosieve Massa (NEM) in de inrichting: sommatie van de aanwezige hoeveelheid NEM in de bewaarplaats en de bewerkingsruimte, uitgedrukt in kilogrammen' .

3b. - Niet te verplaatsen maar te behouden bij: OpslagVuurwerkF1F2F3T1T2; Het voor OpslagVuurwerkF1F2F3T1T2 te hernoemen naar: 'hoeveelheidVuurwerkLocatie' De definitie aan te passen van 'Hoeveelheid vuurwerk (als Netto Explosieve Massa in kg)' naar 'hoeveelheid consumentenvuurwerk in de inrichting: sommatie van de aanwezige hoeveelheid consumentenvuurwerk in de bewaarplaats, de bufferbewaarplaats en de verkoopruimte, uitgedrukt in kilogrammen' .

4a. om het attribuut 'hoeveelheidNEMBewaarplaats': Op te nemen in het IMEV bij een 'BewaarplaatsF4', een 'SamengesteldeReferentieF4 en een 'Bewerkingsruimte' (zodat de som uitgerekend kan worden); Te voorzien van de definitie: Toegestane hoeveelheid Netto Explosieve Massa (NEM) in vuurwerk van categorie F4 in de bewaarplaats of bewerkingsruimte in kg

4b. om het attribuut 'hoeveelheidVuurwerkBewaarplaats': Op te nemen in het IMEV bij een 'Bufferbewaarplaats', een 'BewaarplaatsF1F2F3T1T2' en een 'Verkoopruimte', (zodat de som uitgerekend kan worden); Te voorzien van de definitie: Toegestane hoeveelheid vuurwerk van categorie F1, F2 of F3 en pyrotechnische artikelen voor theatergebruik in de (buffer)bewaarplaats of verkoopruimte in kg [*https://user-images.githubusercontent.com/80040145/234599412-a5368711-78c5-4643-90ba-e2e88d456fbe.png] Unable to render embedded object: File (*[*https://user-images.githubusercontent.com/80040145/234599412-a5368711-78c5-4643-90ba-e2e88d456fbe.png) not found. [*https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png] ![*https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png|alt="image"*|https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png|alt="image"]

**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 Voor bestaande data moet bedacht worden hoe de hoeveelheden verdeeld worden over meerdere bewaarplaatsen.

Toelichting

Er speelt een fundamentele vraag net als in #41 en #89: a) Is het IMEV bedoeld om de gegevens van de EV contouren te delen inclusief een aantal gegevens die nodig zijn als basisgegeven bij de EV contour? b) Is het IMEV bedoeld om de gegevens van de EV contouren te delen inclusief alle gegevens die nodig zijn om de contour te berekenen? Het uitgangspunt voor het IMEV is altijd het BKL. Dus alleen gegevens die voor het REV gevraagd worden in het BKL horen thuis in het IMEV. Dit zal dus eerst per geval bekeken moeten worden.

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

Voordruk

• < 420 kPa
• ≥ 420 kPa

Categorie aantal bevoorradingen

• ≤ 5
• > 5

reactietijdNoodstop

• ≤ 5 s
• > 5 s

hoeveelheidsklasse stikstofgehalte

• [N2] < 5%
• 5% ≤ [N2] ≤ 10%
• [N2] > 10%

• 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: X

laag

Een volledige inventarisatie waar dit voorkomt is nog niet uitgevoerd

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

WAS: https://user-images.githubusercontent.com/9932784/231439229-d4be9fa6-7e63-434b-ad9f-bc295f87b87d.png

WORDT: https://user-images.githubusercontent.com/9932784/231439535-bc2a7cb2-ec0e-4f0d-afd9-9b3dff635908.png

Met een / wordt in bovenstaande figuur aangegeven dat het attribuut afgeleid is uit andere gegevens en dat het door bronhouders dus niet hoeft worden aangeleverd. In de toelichting van het attribuut wordt opgenomen hoe het wordt afgeleid, of waar het vandaan komt. In dit geval gaat het om gegevens uit de BAG die via de pandIdentificatie zijn op te vragen. Met als tekst bij bijvoorbeeld '/gebruiksdoeleinden': Definitie: Het vergunde gebruiksdoel of de vergunde gebruiksdoelen zoals geregistreerd in de BAG. Toelichting: Dit gegeven wordt niet door de bronhouder aangeleverd maar wordt door het REV gegenereerd op basis van de pandIdentificatie. Daarnaast wordt het attribuut “gebruiksdoeleindenDetail“ toegevoegd, omdat de gebruiksdoleinden zoals in de BAG staan niet toereikend zijn.

• 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

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

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

Was: https://user-images.githubusercontent.com/9932784/231506330-9dd49f59-7a2c-4cab-9fea-301e3c353b15.png

Wordt: https://user-images.githubusercontent.com/9932784/231508009-fb1e848e-d2f6-40f6-85df-5d4a6ab7172f.png

Zie ook #52 en #68.

Geef hier een indicatie van de impact van de wijziging:

• 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

midden

Ruimte voor extra toelichting. Bijvoorbeeld alternatieven die je overwogen hebt.

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

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.