60100194-001 MOB-ArcNoise2004 fin - b...Referentie : 60100194-001(MOB-ArcNoise2004) fin - b.doc -- Bijlage 2. -- Pagina 2 van 5 MOB/ARCNOISE 2004 Vinçotte Environment nv – Wölfel

Referentie : 60100194-001(MOB-ArcNoise2004) fin - b.doc -- Bijlage 1. -- Pagina 1 van 2

MOB/ARCNOISE 2004

Vinçotte Environment nv – Wölfel GmbH

BIJLAGE 1.


MOB/ARCNOISE 2004



MOB/ARCNOISE 2004


BIJLAGE 2.


MOB/ARCNOISE 2004


1. Terreinmodel

Voor het terreinmodel zijn er 2 verschillende elementtypes mogelijk: hoogtepunten en hoogtelijnen. Deze elementen hebben naast hun geometrie enkel hun absolute hoogte als eigenschap. Voor hoogtelijnen kan bijkomend al dan niet de diffractie over de hoogtelijn ingeschakeld worden. Hoogtepunten – IMMI element type: HOEP Attribuut naam Data type Commentaar ABS_HEIGHT Float Absolute Z-coördinaat van het hoogtepunt

De waarde van dit attribuut heeft voorrang op eventuele Z-waarden die in de geometrie vervat zouden zijn

Hoogtelijnen – IMMI element type: HOEL Attribuut naam Data type Commentaar ABS_HEIGHT Float Absolute Z-coördinaat van de hoogtelijn

De waarde van dit attribuut heeft voorrang op eventuele Z-waarden die in de geometrie vervat zouden zijn

DIFFRACTIO Boolean 1 (true) = gebruikt als diffractierand 0 (false) = geen diffractie

Het bestand met de hoogtepunten moet de naam “HOEP.shp” hebben, voor de hoogtelijnen is dat “HOEL.shp”.

2. Gebouwen

Voor gebouwen blijven de noodzakelijke eigenschappen beperkt tot de absolute hoogte van het gebouw. Andere eigenschappen zoals reflecties worden standaard ingesteld voor alle gebouwen bij de invoerprocedure. Gebouwen – IMMI element type: HAUS Attribuut naam Data type Commentaar REL_HEIGHT Float Relatieve Z-coördinaat van het gebouw

De waarde van dit attribuut heeft voorrang op eventuele Z-waarden die in de geometrie vervat zouden zijn. Alle knooppunten van de geometrie zullen de vermelde relatieve hoogte krijgen tov het berekende terreinmodel.

Bemerk dat gebouwen moeten bestaan uit een gesloten polygoon met minstens 4 hoekpunten! Het bestand met de gebouwen moet de naam “buildings.shp” hebben.

3. Bodem

Voor bodemdemping is uiteraard de bodemfactor G van belang, wat een reëel getal is tussen 0 en 1 waarbij 0 staat voor een perfect reflecterend bodemoppervlak en 1 voor een absorberend oppervlak. Verder is er ook een eigenschap die te maken heeft met de prioriteit van overlappende bodemelementen. De betekenis ervan zal in § 3 van Bijlage 3. duidelijker worden. Bodemdemping – IMMI element type: Dbod Attribuut naam Data type Commentaar G Float Reëel getal tussen 0 (reflecterend) en 1 (absorberend)

PRIO Integer Positief geheel getal gebruikt om prioriteit van overlappende bodemelementen te sturen.

Het bestand met de bodemelementen moet de naam “ground_effect.shp” hebben.


MOB/ARCNOISE 2004


4. Wegen

De wegen zijn het uiteindelijke geluidsemissie-element en hebben als akoestische beschrijving heel wat meer attributen nodig. Zo zijn er uiteraard eigenschappen van het verkeer zelf zoals het aantal voertuigen en gemiddelde snelheid, opgesplitst voor de verschillende referentieperiodes en voor lichte, middelzware en zware voertuigen1 afzonderlijk. Verder ook enkele eigenschappen van de weg zelf zoals de akoestische wegdekcorrectie / wegdekcategorie. De betekenis van een aantal attributen wordt verder ook verduidelijkt in § 4 van Bijlage 3. bij de verwerking van de gegevens.

Door de omschakeling van NMPB / XP S 31-133 naar RMW / SRM II diende de data specificatie voor wegen aangepast te worden. De eerste in lichtgrijs weergegeven tabel zou geldig geweest zijn bij een GIS-module volgens NMPB / XP S 31-133. RMW / SRM II vraagt iets minder informatie betreffende wegen en ook de wijze waarop bepaalde zaken worden voorgesteld is hier en daar gewijzigd.

Wegen – IMMI element type: R96 – volgens NMPB / XP S 31-133 Attribuut naam Data type Commentaar

REL_HEIGHT Float Relatieve Z-coördinaat van de weg De waarde van dit attribuut heeft voorrang op eventuele Z-waarden die in de geometrie vervat zouden zijn. Alle knooppunten van de geometrie zullen de vermelde relatieve hoogte krijgen tov het berekende terreinmodel.

Q_CAR_1 Float Aantal lichte voertuigen (< 3.5 ton) per uur voor dagperiode

Q_CAR_2 Float Aantal lichte voertuigen (< 3.5 ton) per uur voor nachtperiode

Q_CAR_3 Float Aantal lichte voertuigen (< 3.5 ton) per uur voor avondperiode

Q_TRK_1 Float Aantal zware voertuigen (> 3.5 ton) per uur voor dagperiode

Q_TRK_2 Float Aantal zware voertuigen (> 3.5 ton) per uur voor nachtperiode

Q_TRK_3 Float Aantal zware voertuigen (> 3.5 ton) per uur voor avondperiode

V_CAR_1 Float Gemiddelde snelheid lichte voertuigen in km/h voor dagperiode

V_CAR_2 Float Gemiddelde snelheid lichte voertuigen in km/h voor nachtperiode

V_CAR_3 Float Gemiddelde snelheid lichte voertuigen in km/h voor avondperiode

V_TRK_1 Float Gemiddelde snelheid zware voertuigen in km/h voor dagperiode

V_TRK_2 Float Gemiddelde snelheid zware voertuigen in km/h voor nachtperiode

V_TRK_3 Float Gemiddelde snelheid zware voertuigen in km/h voor avondperiode

TOT_WIDTH Float Breedte van het wegdek in m

RICHT_SEL Float Rijrichting 2 = éénrichtingsweg in richting van knooppunten wegelement 3 = éénrichtingsweg in tegengestelde richting van knooppunten

SURF_NUM Float Wegdekcorrectie in dB

TFL_NUM_1 Float Verkeersstroom voor dagperiode 1 = vlotte continue verkeersstroom 2 = gepulseerde continue verkeersstroom 3 = gepulseerde versnellende verkeersstroom 4 = gepulseerde vertragende verkeersstroom

TFL_NUM_2 Float Verkeersstroom voor nachtperiode 1 = vlotte continue verkeersstroom 2 = gepulseerde continue verkeersstroom 3 = gepulseerde versnellende verkeersstroom 4 = gepulseerde vertragende verkeersstroom

TFL_NUM_3 Float Verkeersstroom voor avondperiode 1 = vlotte continue verkeersstroom 2 = gepulseerde continue verkeersstroom 3 = gepulseerde versnellende verkeersstroom 4 = gepulseerde vertragende verkeersstroom

1 De categorieën van lichte, middelzware en zware voertuigen volgens de definitie van RMW / SRM II zoals weergegeven

op p. 32-33 van het rapport.


MOB/ARCNOISE 2004


Wegen – IMMI element type: STRt – volgens RMW/SRM II Attribuut naam Data type Commentaar

REL_HEIGHT Float Relatieve Z-coördinaat van de weg De waarde van dit attribuut heeft voorrang op eventuele Z-waarden die in de geometrie vervat zouden zijn. Alle knooppunten van de geometrie zullen de vermelde relatieve hoogte krijgen tov het berekende terreinmodel.

Q_LVEHIC_1 Float Aantal lichte voertuigen per uur voor dagperiode

Q_LVEHIC_2 Float Aantal lichte voertuigen per uur voor nachtperiode

Q_LVEHIC_3 Float Aantal lichte voertuigen per uur voor avondperiode

Q_MVEHIC_1 Float Aantal middelzware voertuigen per uur voor dagperiode

Q_MVEHIC_2 Float Aantal middelzware voertuigen per uur voor nachtperiode

Q_MVEHIC_3 Float Aantal middelzware voertuigen per uur voor avondperiode

Q_ZVEHIC_1 Float Aantal zware voertuigen per uur voor dagperiode

Q_ZVEHIC_2 Float Aantal zware voertuigen per uur voor nachtperiode

Q_ZVEHIC_3 Float Aantal zware voertuigen per uur voor avondperiode

V_LVEHIC_1 Float Gemiddelde snelheid lichte voertuigen in km/h voor dagperiode

V_LVEHIC_2 Float Gemiddelde snelheid lichte voertuigen in km/h voor nachtperiode

V_LVEHIC_3 Float Gemiddelde snelheid lichte voertuigen in km/h voor avondperiode

V_MVEHIC_1 Float Gemiddelde snelheid middelzware voertuigen in km/h voor dagperiode

V_MVEHIC_2 Float Gemiddelde snelheid middelzware voertuigen in km/h voor nachtperiode

V_MVEHIC_3 Float Gemiddelde snelheid middelzware voertuigen in km/h voor avondperiode

V_ZVEHIC_1 Float Gemiddelde snelheid zware voertuigen in km/h voor dagperiode

V_ZVEHIC_2 Float Gemiddelde snelheid zware voertuigen in km/h voor nachtperiode

V_ZVEHIC_3 Float Gemiddelde snelheid zware voertuigen in km/h voor avondperiode

Wegdekcorrectie voor gekende wegdekoppervlakken volgens RMW/SRM II (stand 12/05/2006) SURF_NUM Float

23 = 1L ZOAB

24 = 2L ZOAB

25 = 2L ZOAB fijn

26 = SMA 0/6

27 = uitgeborsteld beton

28 = geoptim. uitgeborsteld beton

29 = fijngebezemd beton

30 = oppervlakbewerking

31 = gewone elementenverharding

32 = stille elementenverharding

33 = dunne deklagen 1

34 = dunne deklagen 2

35 = ZSA-O

36 = ZSA-SD

37 = Dubofalt

38 = Nobelpave

39 = ZSM

40 = Micropave 41 = SilenTONE

42 = Viagrip

43 = Geosilent

44 = Micro-Top 0/6

45 = Micro-Top 0/8

46 = Stilstone

47 = Redufalt

48 = Accoduit

49 = Novachip

50 = Tapisville

51 = Fluisterfalt

52 = Microville

53 = Microflex 0/6

54 = Decipave

55 = Twinlay-m

56 = Stil Mastiek

57 = Bruitville

58 = Duolay

59 = Minifalt 60 = Konwé Stil

Het bestand met de wegelementen moet de naam “road_sources.shp” hebben.


MOB/ARCNOISE 2004


5. Geluidsschermen

Voor geluidsschermen langs wegen zijn de relatieve hoogte van het scherm tov het terrein en de absorptiekarakteristiek van het scherm van belang. Geluidsschermen – IMMI element type: WAND Attribuut naam Data type Commentaar REL_HEIGHT Float Relatieve Z-coördinaat van het scherm


ABSORPTION Float Absorptie van het geluidsscherm in dB

Het bestand met de geluidsschermen moet de naam “noise_barriers.shp” hebben.

6. Bruggen

Bruggen zijn een recent en nieuw type element in IMMI die het mogelijk maken om meer complexe verkeerssituaties beter voor te stellen. Nodige attributen zijn de relatieve hoogte van de brug, de breedte van het brugdek en de hoogte van eventuele geluidsschermen op beide zijden links en rechts1 van de brug. In essentie worden de bruggen gemodelleerd als rechte lijnelementen tussen een begin- en eindpunt en met een bepaalde breedte. Op die manier stellen ze een zwevend oppervlak voor gecentreerd rond het lijnelement. In § 6 van Bijlage 3. zal dit duidelijker worden. Bruggen – IMMI element type: BRCK Attribuut naam Data type Commentaar REL_HEIGHT Float Relatieve Z-coördinaat van de brug


BREITE Float Breedte van het brugdek in m

HLSW_LI Float Hoogte van een geluidsscherm op linkse zijde van de brug in m

HLSW_RE Float Hoogte van een geluidsscherm op rechtse zijde van de brug in m

Bemerk dat de brugelementen om correct gemodelleerd te worden in het overdrachtsmodel maar 2 knooppunten mogen hebben! Het bestand met de brugelementen moet de naam “bridges.shp” hebben.

1 De linkse en rechtse zijde van het brugelement zijn van elkaar te onderscheiden door te kijken van het beginpunt van de

brug (het 1ste

knooppunt) naar het eindpunt van de brug (het 2de

knooppunt).


MOB/ARCNOISE 2004


BIJLAGE 3.


MOB/ARCNOISE 2004


1. Terreinmodel

1.1. Beschrijving van de originele dataset(s)

Het Digitaal Hoogtemodel is een driedimensionale, digitale beschrijving van het aardoppervlak voor het Vlaams Gewest. Het model wordt weergegeven door X, Y en Z coördinaten gepositioneerd op maaiveldhoogte dwz zonder gebouwen noch vegetatie. Kenmerkend zijn de hoge nauwkeurigheid van de opgemeten punten en de hoge puntendichtheid, gemiddeld 1 punt per 20m². Het totale DHM voor heel Vlaanderen beslaat in die vorm 24 CD-ROM’s en wordt ook op die manier verdeeld. Bestandsformaat is op zich een ASCII tekstbestand. Er bestaan tevens afgeleide producten waarbij de oorspronkelijk opgemeten punten worden herleid naar een regelmatig raster met een rasterafstand van 5m, 25m of 100m en die dus een benadering zijn van het originele hoogtemodel.

1.2. Probleempunten en tekortkomingen

Het DHM heeft geen tekortkomingen gezien zijn hoge nauwkeurigheid. De hoge puntendichtheid is echter wel een probleem voor akoestische berekeningen op de grote schaal waarvan in dit project sprake is. Een dichtheid van 1 punt per 20m² betekent immers dat voor een testgebied van 36km² (6km x 6km) het aantal hoogtepunten oploopt tot 1 800 000 per gebied. IMMI heeft echter een limiet op het aantal hoogtepunten dat het kan bevatten, niet in het minst om de handelbaarheid van het model te kunnen garanderen en de rekentijden te beperken. Het maximaal aantal hoogtepunten werd voor dit soort grootschalige projecten ondertussen wel opgetrokken, maar de bezorgdheid om de handelbaarheid en rekentijden blijft wel. Wölfel heeft om met dit soort problemen om te gaan bijkomende functionaliteiten voor IMMI ontwikkeld, onder meer om het aantal hoogtepunten te reduceren op een semi-automatische manier. Deze functionaliteit zal beschikbaar worden in de IMMI Premium versies. Het algoritme is semi-automatisch in die zin dat de gebruiker een aantal parameters kan instellen die een invloed hebben op het verwerkingsproces én dat deze ook toezicht houdt op de berekening om te verifiëren dat deze in de richting van het gewenste resultaat evolueert, het gaat immers om een iteratief proces. Een dergelijke verwerking gebeurt dan ook bij voorkeur door een ervaren gebruiker die:

• inzicht heeft in de manier waarop het verwerkingsproces verloopt en op welke manier de ingestelde parameters daarop een invloed hebben,

• de kennis heeft om deze parameters aan te passen in functie van het terrein / beschouwde gebied, • de impact kan inschatten van de ingestelde parameters op de nauwkeurigheid van akoestische

berekeningen die met een geoptimaliseerd terreinmodel zullen gebeuren. Kort samengevat komt het algoritme erop neer dat het originele terreinmodel zal benaderd worden door een geoptimiseerd terreinmodel waarbij de gebruiker de maximale afwijking kan instellen tov het origineel. Daarbij kan dan nog onderscheid gemaakt worden tussen een (beperktere) maximale afwijking in de nabijheid van wegen en een (ruimere) maximale afwijking op verderaf gelegen locaties. Het algoritme doet een variatie in puntendichtheid ontstaan die groter is waar zich duidelijke en frequente niveauverschillen voordoen maar kleiner waar dat niet nodig is om een relatief vlak terrein te beschreven. Een triangulatie zorgt er dan voor dat meer correcte diffractieranden kunnen gebruikt worden. De voordelen van deze methode zijn de kortere tijd om geluidskaarten te berekenen met een bekende onnauwkeurigheid tegen gevolge van de terrein optimisatie en de duidelijke identificatie van terreinranden waar diffractie van belang kan zijn. Theoretisch kan de module een bewerkt terreinmodel afleveren en opslaan dat klaar is voor gebruik in een berekeningsmodule. Het afstemmen van de berekeningsmodule op een dergelijke invoer heeft echter maar zin op het moment dat een dergelijk terreinmodel klaar kan gemaakt worden voor gans Vlaanderen. Gezien het feit dat de module nog niet voldoende stabiel is in die zin dat een goed eindresultaat nog niet in alle omstandigheden gegarandeerd kan worden en veel supervisie vraagt, zal deze module nog niet op korte termijn bruikbaar zijn voor de modale eindgebruiker. Automatisatie van het proces is zeker niet aan de orde en er werd dan ook voor geopteerd om de invoer van het terreinmodel en de mogelijke voorbewerkingen meer open te houden.


MOB/ARCNOISE 2004


In de volgende paragraaf zal dan ook weergegeven worden hoe een terreinmodel volledig in een GIS omgeving vereenvoudigd en geoptimaliseerd kan worden, zoals ook gebeurd is voor de 3 testgebieden voordat de terreinmodule in IMMI voldoende ontwikkeld was. De belangrijkste tekortkoming daar is dat de methode om hoogtelijnen te reduceren tot enkel de akoestisch relevante hoogtelijnen in het terreinmodel door een selectie op basis van de tweede-orde afgeleide niet in alle gevallen goede resultaten geeft omdat de relevante diffractieranden immers niet altijd zullen samenvallen met een per definitie horizontale hoogtelijn. In één van de testgebieden – A12 Meise – is duidelijk dat enkel het Vlaams Gewest is beschouwd voor het DHM. In het zuiden van het gebied lijkt het alsof een deel van de data is weggesneden, een deel dat overeenkomt met de grens van het Brussels Gewest. Daar beschikt men dus niet over terreininformatie.

1.3. Beschrijving van de verwerking

Digitaal Hoogtemodel

contours

(Spatial Analyst)

Routesysteem

attribuut

ABS_HEIGHT

HOOGTELIJNEN

buffer Access - *.dbf

add X,Y data

IDW - interpolatie

(Spatial Analyst)

HOOGTEPUNTEN

- int (Spatial Analyst)

- raster to point

clip

attributen

ABS_HEIGHT,

DIFFRACTIO (= true)

-times (Spatial Analyst)

- int (Spatial Analyst)

- raster to point

curvature

(Spatial Analyst) &

selectie relevante waarde

buffer

selectie

split polylines

selectie

Er zijn vele mogelijkheden om het DHM in te brengen in de GIS omgeving, de beste manier lijkt om de ASCII tekstbestanden in te lezen in een Access database: op deze manier kunnen de aparte bestanden per kaartblad eventueel al gedeeltelijk gecombineerd worden tot grotere datasets en naderhand opgeslagen als database – *.dbf – bestanden die rechtstreeks en eenvoudig in ArcGIS geopend kunnen worden. De datatabel met X,Y,Z waarden kan daar omgezet worden naar een shapefile met punten op basis van de X,Y locaties en de Z waarde als attribuut.


MOB/ARCNOISE 2004


In de GIS omgeving is er geen echt goede wijze om het grote aantal punten op een intelligente manier uit te dunnen. Het berekenen van een regelmatig raster met een stapgrootte van 10m zal wel een vrij goede benadering zijn van het originele terreinmodel en het aantal hoogtepunten verminderen met ongeveer een factor 5. Het berekenen van een dergelijk raster kan met de functie IDW van de Spatial Analyst extensie. Een dergelijk raster kan dan in ArcGIS opnieuw omgezet worden naar een shapefile met punten, maar het nadeel is dat deze functie enkel werkt voor rasters van gehele getallen, zodat het raster eerst moet geconverteerd worden waarbij onvermijdelijk de getallen na de komma verloren gaan. Om dit probleem te omzeilen kan men eerst de rasterwaarden vermenigvuldigen met 10 – functie Times – en na de omzetting naar punten de attribuutwaarden opnieuw delen door 10. Op deze manier heeft men reeds een shapefile met hoogtepunten die het terrein op voldoende manier zal benaderen. Om de diffractie over het terrein in rekening te kunnen brengen, dient men ook over informatie mbt de relevante diffractieranden te beschikken. In de GIS omgeving kan dit door uitgaande van het eerder beschouwde hoogteraster de isocontouren te bepalen mbv de ArcGIS Spatial Analyst extensie – voor de hoogteverschillen per 1m – en deze op een intelligente manier te vereenvoudigen. Sowieso moet het gebruik van hoogtelijnen beperkt worden tot op een bepaalde afstand van de weg om praktisch te blijven, daartoe kan men een buffer met afstand van bv. 300m aanleggen rond de wegen en deze gebruiken om de hoogtelijnen te snijden. Omdat het van belang is dat enkel de meest relevante delen van de hoogtelijnen worden beschouwd, dient men de hoogtelijnen op te splitsen in aparte lijnstukken. Dit kan in ArcGIS met de functie “Split Line at Vertices” die evenwel enkel beschikbaar is in de ArcInfo versie. Een evenwaardig alternatief is de “Split Polylines” functie in de uitbreiding voor ArcGIS XTools Pro – www.xtoolspro.com – die zelfs nog meer mogelijkheden heeft. De relevante diffractieranden zullen zich steeds in de buurt bevinden van locaties waar de kromming van het terrein relatief groot is. Deze kan men benaderen door gebruik te maken van de functie Curvature van de Spatial Analyst extensie en deze toe te passen op het eerder berekende hoogteraster. Om de kromming van het terrein iets preciezer te bepalen en betere informatie te verkrijgen over de relevanta diffractieranden kan men eventueel een bijkomend raster berekenen met een kleinere stapgrootte van 5m en daarop de Curvature functie toepassen. Met de Symbology mogelijkheden in ArcGIS kan men dan op zoek gaan naar een waardegebied voor de kromming dat de terreinranden voldoende beschrijft, daarbij eventueel geholpen door ook de hoogtecontouren op dezelfde kaart te visualiseren. Uiteraard is men niet op zoek naar locaties waar de kromming in de buurt van 0 ligt. Een voorbeeld is een selectie van het waardegebied kleiner dan -1.5 en/of groter dan 1.5, maar deze waarden kunnen afhangen van site tot site en ook van de gekozen stapgrootte van het gebruikte hoogteraster. Een goede keuze vraagt het uitproberen van enkele waarden en een zekere ervaring van de gebruiker. Dit krommingsraster kan men dan opnieuw omzetten naar een puntenlaag met nu de kromming als attribuutwaarde. Om opnieuw het probleem te omzeilen met de conversie moeten de rasterwaarden eerst vermenigvuldigd worden met 10 – functie Times – en omgezet naar gehele waarden – functie Int – alvorens dit raster te converteren naar punten. Rond de punten waarvan de waarden – ondertussen vermenigvuldigd met 10 – dan in het eerder bepaalde waardegebied vallen kan men dan een buffer aanleggen van 5m of 10m en daarmee de relevante delen van de gesplitste hoogtelijnen selecteren die men dan kan exporteren als shapefile.

1.4. Aandachtspunten

• Het vereenvoudigen van het originele terreinmodel is geen eenvoudige opgave gezien het belang ervan voor de nauwkeurigheid van het uiteindelijke 3D model en de invloed op de rekentijden. Deze deelopdracht wordt bij voorkeur uitgevoerd door een gebruiker met de nodige ervaring – zie ook § 1.2.

1.5. Standaard eigenschappen bij invoer

• Geen standaard eigenschappen te definiëren.


MOB/ARCNOISE 2004


2. Gebouwen


Het Digitaal Hoogtemodel is in wat voorging al beschreven en wordt voor het bewerkstelligen van een dataset “gebouwen” enkel gebruikt voor het bepalen van de relatieve hoogte van gebouwen. De LANDUSE-laag van de TOP10v-GIS databank van het NGI bevat heel wat nuttige informatie, waaronder de ligging van gebouwen. LANDUSE herneemt alle gebouwen zoals die ook in de STRUCNET-laag van dezelfde databank weergegeven zijn, met uitzondering van elektriciteitscentrales en transformatorstations. Deze beide types gebouwen kunnen wel uit de dataset 3D-LINE gehaald worden. Zodoende hebben we STRUCNET als dataset niet nodig, wat een voordeel is voor de duidelijkheid en ook kostprijs (minder datasets aan te kopen). De LANDUSE-laag heeft het interessante “TYPE” attribuut wat alle elementen classificeert in functie van verschillende thema’s en types elementen. De betekenis van de attribuutwaarden is terug te vinden in het bij de dataset horende document “Structuur en codering van de gegevens TOP10v-GIS en TOP50v-GIS”. In Bijlage 4. zijn de belangrijkste elementen van de classificatie voor deze databank weergegeven. Deze classificatie laat toe om onderscheid te maken tussen verschillende types gebouwen zoals bewoonde gebouwen (type ST911: gewoon gebouw), gevoelige gebouwen zoals ziekenhuizen en scholen of andere gebouwen die enkel een functie hebben als afscherming. LANDUSE is beschikbaar in het ESRI coverage formaat wat betekent dat het meerdere types van elementen – punten, lijnen en polygonen – tegelijkertijd kan bevatten. Aangezien we over gebouwen spreken die een welbepaalde oppervlakte innemen zal hier enkel de polygonenlaag van belang zijn. Aaneensluitende rijhuizen worden daarbij vaak aangegeven als 1 gebouw. LANDUSE bevat evenwel geen hoogte-informatie. 3D-LINE is een CAD-bestand dat onder meer als *.dxf bestand kan afgeleverd worden. Bij het openen van een dergelijk bestand in ArcGIS worden oa punten, lijnen en polygonen als aparte lagen gecatalogeerd. Deze aparte lagen kunnen naderhand eenvoudig als shapefile bewaard worden. De elementen worden ook hier in thema’s geclassificeerd, een classificatie die in ArcGIS zichtbaar wordt in het “Layer” attribuut. De classificatie is hier evenwel wat ruwer, er wordt enkel onderscheid gemaakt naar:

• 26 Omtrek van een zichtbaar, niet-gespecificeerd gebouw • 27 Omtrek van een groot aantal types gebouwen met een specifieke functie • 31 Hoog gebouw (hoger dan 50m) • 33 Op luchtopname onzichtbaar gebouw of constructie

De elementen in 3D-LINE zijn wel volledig driedimensionaal, informatie die we nodig hebben om de hoogte van gebouwen uit af te leiden.


Het belangrijkste probleem is dat zowel 3D-LINE als LANDUSE te maken hebben met een lange update-cyclus bij het NGI. Dat maakt dat ze niet altijd alle gebouwen omvatten, wat te zien is bij vergelijkingen van de gegevens met luchtfoto’s. Dat maakt ook dat de nauwkeurigheid van deze datasets kan verschillen afhankelijk van de kaartbladen die men bekijkt. Sommige gegevens kunnen zeer recent zijn, maar sommigen ook meerdere jaren oud. De gebouwen uit beide bestanden komen dan ook niet altijd overeen, waarbij het moeilijk in te schatten is welke van beide het meest correct de huidige realiteit benadert. De beste oplossing is dan ook beide bestanden te combineren wat zo veel mogelijk gebouwen omvat (die er in de realiteit ook zullen zijn), doch de verder voorgestelde methode introduceert hoe dan ook een beperkt aantal fouten bij de verwerking.


MOB/ARCNOISE 2004


Een bijkomend probleem van 3D-LINE is dan weer dat het in se een CAD-bestand is dat enkel lijnelementen bevat, waarvoor ArcGIS bij het openen van het bestand de gesloten polylijnen tracht te herkennen als polygonen. Voor de meerderheid van de elementen verloopt dit correct, maar als een gebouw in het CAD-bestand bestaat uit meerdere afzonderlijke polylijnen of niet perfect gesloten polylijnen wordt het gebouw niet of foutief als polygoon herkend en kan het ook niet gebruikt worden als gebouw. Meestal is dit het geval voor gebouwen met complexe vormen of een grote oppervlakte. Tenslotte is ook de hoogte-informatie in 3D-LINE niet altijd even correct. Bij de bepaling van de relatieve hoogte van de gebouwen verder blijkt dat in sommige gebiedsdelen grote percentages van de gebouwen ongewoon klein zijn of zelfs onder het grondniveau gelegen zijn. Navraag bij het NGI heeft ons geleerd dat er voor sommige kaartbladen waarvoor de gegevens relatief oud zijn inderdaad mogelijk problemen zijn met de hoogte-informatie. Dit heeft blijkbaar te maken met een in het verleden moeilijker kwaliteitscontrole op de hoogte van gebouwen. Sinds 2000 zou men overgeschakeld zijn op een andere methode die maakt dat de kwaliteit van de informatie beter zal zijn. Vermoedelijk zal men dus moeten wachten tot alle kaartbladen opnieuw herwerkt zijn om overal voldoende kwaliteit te hebben. Vervelend is dan wel dat op dit moment de kwaliteit van de gegevens – en dus ook de gewenste aanpak – kan verschillen van gebied tot gebied. Het is ook belangrijk op te merken dat de hoogte-informatie in 3D-LINE enkel weergegeven is voor de randen van het gebouw. Voor gebouwen met platte daken geeft dit geen probleem, voor de vele – vaak bewoonde – gebouwen met schuine daken wordt de hoogte dus onderschat. Oplossing voor dit probleem is het verhogen van alle residentiële gebouwen met een gemiddelde extra hoogte van 1.5m. Het laatste probleem is dat complexere gebouwen soms ook een open ruimte omsluiten en de polygoon er uitziet als een vlak met een opening erin. Een GIS-pakket kan met dergelijke gevallen zonder problemen overweg, maar software voor akoestische berekeningen heeft daar wel problemen mee. Dergelijke polygonen kunnen niet zonder meer in IMMI geïmporteerd worden, ze zouden nogal onvoorspelbare resultaten tot gevolg hebben. Een oplossing voor dit probleem wordt verder beschreven.


MOB/ARCNOISE 2004



LANDUSE

attribuut

REL_HEIGHT

GEBOUWEN

3D-line polygonen Digitaal Hoogtemodel

samenvoegen

selectieselectie

selectie niet

overlappende polygonen

Digitaal Hoogtemodel3D-line polylijnen

add X,Y,Z coördinates

(gem. absolute hoogte)

interpolate shape

(3D Analyst)

add X,Y,Z coördinates

(gem. terrein hoogte)

bereken relatieve hoogte

mean center

spatial join

- spatial join

- indeling gebouwtypes

in groepen en

kwaliteitscontrole

- spatial join

- rel. hoogte bewoonde

gebouwen +1.5m en

kwaliteitscontrole

- m to s

- verwijderen interne

openingen

- vereenvoudiging

De eerste opdracht bestaat erin om zo correct mogelijk de gebouwen samen te brengen, wat er gezien reeds aangehaalde tekortkomingen op neerkomt zo veel mogelijk gebouwen te behouden. Van de LANDUSE polygonen kunnen we vrij zeker zijn dat de aanwezige elementen een correcte geometrie hebben, daarom zullen we ook van deze dataset vertrekken. We selecteren uiteraard enkel de polygonen die betrekking hebben op een gebouw die volgende waarden hebben voor het attribuut “TYPE”: ST110, ST111, ST112, ST113, ST120, ST131, ST141, ST211, ST212, ST220, ST230, ST240, ST250, ST311, ST312, ST411, ST414, ST415, ST510, ST720, ST911, ST912, ST913, ST914 en ST940 – zie Bijlage 4. Om in LANDUSE ontbrekende polygonen evenwel aan te vullen, selecteren we ook alle herkende polygonen uit 3D-LINE die niet overlappen met polygonen in LANDUSE – om dubbele, licht verschillende of foutieve gebouwen te vermijden – en voegen deze toe aan de al weerhouden polygonen uit LANDUSE. De polygonen uit LANDUSE hebben allen een “TYPE” attribuut, polygonen uit 3D-LINE missen deze informatie. Eventueel kan de ontbrekende informatie aangevuld worden door het relatief beperkte aantal polygonen uit 3D-LINE – 777 gebouwen op een totaal van 24108 voor de 3 testgebieden samen – de attribuutwaarde te geven van de dichtstbijzijnde polygoon uit LANDUSE. In ArcGIS kunnen de daarvoor noodzakelijke bewerkingen eenvoudig uitgevoerd worden. Er worden op deze manier mogelijk fouten in de classificatie geïntroduceerd, maar gezien het aantal gebouwen in kwestie wel beperkt in omvang. Het enige alternatief is trouwens de gebouwen niet mee in beschouwing nemen wat een relatief gezien nog grotere fout tot gevolg zou hebben. Op basis van de aanwezige classificatie kunnen de gebouwen dan ingedeeld worden in groepen: residentiële (ST911), gevoelige (ST211, ST212, ST230) en andere gebouwen. Dit kan geregistreerd worden door het toevoegen van een extra attribuut. Het type ST913 is wat speciaal: het geeft gebouwen aan hoger dan 50m die zowel residentieel kunnen zijn als een andere functie hebben. Gezien het beperkte aantal kunnen deze waarschijnlijk wel afzonderlijk door een operator geverifieerd worden: in de 3 testgebieden was er geen enkel. Wel kan het nuttig zijn om een kwaliteitscontrole in te bouwen door gebouwen met een relatief grote oppervlakte (of hoogte, zie verder) te controleren op het al dan niet bewoond zijn om achteraf grote fouten in het tellen van het aantal inwoners te vermijden.


MOB/ARCNOISE 2004


Verder moet de relatieve hoogte van de gebouwen nog uit de gegevens gehaald worden. Daartoe maken we gebruik van de lijnenlaag van 3D-LINE, waarbij we voor elke lijn een gemiddelde relatieve hoogte zullen bepalen. De gemiddelde relatieve hoogte van een gebouw wordt bepaald als het verschil van de gemiddelde absolute hoogte – Z-coördinaat – op alle knooppunten van het lijnelement en de absolute hoogte van het terrein op diezelfde knooppunten. In de uitbreiding voor ArcGIS Xtools Pro – www.xtoolspro.com - bestaat een functie die de gemiddelde hoogte van features als attribuut toevoegt. De lijnelementen kunnen dan met behulp van de ArcGIS 3D Analyst extensie op een terreinmodel geprojecteerd worden en door de gemiddelde absolute hoogte van het nu op het grondniveau gelegen lijnelement opnieuw te bepalen, kan men op een eenvoudige manier het verschil tussen beide hoogtes berekenen en gelijkstellen aan de relatieve hoogte. Elk lijnelement in 3D-LINE moet aldus een extra attribuut krijgen met de relatieve hoogte. Door het samenvoegen van de polygonen en de lijnen met hoogte-informatie kan de relatieve hoogte overgedragen worden aan de gebouwpolygonen op basis van een afstandscriterium. Voor de meeste gebouwen zal er een 1-op-1 relatie zijn tussen polygonen en lijnen, voor een beperkt aantal zal de polygoon geen equivalent lijnelement vinden en de relatieve hoogte aannemen van het dichtstbijzijnde gebouw. Ook hier kunnen fouten geïntroduceerd worden, maar is het alternatief – het niet in beschouwing nemen van de gebouwen – een nog grotere fout. Voor de 3 testgebieden samen was dit het geval voor ongeveer 280 van de meer dan 24000 gebouwen. Het probleem met het schuine dak van – meestal bewoonde – gebouwen dat niet in rekening gebracht wordt kan aangepakt worden door alle woningen die eerder als residentieel geclassificeerd werden te verhogen met een extra 1.5m. Een eenvoudige herberekening van het attribuut “REL_HEIGHT” volstaat daartoe. Problemen met te kleine of negatieve hoogtes van gebouwen in bepaalde zones zoals we eerder gesignaleerd hebben, kunnen beperkt worden door bijvoorbeeld gebouwen kleiner dan 4m een relatieve hoogte te geven van 5m, maar er zijn ook andere voorstellen denkbaar. Dit soort operaties kan eenvoudig in ArcGIS uitgevoerd worden. Andere mogelijkheden kunnen ook en moeten eventueel afgestemd worden op de zone die men beschouwt. Veel hangt af van de nauwkeurigheid van de gegevens in 3D-LINE afkomstig van het NGI. Een kwaliteitscontrole op eerder extreme waarden voor de relatieve hoogte – zowel laag als hoog – is in ieder geval aangewezen. Complexe gebouwelementen die uit meerdere afzonderlijke onderdelen bestaan kunnen in ArcGIS eenvoudig gesplitst worden, het is dan ook best om dit vooraf aan de invoer in IMMI te doen om problemen te vermijden. Moeilijker is het verwijderen van interne openingen in het oppervlak van polygonen, wat ook moet gebeuren om de invoer in IMMI correct te laten verlopen. Een methode om dit te verhelpen is weergegeven in Bijlage 5. Het uiteindelijke eindpunt moet een dataset zijn met polygonen die de attributen bevat als weergegeven in § 2 van Bijlage 2., andere overtollige attributen mogen verwijderd worden. Tenslotte kan de digitalisatie van gebouwen soms vereenvoudigd worden: knooppunten van gebouwen zullen niet altijd een significante wijziging in de zijde van een gebouw voorstellen, zodat deze kunnen verwijderd worden zonder de vorm van het gebouw te wijzigen. Vereenvoudigingen op basis van een maximale afwijking van het origineel kunnen zowel in ArcGIS als in IMMI gebeuren. Bij de voorbereiding van de gegevens kan dit gebeuren met behulp van de “Generalize” Visual Basic functie die bijvoorbeeld op een manier gelijkaardig als in Bijlage 5. beschreven is kan toegepast worden. De maximale afwijking van het originele gebouw mag echter niet te groot worden om relatief grote fouten te vermijden. Een afwijking tot bijvoorbeeld 0.5m levert geen enkel probleem op. Deze vereenvoudigingen zullen het aantal vlakken en/of randen dat tijdens de berekeningen in beschouwing moeten worden genomen verminderen ivm reflecties en afscherming.


MOB/ARCNOISE 2004



• Het verwijderen van interne openingen van gebouwen leidt tot een wijziging van de grondoppervlakte van bepaalde gebouwen. Als in een latere fase inwonersaantallen moeten verdeeld worden over bewoonde gebouwen mbv statistische sectoren en ifv gebouwvolume – oppervlakte x relatieve hoogte – dan moet de oorspronkelijke oppervlakte van het gebouw gekend zijn om het gebouwvolume correct te bepalen, dwz voor het verwijderen van de interne openingen.

• Problemen met nauwkeurigheid van hoogte-informatie kunnen verschillen van zone tot zone, net als de ouderdom van de basisgegevens waarvoor grote tijdsintervallen bestaan voor het bijwerken ervan.


• De gebouwen zijn standaard reflecterend uitgevoerd (REFLECTION = TRUE) met een gerelateerde absorptiewaarde van 1 dB (ABSORPTION = 1).

3. Bodem


Om zo volledig mogelijke informatie te bekomen over bodemabsorptie of -reflectie op het terrein werd een beroep gedaan op 3 datasets: de bebouwde kernen uit Multinet (versie 2004), de indeling in bestemmingszones volgens het gewestplan (versie 2002) en opnieuw de LANDUSE-laag. Uiteindelijk is het de bedoeling om te komen tot een benaderende indeling van bodemtypes en daarbij de fout zo klein mogelijk te maken zonder de rekentijden sterk op te drijven. De bebouwde kernen uit de Multinet-databank bestaan uit polygonen die de woonkernen weergeven maar bevat verder weinig informatie nodig voor akoestische berekeningen in hun attributen. De bestemmingszones op het gewestplan zijn eveneens polygonen waarvoor een uitgebreide classificatie voorzien is in het attribuut “hoofdcode” waarvan de waarden verklaard worden in het bijhorende bestand “gpcodes_2001.xls”. Beide datasets bevatten in essentie relatief grote polygoonoppervlakken die het algemeen bodemgebruik bij benadering beschrijven. Beiden werd aangeleverd als ESRI shapefile. LANDUSE bevat eveneens nuttige informatie over bodemgebruik, is veel nauwkeuriger maar daardoor ook veel meer gefragmenteerd in kleine oppervlakken. Uit deze dataset zullen we enkel informatie halen om zones aan te duiden die we met grote zekerheid kunnen catalogeren als reflecterend. Daarvoor maken we opnieuw gebruik van het attribuut “TYPE” alsook van het attribuut “LEV” dat het relatieve niveau tov de grond aangeeft. LANDUSE heeft in zijn attribuutwaarden ook informatie over respectievelijk de oppervlakte – “AREA” – en omtrek – “PERIMETER” – van de polygonen.


LANDUSE is zoals gezegd de meest nauwkeurige dataset maar dat heeft ook zijn nadelen. Vaak omvat het grote aantallen kleine polygonen die helemaal niet relevant zijn voor een akoestische berekening maar wel veel rekentijd in beslag zullen nemen. Het in beschouwing nemen van de bodem in NMPB / XP S 31-133 is immers zo opgevat dat voor elke combinatie van geluidsbron en waarnemingspunt een gemiddelde G wordt bepaald voor de volledige overdrachtsweg. Hoe meer verschillende bodemelementen er tussen bron en ontvanger liggen, des te meer werk heeft de software dan ook om deze parameter te bepalen. Verderop zullen dan ook een aantal voorstellen gedaan worden om de gegevens te vereenvoudigen. De bebouwde kernen uit Multinet zijn dan weer niet altijd even nauwkeurig om woonkernen correct weer te geven. Uit een vergelijking met luchtfoto’s is gebleken dat sommige woonkernen zelfs “vergeten” worden, één van de redenen waarom ook het gewestplan werd gebruikt om deze zones te vervolledigen. Verder zal de combinatie van beiden gebruikt worden met een “gemiddelde” bodemfactor om de realiteit te benaderen.


MOB/ARCNOISE 2004


Eén van de mogelijkheden om vereenvoudigingen door te voeren in de gegevens is het samenvoegen van aanliggende polygonen met dezelfde bodemfactor, dat betekent immers minder tijd nodig voor het bepalen van de gemiddelde G voor de overdrachtsweg tussen bron en ontvanger. Dit heeft echter ook het nadeel dat, los van interne openingen in polygonen die al in de originele datasets aanwezig kunnen zijn, ook bijkomende interne openingen gecreëerd worden die in het geval van bodemelementen grote oppervlaktes kunnen vertegenwoordigen. Ook hier moet dit probleem aangepakt worden, omdat IMMI bij invoer deze polygonen niet altijd correct zal invoeren.


Bebouwde kernen Multinet 2004 Gewestplan 2002 LANDUSE

selectie

- selectie

- vereenvoudiging

- verwijderen elementen

met interne openingen

- m to s

-union

- dissolve

- m to s

samenvoegen

attributen

G = 0.5, PRIO = 1

attributen

G = 0.2, PRIO = 2

verwijderen interne

openingen

BODEM

Een perfecte gegevensinvoer voor de bodemfactor is sowieso praktisch onmogelijk en voor de toepassing die ontwikkeld wordt helemaal niet aangewezen. Daarom werd van bij de start geopteerd voor 3 klassen van bodemabsorptie of -reflectie:

• een achtergrondwaarde van G = 1 voor absorberend terrein waar er geen aanwijzingen bestaan voor een meer reflecterend bodemtype,

• een gemiddelde waarde van G = 0.5 voor gemengde zones waar delen van het terrein absorberend zullen zijn en andere delen reflecterend,

• een waarde van G = 0.2 voor zones met een relatief grote zekerheid dat het terrein op die plaats reflecterend is.

De achtergrondwaarde G = 1 is een waarde die in IMMI zelf moet ingesteld worden en waar we dus verder geen gegevens over hoeven te verzamelen. Dat moet wel gebeuren voor beide andere waarden. Daarbij zullen we polygonen bekomen voor beide waarden die, omdat ze van verschillende datasets afkomstig zullen zijn, elkaar ook kunnen overlappen. Daartoe kunnen we een prioriteit instellen, waarbij we de hoogste prioriteit zullen geven aan reflecterende bodemoppervlakken (G = 0.2, PRIO = 2) boven meer gemengde zones (G = 0.5, PRIO = 1).


MOB/ARCNOISE 2004


Om de reflecterende bodemoppervlakken te bekomen vertrekken we van LANDUSE waaruit we een selectie aan polygonen maken van de waarden GS200, GS300, HY112, HY120, HY140, HY240 en HY250 voor het “TYPE” attribuut en waarvoor het attribuut “LEV” tegelijkertijd gelijk is aan 0, ttz op grondniveau. In essentie gaat het om gladde reflecterende oppervlakken, bv. grote parkeergelegenheden en verschillende types van wateroppervlakken. De classificatie van het “TYPE” attribuut is verklaard in Bijlage 4. Alle geselecteerde polygonen krijgen aldus een bijkomend attribuut “G” met waarde 0.2 en een attribuut “PRIO” met waarde 2. Best kunnen ook complexe polygonen – met meerdere delen – al gesplitst worden wat in de ArcGIS omgeving eenvoudig kan. Deze selectie bevat evenwel nog heel veel polygonen die geen of slechts een kleine invloed zullen hebben op de berekende geluidsniveaus. Immers, voor de volledige overdrachtsweg wordt een gemiddelde G-waarde berekend zodat kleine elementen ook slechts een kleine invloed zullen hebben op dit gemiddelde. Deze kleine elementen kunnen dan ook best verwijderd worden omdat ze nauwelijks een bijdrage leveren aan het eindresultaat maar wel een duidelijke impact kunnen hebben op de rekentijd. Daardoor kunnen elementen met een oppervlakte kleiner dan 500m² beter verwijderd worden. Ook elementen met een voldoende grote oppervlakte maar een relatief kleine breedte, bv. lange smalle beekjes, zijn om dezelfde reden eerder overtollige ballast. Elementen met een gemiddelde breedte kleiner dan 10m (verhouding tussen oppervlakte – “AREA” – en omtrek – “PERIMETER” – is kleiner dan 5) worden dan ook beter verwijderd. Voor het gemengde bodemtype is een samenvoegen van gegevens over de bebouwde kernen en uit het gewestplan noodzakelijk. Uit het gewestplan wordt daarvoor volgende selectie gemaakt voor het attribuut “hoofdcode”: 0100-0101, 0110-0116, 0200, 0210, 0300-0301, 0330, 1000-1002, 1010-1015, 1030-1033, 1040-1041, 1044-1048, 1100, 1110-1114. Dit komt in hoofdzaak overeen met woongebieden en zones van industriële of commerciële aard. Daaraan worden de polygonen van de bebouwde kernen toegevoegd. Polygonen uit beide datasets kunnen uiteraard overlappen, daarom kunnen alle polygonen best samengevoegd worden tot één geheel en daarna de complexe polygoon weer gesplitst in zijn verschillende delen. Bemerk dat dit een risico inhoudt op het creëren van interne openingen. De uiteindelijke polygonen krijgen dan een bijkomend attribuut “G” met waarde 0.5 en een attribuut “PRIO” met waarde 1. Voor het aanpakken van interne openingen bevelen we een gediversifieerde aanpak aan voor oppervlakken van reflecterende en gemengde aard afzonderlijk, rekening houdend met hun karakteristieken. Voor de polygonen van reflecterende aard – afkomstig uit LANDUSE – houdt het toepassen van de methode zoals voor gebouwen nogal wat risico’s in. In LANDUSE zijn immers heel wat voorbeelden te vinden van polygonen met een relatief kleine oppervlakte – maar niet klein genoeg om in eerste instantie te verwaarlozen – die wel veel grotere interne openingen hebben. Een typisch voorbeeld is een groot en gesloten grachtenstelsel in landelijke gebieden. Het toepassen van de methode in Bijlage 5. houdt in dat de volledige oppervlakte inclusief de interne openingen als reflecterend zou worden aanzien, wat grote fouten met zich mee zou brengen. Voor reflecterende oppervlakken verkiezen we dan ook om polygonen met interne openingen te verwijderen uit de gegevens, eerder dan de bodemfactor mogelijk serieus te overschatten. Om dit te automatiseren kan een licht gewijzigde variant van de eerder vermelde methode toegepast worden. Voor gemengde bodemoppervlakken is deze werkwijze niet haalbaar omdat het vaak over polygonen zal gaan met veel grotere afmetingen. Hier lijkt de methode zoals die toegepast werd voor gebouwen meer haalbaar, al kunnen ook hier grote interne openingen een G-waarde krijgen van 0.5 waar dat eigenlijk 1 zou moeten zijn. Eventueel kan hier manueel ingegrepen worden door grote polygonen met grote interne openingen doormidden te snijden – en dus in één of meerdere elementen te splitsen – zodat de interne opening wel een “opening” blijft, maar niet langer “intern” is. ArcGIS bevat de nodige functionaliteiten om dit op een eenvoudige manier te doen, alleen blijft het arbeidsintensiever omdat de openingen getraceerd moeten worden en enkele manuele bewerkingen nodig zijn, die eveneens beknopt beschreven zijn in Bijlage 5.


MOB/ARCNOISE 2004



• Voor de achtergrondwaarde G = 1 werden zoals gezegd geen elementen gedefinieerd, deze parameter moet in IMMI zelf ingesteld worden. Voor automatische berekeningen met de rekenmodule gebeurt dit zonder dat een ingreep van de gebruiker nodig is.



4. Wegen

In andere delen van dit rapport werd voornamelijk aangegeven welke wijzigingen de omschakeling van de berekeningsmethode van NMPB / XP S 31-133 naar RMW / SRM II tot gevolg had zonder de oude tekst te wijzigen. Om in dit hoofdstuk over de voorbereiding van een dataset geen verwarring te zaaien, werd het hoofdstuk echter grotendeels herschreven. Onder meer voor de types voertuigen wordt van 2 categoriën naar 3 categoriën overgeschakeld.


Het belangrijkste basisgegeven is uiteraard de geometrie van de wegen zelf. Daarvoor werd het ontwikkelde routesysteem gebruikt dat voor Vlaanderen alle autosnelwegen en gewestwegen omvat. Omdat er in de op dat moment in gebruik zijnde versie toch een aantal serieuze onnauwkeurigheden gevonden werden op het vlak van geometrie werd een nieuwere versie gebruikt die in ontwikkeling was maar qua geometrie voor akoestische berekeningen veel beter geschikt. Het routesysteem bestaat uit lijnelementen waarbij de knooppunten naast de gewone X- en Y-coördinaten ook een bijkomende M-coördinaat hebben die het kilometerpunt aangeven langs de weg. De wegen hebben ook een unieke identificatie zodat elke plaats langs de wegen op ondubbelzinnige wijze kan voorgesteld worden door het identificatienummer van de weg en het kilometerpunt. Elke rijrichting wordt voorgesteld door een afzonderlijk lijnelement – er is geen informatie over de afzonderlijke rijstroken – en voor gewestwegen zijn deze in veel gevallen identiek zodat het in de GIS-omgeving lijkt alsof er slechts één element gelegen is. De belangrijkste attributen van het routesysteem zijn de volgende:

• WEGTYPE: type A, R of N • WEGNUMMER: volgens nummering van de wegen • WEGINDEX: verdere onderverdeling van de wegen • TELLING: geeft informatie over de rijrichting • IDENT8: is het resultaat van het samenvoegen van alle voorgaande attributen tot een enkele string en

bijgevolg een unieke combinatie De eigenschappen van het routesysteem maken het tot een heel krachtig instrument om gegevens over wegen op te slaan en te beheren. De verschillende eigenschappen van de weg kunnen immers in tabellen als afzonderlijke databank opgeslagen en ook beheerd worden. Voorwaarde is wel dat met de gegevens ook de unieke identificatie van de wegen en begin- en eindpunten van de wegsectie waarvoor deze eigenschap geldig is mee opgeslagen worden. Op het moment dat een dataset moet aangemaakt worden, is gewoon een GIS-bewerking nodig om tot een resultaat te komen dat bruikbaar is. Jammer genoeg blijkt de informatie niet voldoende op die manier beschikbaar. Informatie over wegdektypes hebben we gebruikt om te koppelen aan het routesysteem. We hebben deze gegevens gekregen als een lijnenbestand op basis van het oude routesysteem, maar deze zelf opnieuw gekoppeld aan het nieuwe routesysteem. De databank over wegdektypes bevat een beperkte onderverdeling aan wegdektypes: asfalt (“c_verhcode” = A), beton (“c_verhcode” = B) en plaveien of elementverhardingen (“c_verhcode” = E).


MOB/ARCNOISE 2004


Omdat er geen andere adequate gegevens beschikbaar waren over de snelheid van voertuigen hebben we gegevens gebruikt over de ligging van de bebouwde kernen uit Multinet om informatie over de gemiddelde snelheid van voertuigen uit af te leiden. Op basis van de dataset wordt immers een onderscheid gemaakt tussen wegen gelegen in en buiten de bebouwde kom. Tenslotte hebben we gegevens verkregen van het Verkeerscentrum over het aantal voertuigen dat over de wegen rijdt. De bewuste shapefile is afkomstig van verkeersmodellen die uitgaan van een geometrisch sterk vereenvoudigd netwerk dat niet overeenkomt met het routesysteem en er ook niet op eenvoudige manier aan te koppelen is. Verder bevatten de attributen informatie over het aantal lichte en zware voertuigen per uur voor de ochtend- en avondspits en de normale dagperiode – dus niet voor dag-, avond- en nachtperiode – en de gemiddelde snelheid van voertuigen voor de 3 vernoemde periodes van de dag. Latere bijkomende gegevens hadden de verdeling van de voertuigtypes over licht, middelzwaar en zwaar (volgens RMW / SRM II) en waren wel ingedeeld volgens de dag-, avond- en nachtperiode op basis van de oorspronkelijke uurwaarden. Deze gegevens waren correct maar konden evenmin gekoppeld worden aan het routesysteem omdat de nodige informatie in tabelvorm daartoe ontbrak.


Een eerste probleem betreft de gegevens ivm de wegdektypes, de indeling is helemaal niet gedetailleerd en het was moeilijk om een waarde voor de wegdekcorrectie te bepalen. Immers, de categorieën asfalt en beton omvatten potentieel sterk verschillende wegdektypes met grote verschillen wat betreft hun akoestische prestaties. Het ontbreken van een meer gedetailleerde classificatie speelt ons hier parten. Verder is ook gebleken dat de originele dataset voor de wegdektypes voor een beperkte aantal delen van wegen geen wegdekgegevens bevat. De GIS-bewerking voor het koppelen van de datatabel met het routesysteem zorgt er echter voor dat daardoor die delen van de weg verloren gaan. Het recupereren van deze delen achteraf is omslachtig maar mogelijk. Beter is het ervoor te zorgen dat de datatabel voor het volledige wegennetwerk gegevens bevat. Als voor bepaalde delen van de wegen geen informatie voorhanden is, kan men beter op het niveau van de datatabel een standaardwaarde aangeven dan achteraf heel wat extra bewerkingen te moeten doen om dit recht te zetten. Voor de berekening volgens RMW / SRM II is niet langer een wegdekcorrectie in dB nodig maar wordt gewerkt met wegdektypes zoals deze weergegeven zijn in § 4 van Bijlage 2. Er is dus een databank noodzakelijk die aan het routesysteem kan gekoppeld worden en aangeeft op welke locaties in het Vlaamse wegennetwerk welk gedefinieerde (of benaderende) wegdektype gelegen is. Daarvoor is de huidige beschikbare informatie ontoereikend. Andere problemen situeren zich voornamelijk rond de verkeersgegevens. De koppeling van de verkeersgegevens met het routesysteem blijkt op zich al een probleem te zijn. De verkeersmodellen van het Verkeerscentrum maken gebruik van een sterk vereenvoudigde geometrie die helemaal niet geschikt is voor akoestische berekeningen, bovendien blijkt een rechtstreeks verband tussen beide geometrieën niet zo eenvoudig te implementeren. Voor de testgebieden werd de overdracht van de verkeersgegevens naar het routesysteem manueel uitgevoerd, maar voor een volledige bedekking van Vlaanderen is dit praktisch niet mogelijk. Tenslotte hebben we ook opgemerkt dat de verkeersmodellen voor een beperkt aantal gewestwegen geen informatie bevatten. Wat betreft de indeling in referentieperiodes hebben we uiteindelijk gegevens gekregen die voldoen aan de criteria voor strategische geluidskartering: dag-, avond- en nachtperiode. Voor de vergelijking van de berekeningen met de metingen werd gebruik gemaakt van de telgegevens tijdens de metingen zelf door AWV. Tenslotte is de informatie over snelheid van de voertuigen ook beperkt. De geleverde verkeersgegevens bevatten ook informatie over gemiddelde snelheid maar deze is niet uitgesplitst voor lichte en zware voertuigen. Aangezien het over verkeersmodellen gaat lijkt deze trouwens ook vaak gebruik te maken van de snelheidslimieten. Voor de testgebieden werd de snelheid geschat op basis van de snelheidslimieten, de ligging van bebouwde kernen en enkele aannames. De realiteit zal echter niet altijd zo eenvoudig zijn, voornamelijk voor gewestwegen en ringwegen waar een snelheidsbeperking is ingevoerd, zodat ook daar eigenlijk meer accurate informatie nodig is.


MOB/ARCNOISE 2004



RoutesysteemVerkeersgegevens

add route events

selectie

Voertuigsnelheden

Wegverharding

overlay route events

Digitaal HoogtemodelBRUGGEN

- m to s

- aanpassen modellering

wegen rond bruggen

attribuut

REL_HEIGHT (=0)

WEGEN

verificatie ligging,

modellering

attributen

Q_XVEHIC_Y,

V_XVEHIC_Y,

SURF_NUM

Om te beginnen wordt het routesysteem gekoppeld met zijn “events”, waarbij we er van uitgaan dat er zowel voor de verkeersgegevens, de voertuigsnelheden en de wegverhardingen datatabellen beschikbaar zijn die kunnen gekoppeld worden aan het routesysteem. Daartoe moeten de tabellen naast een kolom met de specifieke wegeigenschap ook 3 bijkomende kolommen bevatten met respectievelijk een route identificatie nummer en een start- en eindkilometerpunt waartussen de bewuste waarde voor de eigenschap geldig is. De tabel met de verkeersgegevens bevat dan de – jaargemiddelde – hoeveelheid voertuigen voor lichte, middelzware en zware voertuigen en de dag-, avond- en nachtperiode afzonderlijk. Datzelfde geldt voor een tabel met voertuigsnelheden die kan opgesteld worden op basis van de snelheidsbeperkingen over het wegennetwerk of effectieve metingen. Informatie over de wegverharding moet afgestemd zijn op de beschikbare classificatie voor RMW / SRM II zoals weergegeven in § 4 van Bijlage 2. Deze 3 tabellen kunnen dan in ArcGIS samengevoegd worden tot een globale tabel waarin de verdere segmentatie automatisch door de software beheerd wordt. Deze globale tabel zal uiteindelijk gekoppeld worden aan het routesysteem waardoor een “event layer” ontstaat waarbij het routesysteem opgesplitst is in deellijnen met elk zijn eigenschappen afkomstig uit de datatabellen. Het is van groot belang dat de oorspronkelijke tabellen daarbij het volledige wegennetwerk (of het deel ervan dat relevant is voor strategische geluidskartering) dekken, anders gaan bij deze bewerking delen van het netwerk verloren die niet in rekening zullen gebracht worden bij de berekening. Op- en afritten van autosnelwegen zullen in veel gevallen nauwelijks bijdragen tot het eindresultaat, hooguit plaatselijk, en kunnen dan ook meestal verwijderd worden. Deze zijwegen kunnen op relatief eenvoudige manier uit de dataset gehaald worden door elementen te selecteren die voor het attribuut “WEGINDEX” een waarde hebben die niet gelijk is aan “000”.


MOB/ARCNOISE 2004


Ter hoogte van brugelementen moet aandacht besteed worden aan de manier waarop de knooppunten van het wegelement gemodelleerd zijn. Bij het importeren van de geometrie in IMMI krijgen de knooppunten immers een relatieve hoogte 0 ten opzichte van het terreinmodel. Een wegelement dat over een brug heen gaat moet echter op dezelfde hoogte liggen als de brug en niet langer het terreinmodel volgen. Daartoe moet ervoor gezorgd worden dat de bewuste weg ter hoogte van de brug exact dezelfde modellering krijgt als het brugelement in kwestie, namelijk een knooppunt aan het begin van de brug, een knooppunt aan het eind van de brug en geen enkel knooppunt tussen beiden. Wegen die gesplitst zijn in afzonderlijke elementen in het midden van de brug zullen manueel samengevoegd moeten worden met aandacht voor de respectievelijke attributen die moeten overeenkomen. Het zal een arbeidsintensieve bezigheid zijn om alle bruggen te overlopen en de modellering van de wegelementen manueel aan te passen. Omdat het Digitaal Hoogtemodel ter hoogte van bruggen soms onvoorspelbare resultaten geeft ter hoogte van bruggen is het eveneens aangewezen om voor wegen die onder bruggen door gaan iets vergelijkbaars te doen, namelijk een knooppunt modelleren net voor en na het brugoppervlak en geen knooppunten toe te laten tussen beiden. De wegen krijgen verder nog een laatste bijkomend attribuut / waarde overeenkomstig met § 4 van Bijlage 2.:

• REL_HEIGHT: in principe krijgt dit attribuut voor alle elementen waarde 0, dwz liggend op het terrein In het algemeen is het goed om na te gaan of de modellering van de verschillende datasets, en de wegen en het terreinmodel in het bijzonder, goed op mekaar afgestemd zijn. Daarom is het aan te bevelen om het terreinmodel, de wegen, bruggen en geluidsschermen vooraf aan het opstarten van de rekenmodule samen te stellen en mogelijke problemen op te sporen en te verhelpen. Dit kan onder meer door de geometrie van deze datasets handmatig te importeren in IMMI met behulp van de ArcView interface. De manier waarop deze elementen dan samengesteld zullen worden kan op dat moment meteen geverifieerd worden met behulp van bijvoorbeeld de 3D viewer of de functie om een doorsnede van het terreinprofiel te bekijken over een lange weg. IMMI zal trouwens sowieso zelf ook enkele testen uitvoeren op conflicten in de geometrie. De ArcGIS 3D Analyst extensie zal vergelijkbare functionaliteiten hebben. De gemiddelde snelheid van voertuigen kan in het ideale geval best samen met de verkeersgegevens rechtstreeks aan het routesysteem gekoppeld worden. In de vooropgestelde methode zijn we er vanuit gegaan dat deze in de toekomst wel beschikbaar zullen zijn, voor de testgebieden hebben we een alternatieve manier toegepast. Daartoe moeten de wegen gescheiden worden afhankelijk van het feit of deze al dan niet in een bebouwde kern liggen. Om deze bewerkingen uit te voeren zijn genoeg functionaliteiten voorzien in ArcGIS. Alle wegelementen met “WEGTYPE” A of R krijgen dan een snelheid van 120 km/u voor lichte voertuigen en 90 km/u voor middelzware en zware voertuigen. Wegelementen met “WEGTYPE” N krijgen voor alle categorieën voertuigen een snelheid van 50 km/u indien ze in een bebouwde kern gelegen zijn en een gemiddelde waarde van 80 km/u indien ze erbuiten liggen. De vermelde snelheden moeten telkens aangegeven worden voor de 3 referentieperiodes maar werden hier identiek verondersteld. Na het toevoegen van deze attributen en het toekennen van de waarden kunnen alle wegelementen opnieuw samengevoegd worden in een zelfde dataset. De werkelijke snelheid of zelfs de snelheidslimieten kunnen van de aangenomen waarden echter sterk afwijken, meer in het bijzonder op gewestwegen en ringwegen waar een snelheidsbeperking is ingevoerd. De vooropgestelde methode, met inbegrip van de bijkomend benodigde gegevens, dient dus zeker en vast de voorkeur te krijgen.


• De grootste problemen zijn het ontbreken van een voldoende accurate classificatie voor wegdektypes, de onmogelijkheid om de huidige beschikbare gegevens te koppelen aan het routesysteem en het gebrek aan voldoende nauwkeurige informatie over voertuigsnelheden. Er is vanuitgegaan dat deze problemen kunnen opgelost worden, in het andere geval zal er heel wat extra manueel werk nodig zijn voor het voorbereiden van de datasets.




MOB/ARCNOISE 2004


5. Geluidsschermen


Voor de geluidsschermen werd vertrokken van een – mogelijke verouderde – shapefile uit ADA. Bij AWV bestond er een overzicht van geluidsschermen onder de vorm van papieren fiches die uiteindelijk in een Excel-bestand ingebracht werden. De koppeling met het routesysteem was echter niet vanzelfsprekend zodat uiteindelijk het eerder vermelde databestand gebruikt werd. Het bestand is duidelijk ontstaan uit het koppelen van een datatabel met het routesysteem en bevat onder meer volgende attributen die van nut kunnen zijn:

• “hoogte”: is de hoogte-informatie, blijkbaar in cm • “vorm”: is het type van geluidsscherm, zoals een geluidwerende wal, caisson, één- of meerdelige

panelen • “akoestisch”: verdeelt geluidsschermen in reflecterend, half-absorberend en absorberend

Verder gaat het vooral om informatie over de weg waarlangs ze gelegen zijn e.d. Het DHM is vooral van nut om de modellering van de geluidsschermen af te stemmen op de afscherming die reeds in het terreinmodel vervat is.


De originele dataset heeft nogal wat te lijden onder onjuistheden: de hoogte van de geluidsschermen blijkt niet altijd te kloppen – sommige schermen hebben zelfs hoogte 0 – en de locatie is al helemaal een probleem. De dataset bevat wel informatie over een minimum- en maximumafstand tot de weg maar deze informatie is bij het totstandkomen van de shapefile duidelijk helemaal niet gebruikt. Al moet gezegd dat de situatie ter plaatse het ook helemaal niet eenvoudig maakt om geluidsschermen op deze manier te beschrijven, dat hebben we op een aantal plaatsen in de testgebieden zelf ook duidelijk gemerkt. Voor eenvoudige situaties klopt het bestand soms nog relatief goed, met uitzondering misschien van de afstand tot de weg waarvoor een standaard waarde werd gebruikt voor alle schermen. Problemen duiken altijd op waar schermen zich in de buurt van open afritten bevinden of waar effectieve schermen gecombineerd worden met aarden wallen of natuurlijke reliëfverschillen. Voor de testgebieden hebben we een heel aantal geluidsschermen ter plaatse bekeken en vastgesteld dat de situatie ter plaatse soms heel complex kan zijn, wat betekent dat het aanmaken van een goed databestand voor geluidsschermen arbeidsintensief zal zijn en bovendien wel wat kennis van zaken veronderstelt.


MOB/ARCNOISE 2004



Geluidsschermen ADA Digitaal Hoogtemodel

- selectie

- verificatie hoogte,

ligging, modellering,

absorptiewaarde

attributen

REL_HEIGHT,

ABSORPTION

GELUIDSSCHERMEN BRUGGEN

eventueel deel vh scherm

overbrengen naar brugelement

verificatie ligging, modellering

De verwerking komt erop neer dat de aanwezige data moeten geverifieerd, gecorrigeerd en eventueel aangevuld worden. Het uiteindelijke eindresultaat moet een shapefile met lijnen zijn met 2 attributen: de relatieve hoogte van het scherm “REL_HEIGHT” en de absorptiewaarde “ABSORPTION” in dB. Geluidsschermen met de waarde “GELUIDWERENDE WAL” voor het attribuut “vorm” zullen bijna altijd uit de originele dataset verwijderd mogen worden. We hebben gemerkt dat deze aarden wallen, als ze ten tijde van het opstellen van het DHM al aanwezig waren, ook in het DHM beschouwd zijn. Het heeft geen zin en is zelfs foutief om deze dubbel te beschouwen. De informatie in het DHM is trouwens veel nauwkeuriger dan een databestand met afzonderlijke geluidsschermen ooit kan zijn. Enkel geluidsschermen die bij het opmeten van het DHM nog niet aanwezig waren moeten toegevoegd worden, waarbij men zich kan afvragen of men daartoe niet beter het terreinmodel plaatselijk manueel aanpast. Bij het manueel verwerken van de andere geluidsschermen moet aan volgende elementen aandacht besteed worden:

• De relatieve hoogte van het scherm moet geverifieerd worden, deze blijkt niet altijd te kloppen. De waarde in de originele dataset moet trouwens ook nog omgezet worden naar meters.

• De modellering van de knooppunten is ook van belang, daarvoor moet men begrijpen hoe het scherm in IMMI voorgesteld wordt: de relatieve hoogte wordt daar immers ingesteld enkel op de knooppunten van het scherm, de delen ertussen ontstaan gewoon door lineaire interpolatie tussen de knooppunten. Men moet zich hiervan bewust zijn als men de modellering van de knooppunten verifieert en eventueel wijzigt.

• Mogelijk moet de modellering van het scherm daarbij ook afgestemd worden op het terreinmodel voor de betreffende locatie, bv. voor de aansluiting van effectieve geluidsschermen met aarden wallen.

• De afstand tot de weg is ook van belang, waarbij specifieke aandacht moet besteed worden aan het modelleren van geluidsschermen in de buurt van open afritten van autosnelwegen.


MOB/ARCNOISE 2004


• Geluidsschermen die voor het attribuut “akoestisch” de waarde “REFLECTEREND” hebben kan men een absorptiewaarde van 1 dB geven, voor de waarde “ABSORBEREND” kan men een absorptiewaarde aannemen, voor de testgebieden hebben we een zeer voorzichtige waarde gebruikt van 3 dB, rekening houdend met de staat van bepaalde schermen en onnauwkeurigheden in de gegevens. Het is zeker dat de werkelijke waarde in de meeste gevallen hoger zal liggen en indien meer gedetailleerde gegevens beschikbaar zijn, kunnen deze uiteraard gebruikt worden. De waarde “HALF-ABSORBEREND” wordt in principe enkel gebruikt voor aarden wallen die dus in normale omstandigheden al uit de dataset verwijderd zijn.

• Nog complexer wordt het als er geluidsschermen zijn die zich op bruggen bevinden, aangezien wanden per definitie verticaal tot op grondniveau doorlopen. Als men geen rekening moet houden met geluid dat onder de brug doorgaat of er geen geluidsbron onder de brug ligt, kan men een geluidsscherm nog op de gewone, hierboven beschreven manier modelleren. Het is echter correcter om het geluidsscherm als een eigenschap van de brug mee te geven – zie § 6. – en indien het geluidsscherm verder doorloopt, bijkomende geluidsschermen te definiëren die aansluiten op het geluidsscherm dat op de brug staat. Het spreekt voor zich dat de combinatie van geluidsschermen met bruggen nog meer manueel werk zal vragen.


• In het voorgaande is duidelijk geworden dat de gegevens voor geluidsschermen zeker niet ideaal zijn. Een datatabel met alle gegevens die aan het routesysteem kan gekoppeld worden zal nooit de meer complexe situaties in de realiteit kunnen beschrijven, een dergelijke tabel zal eerder het resultaat zijn van een eerste inventarisatie op basis waarvan een lijnenbestand met de correcte ligging van de geluidsschermen kan ontstaan door manuele aanpassingen.


• De schermen zijn standaard reflecterend uitgevoerd (REFLECTION = TRUE) met dezelfde absorptiewaarde aan beide zijden (REFL_SIDE = 2). Deze laatste eigenschap zal niet altijd correct zijn maar de invloed ervan op de berekende geluidsniveaus is miniem en altijd plaatselijk, het vereenvoudigt wel de verwerking.

6. Bruggen


Informatie over de ligging van brugoppervlakken (voor wegen) kan ook hier uit LANDUSE gehaald worden. Daarvoor maken we opnieuw gebruik van de attributen “TYPE” en “LEV”. Omdat we hier informatie willen over bruggen die per definitie niet op grondniveau liggen zullen we een selectie maken voor het attribuut “LEV” waarvoor de waarde niet gelijk is aan 0. Verder wordt ook gebruik gemaakt van het routesysteem omdat deze informatie bevat over de ligging van de as van de weg, zodat de bruggen gecentreerd zullen worden rond de as van deze weg, zelfs als het routesysteem niet altijd perfect overeenstemt met de wegdekoppervlakken in LANDUSE.


De informatie in het routesysteem en LANDUSE komt niet altijd perfect overeen. In uitzonderlijke gevallen is het lijnelement dat de weg voorstelt in het routesysteem naast het wegdekoppervlak in LANDUSE gelegen, wat problemen stelt voor de verwerking. Verder is ook de combinatie van de polygoon uit LANDUSE met het terreinmodel soms een probleem: als het brugdek te beperkt gemodelleerd is, zal het de overspanning tussen de verhoogde elementen in het terreinmodel niet halen en zal de brug niet correct geplaatst kunnen worden. Bij de verwerking worden deze problemen aangepakt.


MOB/ARCNOISE 2004


Ook de modellering van de bruggen als lijnelementen zal soms bijgestuurd moeten worden om te vermijden dat het brugelement eerder het terrein zal volgen dan boven het terrein te zweven op de plaatsen waar het moet. Verder bevatten de basisgegevens geen informatie over eventuele geluidsschermen die zich op bruggen zouden bevinden, hoewel het in sommige gevallen wenselijk is om deze toe te voegen zoals in § 5. opgemerkt werd. Deze informatie zal dan ook manueel moeten toegevoegd worden.


Routesysteem GELUIDSSCHERMEN

- m to s

- selectie

- verwijdering

overtollige en valse

bruggen

- verificatie ligging,

modellering

attributen

REL_HEIGHT (=0),

BREITE

BRUGGEN

eventueel deel vh scherm

overbrengen naar brugelement

LANDUSE Digitaal Hoogtemodel

- selectie

- dissolve

- m to s

- buffer 10m

clip

selectie

verificatie ligging, modellering

attributen

HLSW_LI, HLSW_RE

WEGEN

Informatie over de bruggen halen we in eerste instantie uit LANDUSE: daar maken we een selectie van alle elementen met waarden “RO112” – wegoppervlak – en “GS300” – steriele grond, hier gebruikt voor eventuele zij- of tussenbermen op de brug – voor het attribuut “TYPE” die voor het attribuut “LEV” een waarde hebben die niet gelijk is aan 0. In ArcGIS kunnen dan aanliggende polygonen samengevoegd worden tot een volledig brugoppervlak: het wegdek met de bijhorende zijbermen. Om problemen te vermijden met te kleine of uit de as van de weg liggende brugoppervlakken, maken we dan een buffer rond de resulterende polygonen op een afstand van 10m. Daardoor worden een iets ruimere marge genomen op de bruggen en zal het resultaat waarschijnlijk steeds correct zijn, we hebben in de testgebieden in ieder geval geen problemen meer kunnen vinden.


MOB/ARCNOISE 2004


Het uiteindelijke doel is om de bruggen te modelleren als lijnelementen, gecentreerd rond de as van de weg, die een bepaalde breedte zullen hebben. Daarbij gebruiken we de wegen zoals we die in IMMI zullen importeren, afkomstig van het routesysteem. Het eenvoudigst om de lijnelementen te bekomen is die lijnen te selecteren – en te snijden – die in de polygonen gelegen zijn die de brugoppervlakken voorstellen. Daarbij dient men gebruik te maken van het originele, niet-bewerkte routesysteem met alle wegen waarvoor gerekend zal worden. Bemerk dat brugelementen die niet van belang zijn omdat ze geen weg kruisen die in het routesysteem aanwezig is ook niet verder in beschouwing worden genomen door deze werkwijze. Merk wel op dat de werkwijze impliceert dat niet alleen de wegen die op de brug gelegen zijn als lijnelement weerhouden zullen worden, maar ook de wegen die bijvoorbeeld onder de brug door zouden gaan in de dwarsrichting. Na het bekomen van de lijnelementen is het aan te bevelen om deze allen te bekijken en deze al dan niet te verwijderen afhankelijk van het feit of het om een effectieve brug gaat of niet. Bruggen die door meerdere lijnen voorgesteld worden omdat de weg in het routesysteem toevallig gesplitst is in het midden van de brug – wat mogelijk kan voorkomen maar in het originele routesysteem in principe niet het geval is – moeten manueel tot één brugelement samengevoegd worden. Bemerk ook dat gewestwegen meestal voorgesteld worden door 2 identieke lijnelementen, elk voor 1 rijrichting, zodat voor de bruggen ook 2 geometrisch identieke lijnelementen zullen bekomen worden: één van beide mag verwijderd worden. Tenslotte moeten deze lijnelementen nog omgevormd worden tot rechte lijnstukken met een begin- en eindpunt, zonder tussenliggende knooppunten. Dit is van belang om in IMMI correct als een zwevende brug te worden voorgesteld. Immers, de brugelementen zullen in IMMI geïmporteerd worden met relatieve hoogte 0 wat betekent dat alle knooppunten op deze hoogte zullen geplaatst worden en dat de tussenliggende knooppunten tot gevolg zullen hebben dat de brug eerder het terreinmodel zal volgen dan op een bepaalde hoogte boven het terrein te zweven. Het vereenvoudigen van lijnelementen kan in ArcGIS door gebruik te maken van de “Generalize” Visual Basic functie die bijvoorbeeld op een manier gelijkaardig als in Bijlage 5. beschreven is kan toegepast worden. Het principe van deze functie is dat lijnen vereenvoudigd worden door zo veel mogelijk knooppunten te verwijderen met een maximale afwijking tov het originele lijnstuk als parameter. Als deze parameter dus voldoende groot ingesteld wordt zullen tussenliggende knooppunten dus verwijderd worden en ontstaat een recht lijnstuk met een begin- en eindpunt die gelijk zijn aan die van het originele element. Tenslotte moet de attribuutstructuur beantwoorden aan de tabel in § 6 van Bijlage 2., dus volgende attributen moeten toegevoegd worden:

• REL_HEIGHT: in principe zal deze gelijk gesteld worden aan 0 om het begin- en eindpunt te laten aansluiten op het terreinmodel,

• BREITE: is de breedte van het brugoppervlak, kan aangevuld worden als er meer informatie beschikbaar is, bij gebrek aan informatie zullen waarden van 16 tot 20m vaak voldoen,

• HLSW_LI: is de hoogte van een eventueel geluidsscherm op de linkse1 zijde van de brug, hiervoor moet teruggekoppeld worden naar informatie over geluidsschermen - zie § 5. – en indien afwezig op 0 gesteld worden,

• HLSW_RE: is de hoogte van een eventueel geluidsscherm op de rechtse zijde van de brug en moet indien afwezig op 0 gesteld worden.

1 De linkse en rechtse zijde van het brugelement zijn van elkaar te onderscheiden door te kijken van het beginpunt van de

brug (het 1ste

knooppunt) naar het eindpunt van de brug (het 2de

knooppunt).

1

2

brug = lijnelem

ent

BREITE

HL

SW

_R

E

HL

SW

_L

I


MOB/ARCNOISE 2004



• Voor bruggen hebben we getracht om een methode te ontwikkelen die zo weinig mogelijk ingrepen vraagt, maar toch zal nog heel wat verificatie en ingreep vanwege de gebruiker nodig zijn, vooral dan in meer complexe situaties. Het is in ieder geval belangrijk dat deze verificatie gebeurt om onverwachte resultaten te vermijden.


• De brug moet gezien worden als een zwevend reflecterend element (MODUS = flying obstacle). Het element reflecteert (REFLECTION = TRUE) met een gemiddelde absorptie voor zowel het brugoppervlak als eventuele opstaande geluidsschermen aan de rand (ABSORPTION = 1). Deze laatste parameter kan niet afzonderlijk ingesteld worden voor brugoppervlak en geluidsschermen.


MOB/ARCNOISE 2004


BIJLAGE 4.


MOB/ARCNOISE 2004


Lijst van objecten AD110 : staatsgrens ADMINET - Lijnen AD120 : gewestgrens ADMINET - Lijnen AD130 : provinciegrens ADMINET - Lijnen AD140 : grens van een arrondissement ADMINET - Lijnen AD150 : gemeentegrens ADMINET - Lijnen AD250 : gemeente ADMINET - Polygonen AD310 : grenspaal (10) ADMIPNT - Punten AL210 : punt met gekende hoogte (50) ALTIPNT - Punten AL220 : bathymetrisch punt (50) ALTIPNT - Punten AL230 : geodetisch punt op de grond (50) ALTIPNT - Punten AL240 : geodetisch punt op een hoogte (50) ALTIPNT - Punten EL110 : bovengrondse hoogspanningslijn (+70kV) ELECNET - Lijnen EL210 : elektriciteitscentrale ELECNET - Polygonen STRUCNET - Polygonen CPL - Polygonen EL220 : transformatorstation (complex) (50) ELECNET - Polygonen STRUCNET - Polygonen CPL - Polygonen EL221 : transformatorstation (technisch gebouw) (10) ELECNET - Polygonen STRUCNET - Polygonen EL222 : transformatorstation (omheining) (10) ELECNET - Lijnen EL230 : windturbine/windrad (50) ELECPNT - Punten STRUCPNT - Punten EL231 : windturbine (10) ELECPNT - Punten STRUCPNT - Punten EL240 : hoogspanningsmast (10) ELECPNT- Punten STRUCPNT - Punten GS110 : zand (10) LANDUSE - Polygonen GS111 : droog zand (50) LANDUSE - Polygonen GS112 : vochtig zand (50) LANDUSE - Polygonen GS120 : slikke LANDUSE - Polygonen GS130 : schorre LANDUSE - Polygonen GS200 : rots LANDUSE - Polygonen GS300 : Steriele grond (10) LANDUSE - Polygonen HY111 : as van waterloop HYDRONET - Lijnen HY112 : oppervlak van waterloop HYDRONET - Polygonen LANDUSE - Polygonen HY113 : verbreding van de rivier (50) HYDRONET - Polygonen LANDUSE - Polygonen HY120 : meer, vijver, poel, bassin (10) HYDRONET - Polygonen LANDUSE - Polygonen HY121 : vijver (50) HYDRONET - Polygonen LANDUSE - Polygonen HY122 : overstromingsbekken (50) HYDRONET - Polygonen LANDUSE - Polygonen HY130 : moeras (50) HYDRONET - Polygonen HY131 : moeras (10) HYDRONET - Polygonen


MOB/ARCNOISE 2004


LANDUSE - Polygonen HY132 : moerassige grond (10) HYDRONET - Polygonen HY140 : Noordzee (10) HYDRONET - Polygonen LANDUSE - Polygonen HY141 : dieptezone Noordzee en zeemond van de Schelde) (50) HYDRONET - Polygonen LANDUSE - Polygonen HY150 : waterpunt (bron, fontein, put) (50) HYDROPNT - Punten HY151 : bron (10) HYDROPNT - Punten HY152 : fontein (10) HYDROPNT - Punten HY153 : put (10) HYDROPNT - Punten HY211 : golfbreker HYDRONET - Lijnen HY212 : havenhoofd (50) HYDRONET - Lijnen HY213 : zeedijk (50) HYDRONET - Lijnen HY221 : stuwdam HYDRONET - Lijnen HY222 : stuw HYDRONET - Lijnen HY223 : kleine stuw, watervalletje (10) HYDRONET - Lijnen HY224 : valdeur (10) HYDROPNT - Punten HY230 : steiger, aanlegsteiger, kade, vernauwingsdijk (50) HYDRONET - Lijnen HY231 : kade (10) HYDRONET - Lijnen HY232 : geleidewerken (10) HYDRONET - Lijnen HY233 : steiger (10) HYDRONET - Lijnen HY240 : sluis HYDRONET - Polygonen LANDUSE - Polygonen HYDROPNT - Punten HY241 : sluisdeur (10) HYDRONET - Lijnen HY250 : scheepslift HYDRONET - Polygonen STRUCNET - Polygonen LANDUSE - Polygonen HY261 : ingang grondduiker HYDROPNT - Punten HY262 : duikeringang (10) HYDROPNT - Punten HY271 : lichtopstand HYDROPNT - Punten HY272 : baken HYDROPNT - Punten HY273 : dukdalf (10) HYDROPNT - Punten HY274 : vuurtoren HYDROPNT - Punten STRUCPNT - Punten HY310 : dieptelijn HYDRONET - Lijnen HY510 : kilometerpaal langs waterweg HYDROPNT - Punten LA110 : talud (50) SCAPENET - Lijnen LA111 : top groot talud (10) SCAPENET - Lijnen LA112 : basis groot talud (10) SCAPENET - Lijnen LA113 : klein talud (10) SCAPENET - Lijnen LA114 : groot talud (10) SCAPENET - Polygonen LA120 : droge gracht SCAPENET - Lijnen LA130 : dijk, wal (50) SCAPENET - Lijnen LA131 : top grote dijk (10) SCAPENET - Lijnen LA132 : basis grote dijk (10) SCAPENET - Lijnen LA133 : kleine dijk (10) SCAPENET - Lijnen LA134 : grote dijk (10) SCAPENET - Polygonen LA140 : steilte (10) SCAPENET - Lijnen LA150 : steile rots (50) SCAPENET - Polygonen LA161 : duin SCAPENET - Polygonen LA162 : duinhelling (10) SCAPENET - Lijnen LA170 : terril (50) SCAPEPNT - Punten


MOB/ARCNOISE 2004


LA171 : hoogtelijn in terril (10) SCAPENET - Lijnen LA210 : muur SCAPENET - Lijnen LA220 : steunmuur (10) SCAPENET - Lijnen LA230 : grondvesten (10) SCAPENET - Lijnen LA240 : begrenzing ontoegankelijke zone (10) SCAPENET - Lijnen LA310 : kruis SCAPEPNT - Punten LA320 : paal (historisch, merkwaardig) SCAPEPNT - Punten LA330 : tumulus SCAPEPNT - Punten LA340 : megaliet (10) SCAPEPNT - Punten LA350 : monument, monumentaal standbeeld (10) SCAPEPNT - Punten LA360 : ingang grot (10) SCAPEPNT - Punten RA110 : spoor RAILNET - Lijnen RA112 : oppervlak spoorbaan LANDUSE - Polygonen RA210 : kabelspoor RAILNET - Lijnen RA311 : station (50) RAILPNT - Punten RA312 : halte voor reizigers RAILPNT - Punten RA313 : metrostation (10) RAILPNT - Punten RA510 : kilometerpaal langs spoorweg RAILPNT - Punten RO111 : wegas ROADNET - Lijnen RO112 : oppervlak van weg (10) ROADNET - Polygonen LANDUSE - Polygonen RO113 : kruispunt (10) ROADNET - Polygonen LANDUSE - Polygonen RO120 : aardeweg ROADNET - Lijnen RO130 : pontveer ROADNET - Lijnen RO140 : wad (10) ROADNET - Lijnen RO150 : parkeerterrein ROADPNT - Punten RO160 : wegversmalling (50) ROADPNT - Punten RO210 : pad ROADNET - Lijnen RO220 : fietspad (10) ROADNET - Lijnen RO230 : voetveer ROADNET - Lijnen RO240 : voetgangerstunnel ROADNET - Lijnen RO250 : trap ROADNET - Lijnen RO260 : winkelgalerij (10) ROADNET - Lijnen RO270 : brandgang (10) ROADNET - Lijnen RO310 : versperring voor autoverkeer (10) ROADNET - Lijnen RO510 : kilometerpaal langs weg ROADPNT – Punten ST110 : industrieel gebouw (50) STRUCNET - Polygonen LANDUSE - Polygonen ST111 : industrieel gebouw (in gebruik) (10) STRUCNET - Polygonen LANDUSE - Polygonen ST112 : industrieel gebouw (buiten gebruik) (10) STRUCNET - Polygonen LANDUSE - Polygonen ST113 : stapelhuis, hangaar, afdak (10) STRUCNET - Polygonen LANDUSE - Polygonen ST120 : silo/opslagtank (10) STRUCNET - Polygonen LANDUSE - Polygonen ST121 : silo (voedingsproducten) (50) STRUCNET - Polygonen LANDUSE - Polygonen ST122 : opslagtank (50) STRUCPNT - Punten ST131 : serre STRUCNET - Polygonen


MOB/ARCNOISE 2004


LANDUSE - Polygonen ST132 : boerderij (50) STRUCNET - Polygonen LANDUSE - Polygonen ST141 : koeltoren STRUCNET - Polygonen LANDUSE – Polygonen STRUCPNT - Ptn ST142 : schoorsteen STRUCPNT - Punten ST143 : bedrijfsfakkel (10) STRUCPNT - Punten ST151 : windrad (10) STRUCPNT - Punten ST152 : watermolen (50) STRUCPNT - Punten ST153 : windmolen STRUCPNT - Punten ST154 : waterrad (10) STRUCPNT - Punten ST160 : gasstation (10) STRUCPNT - Punten ST170 : steen-, zandgroeve (50) STRUCNET - Polygonen LANDUSE - Polygonen ST180 : pijpleiding voor industriële producten STRUCNET - Lijnen ST210 : hospitaal of ziekenhuis (50) STRUCNET - Polygonen LANDUSE - Polygonen ST211 : niet-universitair ziekenhuis (10) STRUCNET - Polygonen LANDUSE - Polygonen ST212 : universitair ziekenhuis (10) STRUCNET - Polygonen LANDUSE - Polygonen ST220 : gemeentehuis STRUCNET - Polygonen LANDUSE - Polygonen ST230 : schoolgebouw STRUCNET - Polygonen LANDUSE - Polygonen ST240 : brandweerkazerne STRUCNET - Polygonen LANDUSE - Polygonen ST250 : commercieel gebouw (10) STRUCNET - Polygonen LANDUSE - Polygonen ST260 : rijkswachtkazerne (50) STRUCNET - Polygonen LANDUSE - Polygonen ST270 : rusthuis (50) STRUCNET - Polygonen LANDUSE - Polygonen ST280 : gevangenis (50) STRUCNET - Polygonen LANDUSE - Polygonen ST291 : luchthaven (50) CPL (50) - Polygonen ST292 : landingsbaan (50) STRUCNET - Polygonen LANDUSE - Polygonen ST293 : landingsplaats voor helikopters (10) STRUCPNT - Punten ST311 : religieus gebouw (10) STRUCNET - Polygonen LANDUSE - Polygonen ST312 : kerk of grote kapel buiten gebruik (10) STRUCNET - Polygonen LANDUSE - Polygonen ST313 : religieus gebouw (uitgez. katholieke en orthodoxe godsdienst) (50) STRUCNET - Polygonen LANDUSE - Polygonen ST320 : klooster (50) STRUCNET - Polygonen LANDUSE - Polygonen ST330 : abdij (50) STRUCNET - Polygonen LANDUSE - Polygonen ST340 : kerk (50) STRUCPNT - Punten ST350 : kapel (kleine en grote) (50) STRUCPNT - Punten ST351 : kleine kapel (10) STRUCPNT - Punten


MOB/ARCNOISE 2004


ST360 : Grot O.L.V. van Lourdes (10) STRUCPNT - Punten ST410 : sportcomplex (50) CPL (50) - Polygonen ST411 : gebouw voor sportbeoefening (10) STRUCNET - Polygonen LANDUSE - Polygonen ST412 : sportterrein (10) STRUCPNT - Punten ST413 : voetbalterrein (50) STRUCPNT - Punten ST414 : overdekte tribune (10) STRUCNET - Polygonen LANDUSE - Polygonen ST415 : niet-overdekte tribune (10) STRUCNET - Polygonen LANDUSE - Polygonen ST416 : overdekt zwembad (10) STRUCNET - Polygonen LANDUSE - Polygonen ST417 : openluchtzwembad (10) STRUCNET - Polygonen LANDUSE - Polygonen ST420 : golfterrein (50) CPL (50) - Polygonen ST430 : observatietoren (10) STRUCPNT - Punten ST440 : pretpark (50) CPL (50) - Polygonen ST450 : zoo (50) CPL (50) - Polygonen ST460 : renbaan (50) STRUCNET - Polygonen LANDUSE - Polygonen ST461 : piste van renbaan (50) STRUCNET - Polygonen LANDUSE - Polygonen ST510 : historische ruïne STRUCNET - Polygonen LANDUSE - Polygonen ST520 : vesting (50) STRUCNET - Polygonen LANDUSE - Polygonen ST530 : kasteel (50) STRUCPNT - Punten ST541 : monument (10) STRUCNET - Polygonen LANDUSE - Polygonen ST542 : monumentale trap (10) STRUCNET - Polygonen LANDUSE - Polygonen ST610 : telecommunicatiemast (10) STRUCPNT - Punten ST611 : telecommunicatiemast (burgerlijk) (50) STRUCPNT - Punten ST612 : telecommunicatiemast (militaire veiligheid) (50) STRUCPNT - Punten ST620 : telecommunicatietoren (10) STRUCPNT - Punten ST630 : paraboolantenne (10) STRUCPNT - Punten ST640 : radiobaken (10) STRUCPNT - Punten ST711 : reservoir voor drinkwater STRUCPNT - Punten ST712 : watertoren STRUCPNT - Punten ST720 : gebouw voor drinkwaterwinning en -voorziening STRUCNET - Polygonen LANDUSE - Polygonen ST721 : pompstation (50) STRUCPNT - Punten ST730 : zuiveringsstation (50) CPL (50) - Polygonen ST731 : zuiveringsbekken (50) STRUCPNT - Punten ST740 : bemalingsinstallatie (drainage) STRUCPNT - Punten ST750 : pijpleiding voor water STRUCNET - Lijnen ST911 : gewoon gebouw STRUCNET - Polygonen LANDUSE - Polygonen ST912 : gebouw van openbaar nut of merkwaardig gebouw STRUCNET - Polygonen LANDUSE - Polygonen ST913 : hoog gebouw (hoger dan 50m) (10) STRUCNET - Polygonen LANDUSE - Polygonen ST914 : bouwvallig gebouw (10) STRUCNET - Polygonen LANDUSE - Polygonen


MOB/ARCNOISE 2004


ST915 : bebouwde wijk (50) STRUCNET - Polygonen LANDUSE - Polygonen ST920 : toren STRUCPNT - Punten ST931 : begraafplaats STRUCNET - Polygonen LANDUSE - Polygonen STRUCPNT - Punten ST932 : kleine begraafplaats (10) STRUCPNT - Punten ST940 : luchthal (10) STRUCNET - Polygonen LANDUSE - Polygonen VE110 : loofhout (50) LANDUSE - Polygonen VE111 : hoogstammig loofhout zonder ondergroei van struiken (10) LANDUSE - Polygonen VE112 : hakhout (10) LANDUSE - Polygonen VE113 : middelhout of hoogstammig loofhout met ondergroei van struiken (10) LANDUSE - Polygonen VE114 : populierenaanplant(10) LANDUSE - Polygonen VE120 : naaldhout LANDUSE - Polygonen VE130 : gemengd loof- en naaldhout (50) LANDUSE - Polygonen VE131 : gemengd loof- en naaldhout zonder dominant (10) LANDUSE - Polygonen VE132 : gemengd loof- en naaldhout met dominantie van loofhout (10) LANDUSE - Polygonen VE133 : gemengd loof- en naaldhout met dominantie van naaldhout (10) LANDUSE - Polygonen VE140 : boomgaard LANDUSE - Polygonen VE150 : boomkwekerij LANDUSE - Polygonen VE160 : bomenrij SCAPENET - Lijnen VE170 : merkwaardige boom SCAPEPNT - Punten VE180 : alleenstaande boom (10) SCAPEPNT - Punten VE210 : heide (alle types gegroepeerd) (50) LANDUSE - Polygonen VE211 : heide (10) LANDUSE - Polygonen VE212 : heide met kreupelhout (10) LANDUSE - Polygonen VE213 : heide met loofhout (10) LANDUSE - Polygonen VE214 : heide met naaldhout (10) LANDUSE - Polygonen VE220 : struikgewas of kreupelhout (10) LANDUSE - Polygonen VE231 : ruderale vegetatie (10) LANDUSE - Polygonen VE232 : ruderale vegetatie met opslag van struiken (10) LANDUSE - Polygonen VE240 : rietveld (10) LANDUSE - Polygonen VE250 : haag (10) SCAPENET - Lijnen VE260 : houtkant (10) SCAPENET - Lijnen VE270 : struik (10) SCAPEPNT - Punten VE310 : grasperk, andere graslanden LANDUSE - Polygonen VE320 : hooi- of weiland (10) LANDUSE - Polygonen VE330 : tuin (10) LANDUSE - Polygonen VE340 : land- of tuinbouwgrond (10) LANDUSE - Polygonen


MOB/ARCNOISE 2004


BIJLAGE 5.


MOB/ARCNOISE 2004


Interne openingen in polygonen

Interne openingen in polygonen die moeten verwijderd worden kunnen relatief eenvoudig aangepakt worden met volgend stukje Visual Basic code. Dim i As Integer Dim j As Integer Dim pExteriorRing() As IRing Dim pInteriorRing() As IRing Dim pPolygon As IPolygon Set pPolygon = [Shape] i = pPolygon.ExteriorRingCount Redim pExteriorRing(i) pPolygon.QueryExteriorRings pExteriorRing(0) i = pPolygon.InteriorRingCount(pExteriorRing(0)) If i <> 0 Then Redim pInteriorRing(i) pPolygon.QueryInteriorRings pExteriorRing(0), pInteriorRing(0) For j = 0 To i - 1 pInteriorRing(j).SetEmpty Next j End If De eenvoudigste manier om dit toe te passen op de shapefile met polygonen die moet bewerkt worden gaat als volgt: best kan men een extra attribuut toevoegen dat het aantal interne openingen zal tellen. Vervolgens start men een editeersessie voor de bewuste shapefile in ArcGIS en berekent men het toegevoegde attribuut met de hierboven weergegeven code: deze zal het aantal interne openingen tellen én ook verwijderen. Het aantal interne – verwijderde – openingen is dan gelijk aan i. “Multipart features” moeten daarbij vooraf gesplitst worden met de “Multipart to Singlepart” functie.


MOB/ARCNOISE 2004


Voor het verwijderen van polygonen met interne openingen kan de If - End If structuur volledig weggelaten worden. De code zal dan het aantal interne openingen berekenen als attribuutwaarde. Polygonen met een waarde die niet gelijk is aan 0 kunnen dan op basis van een gewone selectie verwijderd worden. Een manuele manier om interne openingen te verwijderen is door een polygoon met grote interne openingen doormidden te snijden – en dus in één of meerdere elementen te splitsen – zodat de interne opening wel een “opening” blijft, maar niet langer “intern” is. Dit kan in een editeersessie in ArcGIS gebeuren met de “Cut Polygon Features” functie zoals weergegeven is in onderstaande afbeeldingen.


MOB/ARCNOISE 2004


BIJLAGE 6.


MOB/ARCNOISE 2004


--GGIISS Noise mapping calculation kernel

for ArcGIS 9.x environments

User’s Manual

Version 1.6 Delivery of the MOB/ArcNoise 2004 contract; release date: 21/10/2006


MOB/ARCNOISE 2004


1. Introduction

The present manual explains both the installation and the use of IMMI-GIS. IMMI-GIS is the combination of

• a calculation kernel for outdoors sound propagation based on IMMI technology, and • an interface added to the ArcGIS 9.x environment to start the calculation with the IMMI calculation

kernel and to make settings. The current implementation of IMMI-GIS for “Afdeling Beleid Mobiliteit en Verkeersveiligheid” of the “Departement Mobiliteit en Openbare Werken” provides support for calculations according to the Standaard Rekenmethode II described in “Reken- en Meetvoorschrift Wegverkeerslawaai 2002”. The latest road surface corrections available in August 2006 and published on the website “www.stillerverkeer.nl” have been programmed into this computer programme. To make IMMI-GIS work properly, the user must provide input data in shape file format. The required formatting of the attributes and vector data is described in a separate document. The present document describes the actual use and working of IMMI-GIS and the installation of both the IMMI calculation kernel for ArcGIS and the installation of the user interface inside the ArcGIS environment.

