SDIMEV-12: Wijzigingsverzoek IMEV Basisnet en Buisleidingen

[PB-GNM]

Beste allen,

Alvast een vooraankondiging voor een verzoek tot besluit door IenW over een aanpassing aan het informatiemodel (door beheerder Geonovum) van Basisnet Wegen (Bronhouder RWS) en Buisleidingen (bronhouder DPO). Dit verzoek komt formeel van Rijkswaterstaat en DPO, maar aangezien Geodan beide organisaties ondersteunt in de vervaardiging van de datasets voor REV hebben Mirke, Jorn en ik deze conceptmemo opgesteld.

Zouden jullie de bijbehorende memo willen lezen en commentaar leveren zodat eenieder het begrijpt, we e.e.a. aan info kunnen aanvullen zodat uiteindelijk een besluit genomen kan worden?

Item is toegevoegd aan deze besluitenlijst op de samenwerkingsruimte en de memo staat ook hier op de samenwerkingsruimte.

Ik heb meerdere betrokkenen meegenomen in deze mail zodat we meteen het proces van wijzigingsverzoeken voor het IMEV kunnen oefenen.

Groet, Jos

(1) bijlagen

166 Wijzigingsverzoek IMEV Basisnet en Buisleidingen opm Ruben.docx

24 jun. 2021, 08:57 am Activiteit

[PB-GNM]

#166 Wijzigingsverzoek IMEV Basisnet en Buisleidingen opm Ruben.docx

[PB-GNM]

Antwoord ProRail: Vraag_RWS_antwoord_ProRail_GithubIssue_22.docx

[PalmJanssen]

Ik concludeer het volgende uit het wijzigingsverzoek:

1. Nu wordt middels de huidige codering van IMEV data een PR=1 contour zichtbaar waar de PR=0. Dat is ongewenst
2. Dit kan voorkomen bij alle typen van het Basisnet: wegen, water, spoor, en ook andere ReferentieEvContouren
3. Een PR=0 is niet hetzelfde als geen PR. In het eerste geval is er wel een object PRContour met een geometrie en bijbehorende informatie. In het tweede geval is er geen object PRContour.
4. Een PR=0 en 'helemaal geen PR' komen beide voor.
5. Een PR=0 contour moet wel als PR=0 contour herkenbaar zijn maar dan als geometrie gelijk aan de bron (=ReferentieEVContour), meestal een referentielijn.

Ik heb hierbij twee vragen: klopt punt 3? klopt punt 4? Is bij punt 5 zo dat een PR=0 contour wel PR-informatie bevat zoals maatgevendeStof en aardRisico?

[PalmJanssen]

In overleg met Ruben Polman RWS komen we tot het volgende voorstel: Analyse 1) In de categorisering van het basisnet (weg, spoor, water) op PR komt de waarde 'geen PR' niet voor. 2) Wel komt voor PR afstand = 0. Dit betekent dat er bij een afstand van 0 meter een plaatsgebonden risico van 10-6 geldt. 3) PR = 0 is daarmee een geadministreerde waarde. 4) Deze waarde kan gedeeld worden door een PR contour van 0 meter op te nemen. 5) In concreto is dat dezelfde geometrie als de referentieEVContour, een lijn multilijn en mogelijk een punt.

Oplossing 1 (wissel expliciet de PR = 0 informatie uit en beeld die af op de kaart met een eigen correcte geometrie): Maak de geometrietypen punt, lijn en multilijn ook mogelijk voor een PRContour. In het geval dat een afstand = 0 is ingevuld, is de geometrie van de PRContour hetzelfde als de geometrie van de ReferentieEVContour.

• aanpassing aan model: maak PRContour geometrie ook van type punt, lijn of multilijn

Oplossing 2 (wissel expliciet de PR =0 informatie uit en beeld die niet af met een eigen geometrie): Zorg dat er geen geometrie wordt ingevuld bij de geometrie van een PRContour indien de afstand = 0 is ingevuld. De PRContour informatie is opvraagbaar via de de relatie tussen ReferentieEVContour en EVContour.

• aanpassing aan model: Geen

Oplossing 3 (wissel niet expliciet de PR = 0 informatie uit) Er is wel een ReferentieEVContour maar er is geen PRContour aangekoppeld.

• aanpassing aan model: maak de koppeling tussen ReferentieEVContour en EVContour optioneel (1.. -> 0..)

[RubenPolman]

Oplossing 1 en 3 lijken mij de beste keuzes, ik heb geen expliciete voorkeur (Ruben).

[JanneVst]

Reactie Geodan ontwikkelteam

De relaties voertUit, heeft en resulteertIn kunnen niet uit het model geëxtraheerd worden: vandaar dat we de properties evActiviteiten, referentieEVContouren en evContouren hebben bedacht.

De eisen die hieraan gesteld worden zijn niet per activiteit in het model aangeven, maar voor iedere activiteit hetzelfde. Wij hebben dat dus opgelost met algemene aannames. Bijvoorbeeld voor alle evActiviteiten, referentieEVContouren en evContouren geldt: (required, Array, minLength=1).

De vraag hier is: willen/moeten we dit per activiteit modelleren?

Specifieke constraints (op PRContour:typePlaatgebondenRisico) worden verwerkt in onze zgn. BKLConfig. Dit beschrijft voor alle BKL activiteiten de samenhang van voertUit/heeft/resulteertIn: met specifiek attribuutwaarden van typePlaatsgebondenRisico in geval van resulteertIn = PRContour.

Deze informatie komt uit de enumerations in de diagrammen per activiteit. Ook hierbij is de vraag willen/moeten we dit per activiteit modelleren?

PRContour kan volgens de openapi beschrijving wel MultiPolygon zijn (zoals de Aandachtsgebieden). In het model: type VlakOfMultiVlak. Alleen geldt wel dat iedere referentieEvContour minimaal 1 evContour moet hebben, maar dat mag dan ook iets anders zijn dan een PR contour.

[PB-GNM]

Gesloten, omdat het verwerkt is in versie 1.1 en via #46 in 1.2 en omdat die versie goedgekeurd is.