Presentatie door Koen Volleberg (LievenseCSO) voor de "Simona Gebruikersmiddag", tijdens de Deltares Software Dagen- Editie 2017. Donderdag 15 juni 2017, Delft.
3. Baseline NL
• Doel: samenvoegen van
afzonderlijke Baseline
schematisaties tot 1
landsdekkende Baseline
schematisatie van de actuele
modellen (j-modellen)
5. Baseline NL - uitdagingen
• Overlap tussen
verschillende Baseline
gebieden
• Controle welk model
meest actueel en
compleet is
• Daar data uit genomen,
andere gegevens
verwijderd Figuur 1-1: Aansluitingen Rijntakken - IJssel Vecht
6. Baseline NL - uitdagingen
• Aansluiting Rijn/Maas bij
Wilhelminasluis
• Secties sluiten niet aan
• Hoogtedata overlapt
• Behoud data uit
Maasmodel waar deze
ontbreekt in Rijnmodel
• Dijken en secties
aansluiten op elkaar
Figuur 2-2: Hoogtemodel Rijntakken
7. Conclusies Baseline NL
• Het is goed mogelijk gebleken om alle Baseline data van de verschillende
Nederlandse deelmodellen op te nemen in één landelijke database.
• Op een flink aantal locaties is de aansluiting tussen deelmodellen niet
fysiek aanwezig of niet consistent. Daarom zijn globale
aansluitmaatregelen gebouwd.
• In geval van overlap tussen 2 deelmodellen is een knip gelegd om de
overlap te verwijderen. Dit is niet altijd op dezelfde locatie gebeurd zoals
opgenomen in de clipgrenzen.gdb.
• Baseline-procestijden zijn acceptabel (9 uur hoogtemodel, 3.5 uur
ruwheden). Mixen duurt wel erg lang
8. Aanbevelingen Baseline NL
• De nu gebouwde aansluitmaatregelen zijn globaal geschematiseerd. Het is
raadzaam om dit nogmaals degelijk te doen op basis van DTB-Nat en de
Dienstspecificaties Baseline.
• Het detailniveau van de verschillende schematisaties verschilt soms sterk. Het
verdient aanbeveling om de grover geschematiseerde delen te verbeteren. Dit
geldt met name voor de NZK schematisatie rond Amsterdam en voor de
bodem van het Markermeer.
• De keuze dat de meest actuele schematisatie een oudere schematisatie
overruled is niet altijd de beste. De aantakkingen van het Amsterdam-Rijn
Kanaal zijn bijvoorbeeld in het ARK model nauwkeuriger geschematiseerd dan
in het Rijntakkenmodel maar door voornoemde keuze is dit niet in het
landelijk model geland.
9. Aanbevelingen Baseline NL
• In de toekomst is het zinvol om de Baseline data in een landelijke database te gaan
beheren. Dit vergt dan duidelijke afspraken over welke dienst welk gebied beheert.
• Op dit moment loopt in het kader van de ontwikkeling van Baseline 6 onderzoek naar
optimalisatie mogelijkheden voor zowel vereenvoudiging van het datamodel en
performanceverbetering van Baseline functies. Dit zal zeker nodig zijn als met een
landelijke database wordt gewerkt.
• Op het moment dat de Baseline data in een landelijke database zijn geïntegreerd is het
niet langer nodig om aansluitmaatregelen te onderhouden.
• De in Baseline opgeslagen bronnen en putten worden niet of in beperkte mate gebruikt
in de modelschematisaties. Het lijkt zinvol om met name richting het landelijk SOBEK
model (LSM) deze locaties goed te beheren en ook te gaan gebruiken.
• Een goed beheer van meetpunten, uitvoerlocaties, primaire keringen, verbindende
keringen in de landelijke database is gewenst. Dit zal beter beheerbaar worden.
10. Ontwikkelingen Baseline 6
• Doel: Baseline applicatie geschikt maken voor de 6e generatie
waterbewegingsmodellen in Dhydro
• Aanpassingen dataprotocol op nieuwe modelinvoer
• Leren van het verleden
– Handelingen voor de gebruiker
– Performance
11. Uitgangspunten
Principes:
• Uitgangspunt is Baseline-NL; één landelijke database, waaruit regionale clips worden gehaald
• Minder informatielagen:
– Overzichtelijker voor de gebruiker
– Mixen gaat sneller
– Onder de motorkap complexer
– Velddomeinen die invoermogelijkheden beperken daar waar nodig (bijvoorbeeld bereiken in
numerieke velden)
• Bestaande maatregelen dienen (middels conversie) behouden te worden
• Afschaffen afgeleide bestanden:
– Geen dubbele data-opslag
– Minder conversies nodig, dus sneller
– Wel meer gebruikersverantwoordelijkheid (ondersteunen met Invoermodule)
• Volledig engelstalig
• Verbetering performance
12.
13.
14.
15. In detail: de aanpassingen in het protocol
• Veel geschuif en samenvoegen van data
• Automatisch afleiden daar waar mogelijk
• Concept: details worden op dit moment nog uitgewerkt en afgestemd met
RWS-diensten
16. Feature dataset elevation
– Minder lagen met hoogtepunten
– Direct mixen op de Featureclasses in Featuredataset Elevation
– Daarna Secties_terrain en bodemhoogte terrain updaten in plaats van
volledig opbouwen (performance verbetering)
• Een test met Baseline-NL waarbij alle hoogtepunten van de Maas
worden vervangen is 50x zo snel bij een update tov een volledige
nieuwe opbouw terrain.
– Terrain zonder overlaten (cf Baseline 5)
– De speciale wensen (special elevation model tool) apart houden
17. Optimalisaties voor hoogtemodel Baseline 6
• Mixen direct op bestanden die in hoogtemodel komen
– Geen dubbele data
– Geen baswaq-achtige afleiding van 3D-lijnen, dus stappen overslaan
• Hoogtemodel updaten ipv opnieuw opbouwen
– Alleen daar waar hoogtes gewijzigd zijn wordt model aangepast. Snelheidverbetering afhankelijk van
grootte gewijzigd gebied.
• Breuklijnen niet meer als routes + events, maar als 3D-lijnen
– Véél sneller mixen. Performance verbetering groter naarmate database groter is
– Splitsingspunten model met 1 maatregel met breuklijnen + hoogteverschillijnen:
• Routes + events: 45 sec
• 3D-lijnen: 19 sec
– Baseline-NL met 1 maatregel met alleen breuklijnen inmixen:
• Routes + events: ca 2 uur
• 3D-lijnen: ca 5 minuten
19. Lopend uitzoekwerk ten aanzien van hoogtedata
• Verbetering visualisatie hoogtegegevens van de 3D-lijnen en routes
• Positie bandijken in Baseline 6 dataprotocol
– Opnemen in hoogtemodel ja of nee?
– Opnemen in overlaten ja of nee?
20. Ruwheden
• Minder lagen zonder stapeling
• Huidige attributen plassen tbv SOBEK (aangetakt, maaiveldhoogte) niet
langer aan plassen hangen maar bij specifieke SOBEK-functie automatisch
afleiden
• Generieke terminologie zodat herkenbaarheid niet beperkt wordt tot
rivierengebied
• NB. Aandacht besteden aan conversie van bestaande maatregelen waarbij
erase_hoogwatervrije_vlakken wordt gebruikt, dit zijn veelal concessies
die zijn vervallen/ingetrokken en hier dient dan de ‘actuele’ vegetatie te
worden terug gezet.
21. Looks ruwheden
• 1 laag voor vlakken, 1
voor lijnen en 1 voor
punten
• Geen overlap
• Pijlers naar specifieke
modelinvoer, dus uit
ruwheden
22. Locaties en model-data
Scheiding op functie in verschillende FC’s. Deze vijf FC’s hebben allemaal
een andere functie in de modellen:
– Bronnen_putten: zijn onttrekkingen of lozingen en daarmee van belang
voor waterbeweging
– Uitvoerlocaties: locaties waar FM waterbewegingsresultaten
(waterstand etc) vastlegt
– Kunstwerken: sturen de waterbeweging
– Cross-secties: dwarsprofiellijnen waar model waterbewegingsgegevens
vastlegt
– Hoogwatervrije lijnen: keringen
23. Locaties en modeldata
• Alle uitvoerlocaties in 1 bestand
– Wel de mogelijkheid om bij modelconversie uitvoerlocaties naar
meerdere bestanden weg te schrijven
• Type uitvoerlocatie (rivierkilometer, meetstation etc) wordt vastgelegd als
attribuut. Keuzes worden eventueel beperkt in een domain
• Cross-sections: Baseline extrapoleert niet naar bepaalde grens. Data wordt
as-is geconverteerd naar FM