2. Installation

This section of the IMMI-GIS user’s manual deals with the installation of IMMI-GIS on your computer. Remark 1: IMMI-GIS needs ArcMap to be installed on your computer. The installation of ArcMap is not within the scope of this manual. For ArcMap installation instructions refer to the user manual of ArcGIS/ArcMap. Remark 2: The VBA environment must be installed in ArcMap prior to installing IMMI-GIS. ArcMap can be installed without major extensions such as .NET support, Tablet-PC support and others. VBA is installed as part of one or more of these modules. To check whether VBA is installed open “Tools | Macro” and verify whether the VBA submenu points are present. Note that VBA macros cannot be installed if the VBA environment is not properly installed in ArcMap.

2.1. IMMI-GIS executable

Insert the installation CD-ROM into your CD-ROM reader and follow the installation instruction on the screen. The installation process copies a series of files and the complete IMMI-GIS Windows runtime environment onto the hard disk. In case this is the first time IMMI-GIS or IMMI with the ArcView Interface Option is installed on your computer, the BORLAND Database Engine (BDE) must be installed:

• insert CD-ROM into CD-ROM drive of your computer • cancel installation routine • open Windows Explorer and view files on the CD-ROM • double-click folder BDE32 • double-click SETUP.EXE • follow the instructions on the screen

Caution: It has been reported that in Windows XP environments the BDE installation routine sometimes produces a somewhat cryptic error message at the end of the installation procedure. You may ignore this message: the BDE is properly installed and works flawlessly. In normal operation, the IMMI-GIS executable will never be started from the command line or from a link in the Programs folder. IMMI-GIS is supposed to be started from within the ArcMap environment. IMMI-GIS is complete only when both the IMMI-GIS executable environment and the IMMI-GIS ArcGIS interface have been installed.


MOB/ARCNOISE 2004


2.2. IMMI-GIS ArcGIS interface

Start ArcMap. Use “File | Open” to open “Install_ImmiGis.mxd” (this file has been installed on the IMMI-GIS installation folder while installing IMMI-GIS from the IMMI-GIS installation CD-ROM). Opening the file ArcMap reads and installs a series of VBA (Visual Basic for Applications) macros. When ArcMap has finished installing these macros, a message is displayed. Clicking the OK-button closes ArcMap. To complete the installation restart ArcMap: a new entry “IMMI-GIS” is now available in the main-menu entry “Tools”. The installation modifies the ArcMap template “Normal.mxt” which is user-dependent. This means that the IMMI-GIS ArcGIS interface installation has to be repeated for every Windows user that will be using IMMI-GIS. Important setting in ArcMap: To run macros in the ArcMAP environment, the VBA security level must be set to either “low” or “medium”. This is done in the menu “Tools - Customize - Options - Change VBA Security”.

3. Working with IMMI-GIS

IMMI-GIS is an automated calculation kernel for shapefile projects. It is installed as an application tool in the ArcMap environment.

3.1. Starting IMMI-GIS and setting parameters

IMMI-GIS is started from the “Tools” main menu of ArcMap.

Figure 1 – IMMI-GIS menu entry in the Tools main menu of ArcMap (actual content of the menu

can be different depending on the kind and number of ArcMap tools installed)

Click the IMMI-GIS entry to start the software. First start: a dialogue is displayed asking for the path to find the IMMI-GIS executable. The following dialogue is displayed in the ArcMap environment. The dialogue contains two tabs: one for a “New calculation” and another one to “Complete a grid calculation”.


MOB/ARCNOISE 2004


Parameters/settings of the tab “New calculation”:

Figure 2 – IMMI-GIS dialogue in ArcMap

• Job title: each time a calculation is started, it needs a proper and unique name. • Grid:

o Relative height /m: height of the receiver grid above the ground o Step size /m: selection list for constant equidistance between receiver points in x and y

direction (10, 20 and 40 meters). • Calculation parameters:

o Projection of line sound sources: the projection of line sources is a refined segmentation technique that ensures that all changes on the propagation path between the source line and the receiver points are taken into account. As a result of the projection the number of component sound sources increases.


MOB/ARCNOISE 2004


o Limiting range of sound sources (min. level difference /dB): this is an efficiency setting to speed up calculations. This acoustical criterion is based on an assessment of the individual contribution to the sound level at the receiver. If the difference between the total sound level and the partial contributing level is greater than the specified “level difference /dB”, the sound source will be excluded from the calculation. The greater the limiting range, the more sources will be excluded.

o Limiting range of reflecting surfaces /m: efficiency setting. Reflecting surface at a distance greater than the limiting range will not be taken into account. The smaller the limiting range, the more reflecting surfaces are excluded.

• Directories: o Input data: specify the path to the input shapefiles of the project. Clicking the “…”-button

opens a file search dialogue. o Results: specify the path to the output folder where the calculated results are stored. Clicking

the “…”-button opens a file search dialogue. • Interval for saving the grid calculation automatically /min: the time interval between successive

automatic backups during calculation.

Parameters/settings of the tab “Complete grid calculation”:

Figure 3 – complete grid calculation


MOB/ARCNOISE 2004


• IMMI project file with stored grid calculation: specify a path where IMMI-GIS saves intermediate

results that can be reused in case a calculation must be interrupted. • Interval for saving the grid calculation automatically /min: the time interval between successive

automatic backups during calculation.

Buttons of the two tabs “New calculation” and “Complete grid calculation”:

• “Cancel”: quits the dialogue without starting IMMI-GIS. All settings remain intact. • “IMMI…”: opens a file search dialogue to specify the path to the IMMI-GIS installation directory. • “Run IMMI-GIS”: starts the IMMI-GIS executable, i.e. starts a calculation using the input shapefiles

stored in the input shapefile directory. IMMI-GIS automatically opens all shapes and sets up a noise mapping project.

3.2. IMMI-GIS calculation run

Clicking the “Run IMMI-GIS”-button starts the calculation of the noise mapping project. The IMMI-GIS executable is launched and a series of parameters are passed through, including all settings made in the aforementioned “parameters/settings” dialogue. IMMI-GIS reads in all shapefiles located in the input file directory. In ArcMap all information of a theme (or a layer) are stored in shapefile format. For each theme a combination of three individual files is stored:

• .shp: geo-referenced vector data (graphics information) • .shx: index file linking vectors with attribute databases • .dbf: database files containing all attributes

For IMMI-GIS the structure of the database of each file is fixed. The proper definition of the files and the IMMI element types supported can be found in annex of the final report. IMMI-GIS opens these shapefiles and transforms all vector and attribute data into a complete IMMI noise mapping project. IMMI-GIS then automatically starts the calculation. A progress report is displayed in ArcView informing the user about the state of progress of the calculation.

Figure 4 – IMMI-GIS calculation progress dialogue

The numeric results of the calculation are stored in the result directory specified in the “Parameters/settings” of the “New calculation” tab. During calculations these results are stored in a binary file format proprietary to IMMI-GIS.


MOB/ARCNOISE 2004


To quit the dialogue in a proper, orderly fashion click “Cancel”. IMMI-GIS will be notified of your wish to cancel the calculation and you will be prompted to confirm your choice. If confirmed, IMMI-GIS is instructed to stop the calculation and to quit. Leaving the dialogue by means of the button “X” in the upper right corner does not stop the calculation. This would be handy if you wish to continue working in ArcMap while IMMI-GIS is calculating in the background. Disadvantage: you are no longer informed about the progress of the calculation. When you find that IMMI-GIS stopped and quit you will find the result files as usual in the result folder. At the end of the calculation the IMMI-GIS proprietary format is transformed into a binary data format compatible with ArcGIS/ArcMap. Both the calculation and the data transformation is finished when the following message is displayed: the noise map is now ready for import in ArcGIS/ArcMap.

Figure 5 – message window signalling the end of a grid calculation

3.3. Opening a project and the calculated noise map in ArcGIS/ArcMap

To open the shapefiles that are stored in the IMMI-GIS input directory, click the button in the ArcMap speed bar beneath the main menu. Use the file search dialogue to open some or all of the shapes in the IMMI-GIS input directory.

Figure 6 – ArcMap “Add data” dialogue


MOB/ARCNOISE 2004


To open a calculated noise map, first open the ArcToolBox. A menu entry for the ArcToolbox can be found in ArcMap’s “Window” main menu. In the ArcToolbox select “ArcToolbox | Conversion Tools | Float to Raster” to open the file search dialogue for both input and output rasters. Select one of the result layers stored in the IMMI-GIS result directory as “Input floating point raster file” and both a directory and a filename of your choice for the “Output raster”.

Figure 7 – importing a binary raster file into ArcMap

The progress of the raster import is displayed in an ArcMap message window. At the end of the import operation, you get the following result.


MOB/ARCNOISE 2004


Figure 8 – imported raster data of a noise map

In a final step the colour codes must be defined or imported from an already defined layer file. This can be done clicking on the raster feature displayed in the “Table of Contents” column as shown hereunder:

Figure 9 – strategic noise map calculated by IMMI-GIS and displayed in ArcMap


MOB/ARCNOISE 2004


The ArcGIS environment offers all necessary possibilities to visualize the resulting noise maps or continue with the results for postprocessing.

4. IMMI-GIS messages

4.1. Status messages

Status messages are displayed in the “IMMI-GIS Progress” window (see Figure 4). Standard information is relative to the progress of the calculation. Further information can be displayed to inform about special conditions. The messages are explained in Table 1.

Table 1 – IMMI-GIS progress and status messages

Message Use/description example Progress: Progress of the calculation (in percentage) "17.35 %" Time expired (since): Time expired since the start of the calculation, or the time

needed to reach the current progress state of the calculation.

"01:22:33 h"

Remaining time (finish): An estimate of the remaining time to finish the calculation. "12:34:56 h" Calculated points: Absolute number of receiver points calculated and [the

number of points remaining] "312 [8100]"

Number of exceptions: Number of points for which no noise level could be calculated (generally numerical exceptions).

"0"

Calculation aborted. Feedback from IMMI when abortion of calculation is requested by the user.

"Calculation aborted"

Auto-save status: Information regarding the portion of the total grid that has been saved with the last autosave (percentage)

"85.6 %"

4.2. Error messages

IMMI-GIS tests the validity of all parameters and shapefile attributes. If an error is detected the following error message is displayed in the ArcMap environment.


MOB/ARCNOISE 2004


Figure 10 – IMMI-GIS error message for invalid files

To avoid that previous projects are non-intentionally erased, IMMI-GIS issues the following error message in the ArcMap environment when a new calculation is started under an existing job title.

Figure 11 – IMMI-GIS error message for existing job names

5. Filename conventions

The exchange of clippings or complete GIS datasets with IMMI relies on the use of fixed filenames. These filenames are:

• For road sources: ”road_sources” • For buildings: “buildings” • For ground effect elements: “ground_effect” • For bridges/flyovers/viaducts: “bridges” • For walls/screens: “noise_barriers” • For height contours: “HOEL”, and • For altitude points: “HOEP”.

6. Uninstalling the IMMI-GIS extension in ArcMap

1. Run ArcMap

2. Open the Visual Basic Editor (Alt+F11 or Tools – Macros – Visual Basic Editor)


MOB/ARCNOISE 2004


3. In the "Project Explorer" (Ctrl+F4 or View – Project Explorer), select "Normal":

4. Remove IMMIForm

1. Select IMMIForm (or Forms – IMMIForm) 2. Right-click IMMIForm (or Forms – IMMIForm) 3. Click "Remove IMMIForm" from the popup menu:

4. You are asked if you want to export the module before removing it. You can click "No"

5. Repeat the steps 4.1. to 4.4. for the following modules: 1. ImmiProgress (or Forms – ImmiProgress) 2. ImmiTools (or Modules – ImmiTools)

5. Double-click the module Normal – ThisDocument (or Normal – ArcMap Objects – ThisDocument), this opens the VBA code of this module in the editor

6. Search for "Private Sub CreateIMMIMenu()" and delete the whole routine

7. Search for "Private Sub IMMIMacro()" and delete the whole routine

8. Search for 'Calling the routine for Creating a menu-item "IMMI-GIS" CreateIMMIMenu

in the functions MxDocument_OpenDocument() and MxDocument_NewDocument()

and delete both lines (the comment and CreateImmiMenu)

9. Save Normal.mxt (Ctrl+S or File – Save Normal.mxt)

10. Close the Visual Basic Editor and exit ArcMap


MOB/ARCNOISE 2004


BIJLAGE 7.


MOB/ARCNOISE 2004



MOB/ARCNOISE 2004



MOB/ARCNOISE 2004



MOB/ARCNOISE 2004


BIJLAGE 8.


MOB/ARCNOISE 2004


Geluidsniveau in dB(A)

testgebied_1_Lden

Value

... - 40

40 - 45

45 - 50

50 - 55

55 - 60

60 - 65

65 - 70

70 - 75

75 - ...

0 500 1000 1500 2000 2500250

Meters


MOB/ARCNOISE 2004



test_1_Lnight

Value

... - 40

40 - 45

45 - 50

50 - 55

55 - 60

60 - 65

65 - 70

70 - 75

75 - ...

0 500 1000 1500 2000 2500250

Meters


MOB/ARCNOISE 2004



testgebied_2_Lden

Value

... - 40

40 - 45

45 - 50

50 - 55

55 - 60

60 - 65

65 - 70

70 - 75

75 - ...

0 500 1000 1500 2000 2500250

Meters


MOB/ARCNOISE 2004



test_2_Lnight

Value

... - 40

40 - 45

45 - 50

50 - 55

55 - 60

60 - 65

65 - 70

70 - 75

75 - ...

0 500 1000 1500 2000 2500250

Meters


MOB/ARCNOISE 2004



testgebied_3_Lden

Value

... - 40

40 - 45

45 - 50

50 - 55

55 - 60

60 - 65

65 - 70

70 - 75

75 - ...

0 500 1000 1500 2000 2500250

Meters


MOB/ARCNOISE 2004



test_3_Lnight

Value

... - 40

40 - 45

45 - 50

50 - 55

55 - 60

60 - 65

65 - 70

70 - 75

75 - ...

0 500 1000 1500 2000 2500250

Meters

Documents

60100194-001 MOB-ArcNoise2004 fin - b...Referentie : 60100194-001(MOB-ArcNoise2004) fin - b.doc -- Bijlage 2. -- Pagina 2 van 5 MOB/ARCNOISE 2004 Vinçotte Environment nv – Wölfel