-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verduidelijken hoe de fm-factor van het SpoordeelGPP berekend moet worden. #216
Comments
Tijdens de bijeenkomst tussen RIVM en Geonovum van 24 september is besproken dat dit issue eerst nog meer overleg nodig is tussen RIVM, Indiener van het probleem (DGMR) en Prorail. Het doel is dan om hier 1 duidelijk wijzigingsverzoek van te maken met een daarop aangepaste impact analyse. RIVM organiseert een bijeenkomst. |
Wie kan die werkwijze kort beschrijven, liefst met een plaatje? |
Hieronder een screenshot uit Geomilieu. Dus de wissellengte welke bij baanvak 1 wordt opgenomen is 2 maal de lengte van baanvak 1. Bij baanvak 2 is dit 2 maal de lengte van baanvak 2. Tekst uit het rekenvoorschrift: Nu is alleen bekend in de IMG of een feature onderdeel is van een wissel ja of nee 'Spoordeel maakt deel uit van een wissel.' De situatie kan worden opgelost door een toelichting op te nemen dat een feature maal 2 moet voor de berekening van de fm-factor. |
Aanleiding wijziging
Dit verzoek is aangemeld door DGMR met helpdesknummer SDIMG-136.
Er is onduidelijkheid over hoe de fm-factor berekend moet worden uit de lengte van de wissel.
Deze waarde is benodigd bij het berekenen van de emissie van spoordelen.
Tekst uit het rekenvoorschrift:
het aantal voegen gedeeld door de totale lengte van het wissel levert de informatie om de stootgeluidcorrectie te bepalen (de factor fm voor toepassing in formule 2.3c).
Nu is alleen bekend of een SpoordeelGPP onderdeel is van een wissel ja of nee.
Nu blijkt dat voor gegevens afkomstig van Prorail de wissellengte dan 2x de lengte van het SpoordeelGPP is. Prima, maar dat moet dan wel ergens worden vermeld.
Als een wissel in drie segmenten (2 takken en 1 steel) aangeleverd wordt, dan moet je voor het berekenen van fm de lengte van de wissel de lengte van 1 tak en 1 steel bij elkaar optellen. Als een ander het echter als 2 segmenten aanlevert (2 takken waarbij een steel overlappend is, dan moet je dat niet doen. Het RMG gaat natuurlijk niet over data. Wellicht was het beter geweest als we ooit in het IMG de waarde fm hadden geïntroduceerd of lengte wissel.
Analyse probleem
Het lastige van het huidige model is dat de te berekenen fm-factor hoort bij iets dat niet gemodelleerd is als apart objecttype. Namelijk de wissel. Het is daarmee vergelijkbaar met een optrektoeslagpunt zoals die later toegevoegd is aan het model bij WegdeelGPP. Zo zou er ook een Wissel-object toegevoegd moeten worden aan het model.
Ook is lastig dat er geen duidelijk voorschrift is hoe de relatie tussen de wissel en de spoordeelGPP-objecten is. Uit hoeveel spoordelen moet die bestaan. Dat kan dus verschillend gedigitaliseerd zijn. De enige eis is dat de een spoordeel akoestische homogeen is. Maar dan kan de wissel nog steeds met 2 of met 3 spoordelen opgenomen worden.
Om dit goed te modelleren moet er een nieuw objectype gemodelleerd worden: De wissel met daarbij de relatie met de spoordelen die deze wissel vormen en eventueel de lengte die te berekenen is uit de lengte van de gerelateerde spoordelen, zodat uiteindelijk daaruit de fm-factor berekend kan worden. De afstemming hierover vergt nader overleg met experts en kan dus niet op korte termijn gerealiseerd worden. Dit zou een apart wijzigingsverzoek moeten worden.
Op korte termijn kan er een werkafspraak gemaakt worden hoe hier nu mee omgegaan wordt.
Voorgestelde wijziging
De werkwijze hoe omgegaan moet worden met wissels wordt opgenomen in de toelichting bij het SpoordeelGPP.
Impactanalyse
Alleen opnemen van de toelichting heeft een minimale impact. Het is een Z-wijziging.
Het toevoegen van het objecttype Wissel heeft een veel grotere impact:
-Wie gaat er wat van merken? Diegenen die de fm-factor moeten berekenen
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
-Is er een herlevering nodig naar de CVGG? Nee
-Heeft het impact op het xml-schema? Nee
-Is het backward compatible in de zin van validatie op het schema? Ja
-Heeft het impact op de regels in IMG? Nee
-Heeft het impact op de validatieregels voor de CVGG? Nee
-Heeft het impact op de omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? Z
Toelichting
DGMR: het gaat goed wanneer een wissel is gemodelleerd met 3 segmenten, maar niet als het er bv 6 zijn.
zie opmerking DGMR.
The text was updated successfully, but these errors were encountered: