Historikk DATO SBESKRIVELSE 12.06.2017 Endelig versjon 2 av 34
Innhold 1 Bakgrunn 4 2 Følsomhetsanalyse i RTM 4 2.1 Endringer i totalt antall turer................................... 4 2.2 Endringer fordelt på bydeler................................... 6 2.3 Konklusjon............................................. 7 3 Metodebeskrivelse - Om kostnadsoverflate 7 3.1 Gåing og impedans........................................ 7 3.2 Generalisert reisekostnad og modellering av gåing........................ 7 3.3 Kostnadsrasteret......................................... 8 3.4 Hvor store er «penalty»-bidragene i kostnadsrasteret?..................... 9 3.5 Hva er resultatet fra en «least cost path»-kalkulasjon med denne modellen?.......... 9 3.6 Des nasjonspunkt inne i en bygning............................... 11 4 Brukerveiledning 14 4.1 Beskrivelse av metode...................................... 14 4.2 Forberedelser........................................... 17 4.3 Se e opp et raster-prosjekt.................................... 18 4.4 Kjøre applikasjon for å generere raster og beregne avstander.................. 22 5 Tolking av resultater 23 5.1 Eksempel: ByGarasjen i Bergen.................................. 26 6 Bruk i RTM 28 6.1 Endring i modellfaktorer..................................... 28 7 Eksempel på beregning av internavstand for grunnkretser i Bergen 29 7.1 Grunnkretser........................................... 29 7.2 Des nasjonspunkt........................................ 30 7.3 Boliger som startpunkt...................................... 30 7.4 Beregning av gjennomsni lig internavstand........................... 30 7.5 Bruk av RTM l å beregne virkninger av et ltak......................... 31 8 Oppsummering og forslag l videre arbeid 32 8.1 Utskri av reise d......................................... 32 8.2 Applikasjonens brukergrensesni................................. 33 8.3 Muligheter for bruk av metoden................................. 33 Referanser 34 3 av 34
1 Bakgrunn Dette prosjektnotatet beskriver en videreutvikling av rastermetode for å beregne tilgjengelighet for gående i transportmodeller beskrevet i SINTEF-rapport Mer presis modellering av gåing og grunnkretsinterne reiser i RTM (Malmin et al., 2016). Prosjektet ble gjennomført på oppdrag fra Kommunal- og moderniseringsdepartementet høsten 2016. Prosjektet er organisert under programmet Karakteristika i Transportmodeller (KIT). Prosjektleder i SINTEF har vært Olav Kåre Malmin, og prosjektmedarbeidere har vært Petter Arnesen i SINTEF og Yngve Frøyen ved Institutt for byforming og planlegging ved NTNU. Resultatet av dette prosjektet er en applikasjon for å generere og beregne avstander med bruk av raster-gis, dette prosjektnotatet som inneholder en metode- og brukerbeskrivelse, og en PowerPoint-presentasjon holdt på et fagseminar arrangert av KIT 9.11.2016. Prosjektet har bestått av fire deler: 1. Følsomhetsanalyse av endret internavstand for gange i RTM. Denne følsomhetsanalysen gir svar på i hvor stor grad vi kan forvente at transportmodellen responderer på analyser av bedre tilgjengelighet for gående. 2. Videreutvikling av metode. Malmin et al. (2016) beskrev grunnleggende teknikker for å beregne et avstandsraster for gående. I dette prosjektet har vi sett mer på bruk av flere datakilder og utviklet en automatisk metode for å beregne et avstandsraster. 3. Utarbeide en brukerbeskrivelse for å benytte automatisert applikasjon for å beregne avstandsraster. Brukerbeskrivelsen tar utgangspunkt i at brukeren har kompetanse på GIS. 4. Testet applikasjonen på et område i Bergen. 2 Følsomhetsanalyse i RTM I dette avsnittet diskuteres i hvor stor grad endring av internavstand har noe å si for modellresultatet i RTM. Det ble gjennomført en følsomhetsanalyse for delområdemodell Bergen med ulike endringer i internavstanden for gående og syklende. Både gående og syklende fikk en endring i internavstand siden det ikke er mulig i dagens versjon av RTM å skille på kostnader for disse to transportmåtene. Det ble utført en beregning for scenarier med ulik internavstand for gående og syklende. Dette innebar både relative og absolutte endringer for alle grunnkretser i Bergen kommune. De relative endringene var på -20%, -10%, +10% og +20% i forhold til basisberegningen. De absolutte endringene i forhold til basis var -200 meter, -100 meter, +100 meter og +200 meter. Hvis reduksjonen førte til negativ internavstand ble det ikke gjort noen reduksjon. 2.1 Endringer i totalt antall turer Tabell 2.1 viser endring i totalt antall turer for Bergen kommune med de ulike endringene i internavstand. Prosentvis er det svært små endringer for både bil, kollektiv og gang/sykkel. Fortegnet på endringene er i samsvar med endringen i avstand. Antall turer med kollektive reisemiddel endrer seg når internavstanden endres for gående og syklende. Kortere internavstand gir færre kollektivreiser. Endringen er på svært få turer. Dette viser hvordan mekanikken i etterspørselsmodellen fungerer. Etterspørselsmodellen ble estimert basert på reisevaneundersøkelser, og i dette arbeidet har beskrivelsen av gange og sykkel vært beskrevet med avstanden internt i og mellom grunnkretser. Vi tolker av dette at estimering av interne turer for gående og syklende ikke har vært prioritert i modellestimeringen. 4 av 34
Tabell 1: Endring i totalt antall turer Det finnes ikke interne turer for kollektivtrafikk i RTM. Internavstanden påvirker ikke avstander til holdeplasser og transportsystemet forøvrig. En reduksjon i internavstand for gående og syklende gjør det mer attraktivt å gå eller sykle internt i grunnkretsen istedenfor å ta bussen til en annen destinasjon. Endringene påvirker også antall bilturer. Bilturer kan foregå internt i en sone, slik at interne gangturer og interne bilturer er i direkte konkurranse i modellen. Bilturer endrer seg mindre enn kollektivturer og gang/sykkelturer. Vi kan dermed slutte at selv om avstanden for turer i en grunnkrets blir kortere for gående enn for kjørende, vil dette i liten grad endre de som kjører bil sine vaner. Bedre tilrettelegging for gående gir økt antall interne gangturer på kollektivtrafikkens bekostning. Figur 2.1 viser endringer i prosent for alle interne turer med gang og sykkel. Figuren viser at modellen kan gi vesentlige endringer i antall gangturer når tilgjengeligheten endres i soner. Ved å gi alle soner internavstand på 200 meter vil dette gi ca 9% flere interne gange- og sykkelturer. Motsatt vil en dårligere tilgjengelighet kunne redusere antall interne gangturer med omtrent like mye. Figur 1: Endring i interne gang- og sykkelturer Endringer av interne bilturer er ikke vist i denne figuren. Maksimal reduksjon av interne bilturer er på 0,3% for -200 meter, og +200 meter gir en økning på 0,24%. I antall turer er dette henholdsvis 34 og 28 turer. Dette viser igjen at endring av tilgjengelighet for gående og syklende internt i grunnkretser i modellen ikke påvirker antall bilturer. 5 av 34
2.2 Endringer fordelt på bydeler Figur 2.2 viser endring i antall interne turer med gang og sykkel fordelt på bydeler i Bergen (SSB-bydeler, 6 siffer). Figur 2 viser samme endringer i prosent av antall interne gang- og sykkelturer. Figurene viser at ulike bydeler har forskjellig endring i grunnkretsinterne reiser. De største endringene oppstår naturlig nok når tilgjengeligheten endres med et absolutt antall meter, mens de relative endringene i turer varierer mindre mellom bydeler som følge av relative endringer i tilgjengelighet. Årsaken til dette er at grunnkretser har ulik størrelse og for små grunnkretser vil absolutte endringer bety mye for tilgjengeligheten. Ulik befolkning i de ulike grunnkretsene påvirker også hvordan endringer framstår i absolutte og relative tall. Figur 2: Endringer i interne gang- og sykkelturer fordelt på bydeler Figur 3: Relative endringer i interne gang- og sykkelturer fordelt på bydeler 6 av 34
2.3 Konklusjon Følsomhetsanalysen viser at endringer i tilgjengelighet for gående og syklende internt i grunnkretser gir små endringer totalt sett i modellen. I de enkelte grunnkretsene vil endret tilgjengelighet gi tydelige endringer i antall gangturer. Endringer i tilgjengelighet internt i grunnkretser påvirker i svært liten grad konkurranseforholdet mellom bil og gang/sykkel. Det finnes også en samvariasjon mellom økte gangturer og reduserte kollektivturer. Endringer i kollektivturer som følge av bedre tilgjengelighet for gående er større enn endringene for bil. 3 Metodebeskrivelse - Om kostnadsoverflate 3.1 Gåing og impedans Når vi forflytter oss på en overflate skjer det sjelden uten at en eller annen friksjon eller motstand er i sving og motvirker bevegelsen. Selv når gravitasjonen sørger for at vi rullende og motorløst kan akselerere i nedoverbakke er det krefter som virker imot, uansett hvilken transportmåte vi bruker. Dersom vi er gående kan underlaget og terrenghelningen spille en rolle for hva slags framdrift vi kan ha, og bortsett fra dette er omgivelsene nesten alltid rikelig bestykket med barrierer og hindre (Eriksen, 2015). Barrierene forekommer i form av fysiske eller tekniske skranker, altså objekter som for de fleste er vanskelige eller umulige å gå på, over eller gjennom (bygninger, gjerder, skrenter, vann). Barrierer er også juridisk/regulative (områder som ikke er tillatt for gående, som skuldre på motorvegen eller jernbanelinjer), sikkerhetsmessige (vegen med biltrafikk, som dermed er hindring eller i beste fall en forsinkende faktor for kryssende gangtrafikk) eller kulturelle/sosiale (man krysser nå engang ikke gjennom andres villahager selv om de skulle ligge plane, slette og uten gjerde på vegen til butikken). Til og med psykologisk baserte friksjoner trer i kraft, som når vi går nedover en gradvis brattere skråning: tyngdekraften gjør at det fysisk sett blir stadig lettere å øke hastigheten, men blir det bratt nok finner vi det likevel mest komfortabelt å bremse ned eller endre kurs til en retning som ikke går vinkelrett på kotene. Summen av de faktorene som virker mot bevegelsen, enten det dreier seg om fysiske faktorer eller ren komfort, kaller vi med et samlebegrep impedans. 3.2 Generalisert reisekostnad og modellering av gåing I bymessige omgivelser, sett bort fra helning og direkte sperrende fysiske beskrankninger, er det få arealtyper som direkte påvirker ganghastigheten rent fysisk. Unntakene er de som behandles særskilt i denne modellen, for eksempel de som omfatter vegetasjonsdekke med slik tetthet eller beskaffenhet at det er til hinder (skog). Noen arealtyper tillater gåing som sin primære funksjon (gangveger, fortau), andre gir anledning for gående å bruke arealet sammen med (og samtidig med) andre formål (vegkanter på veger med beskjeden trafikkmengde, parker, parkeringsplasser), eller atskilt i tid (fotgjengeroverganger). Når vi forsøker å modellere gåing er det, selv om vi velger et annet «modellmedium» enn lenke-node-nettverket, fortsatt slik at vi mener «klassisk» nytteteoretisk tilnærming er fruktbar (JdD & Willumsen, 2011), altså nyttemaksimering gjennom å minimalisere generalisert reisekostnad. Det er sjelden at vi regner direkte kostnader med til de egenskapene som gåing har, reisetiden er et kriterium som trolig har forrang. Men som det blir argumentert for over: generalisert reisekostnad kan også omfatte andre faktorer enn reisetid, bl.a. gjør vi som trafikanter umiddelbare overlegninger om komfort eller sikkerhet som kan få oss til å velge en lengre eller langsommere rute enn den rette linjen. I dette prosjektet prøver vi altså å finne anvendbare uttrykk for den impedansen som virker på gåing, som gjør at vi kan modellere optimalt rutevalg (og dermed avstand) mellom punkter, og over en overflate. 7 av 34
3.3 Kostnadsrasteret I litteraturen om bruk av raster-tilnærming for å modellere forflytning, er det absolutt vanligst å la et «kostnadsraster» representere overflaten vi beveger oss på (De Smith et al., 2007). Kostnaden er det samme som, eller en funksjon av impedansen, altså motstand mot bevegelse i en rastercelle, eller i overgangen fra en rastercelle til en annen. Impedansen i et gitt punkt er ikke lik i alle retninger fra punktet terrenghelning og uensartet arealdekke sørger for dette, i litteraturen betegnes kostnadsrasteret derfor som et «anisotropt raster». Det springende punktet i en slik metodikk er hva kostnadsverdiene i rastercellene representerer (altså hvordan de fortolkes), og følgelig hvordan data om arealtilstand og overflatedekke i praksis oversettes til kostnadsvekter. På dette har vi ikke funnet noen omforent løsning, men spredte kilder som dels baserer seg på empiriske observasjoner av rutevalg under ulike forutsetninger, dels rene gjetninger (støttet av verbal argumentasjon) av kostnadsvekter. De best funderte kostnadsvektene finner vi antakelig i materiale om sammenhengen mellom helningsforhold og ganghastighet. Temaet har vært gjenstand for studier over lang tid, basert på empirisk innsamlet materiale dels på naturlige og dels på «bymessige» underlag. «Naismith s rule» fra 1892 er blant de eldste, og på denne bygger bl.a. Toblers «Hiking function» (Tobler, 1993), samt formler gitt av Aitken (1977) og Langmuir (1984) som er variasjoner over samme tema. De to sistnevnte er det som er tatt inn i rutinebiblioteket til GIS-plattformen GRASS (GRASS Development Team, 2016), der funksjonen r.walk kalkulerer kumulativ kostnad ved forflytning over et kombinert kostnadsraster og terrengmodell («elevation raster»). For øvrig opererer denne funksjonen med standardverdier fra Langmuirs studier av hastighet, 5 km/t eller 1,39 m/s, for uhindret gåing på horisontal flate. Kostnadsrasteret, som i GRASS funksjons-formulering r.walk rett og slett er et tillegg i reisetiden gjennom hver rute, er altså å fortolke som et «straffetillegg» (penalty)-bidrag, avhengig f.eks av underlagets beskaffenhet. Funksjonen for å beregne tidsbruk avhengig av høydeforskjeller er (Aitken (1977) og Langmuir (1984)): hvor: T = a ΔS + b ΔH uphill + c ΔH moderate downhill + d ΔH steep downhill (1) T = tidsbruk a = ganghastighet på flatmark (0.72) b = ekstra tidsbruk i motbakke per høydemeter (6.0) c = redusert tidsbruk i nedoverbakke per høydemeter (1.998) d = ekstra tidsbruk i bratt nedoverbakke per høydemeter (1.998) ΔS = distanse (meter) ΔH uphill = høydeforskjell i motbakke (meter) ΔH moderate downhill = høydeforskjell i nedoverbakke (meter) ΔH steep downhill = høydeforskjell i bratt nedoverbakke (meter) Forskjellen mellom nedoverbakke og bratt nedoverbakke settes med en egen faktor, slope_factor som har en standardverdi på 21.25%. Dette betyr at hvis det blir brattere enn 21.25% vil det føre til økt tidsbruk enn det å gå på flatmark. Overgangen mellom tilstanden nedoverbakke og brakk nedoverbakke er helt brå, slik at hastighetsforskjellen mellom fall på 21.24% og fall på 21.26% blir betydelig. 3.3.1 Modifisering av r.walk-funksjonen i GRASS Funksjonen r.walk som benyttes til å beregne kostnader til et punkt fungerer slik at den beregner kostnader ut fra et eller flere startpunkt, og ikke inn mot disse punktene slik vi er avhengig av. For beregning av gangtid med friksjoner har ikke retning noe å si, men bakker blir motsatt slik at hvis vi benytter r.walk vil det være en fordel hvis destinasjonspunktet ligger på høyeste punkt. 8 av 34
For å løse dette måtte vi modifisere r.walk direkte i kildekoden som er tilgjengelig fra utviklerne av GRASS (GRASS Development Team, 2016). Disses modifikasjonene ble kompilert til en versjon av r.walk med nytt navn r.walk.inversed som er vedlagt applikasjonen for å benytte raster-metoden. 3.4 Hvor store er «penalty»-bidragene i kostnadsrasteret? I tabell 2 er det gjort anslag på hvor store tidstillegg som følger av ulike typer areal eller underlag. Normalt gis reisetiden av Aitken/Langmuirs formel (referert til over), altså uten «kostnadstillegg» såfremt underlaget lar seg forsere uhindret. Arealtyper eller objekter som ikke tillater ferdsel er gitt et høyt tillegg (her eksemplifisert med 9999 sekunder pr meter). Ved kryssing av veg med liten til moderat trafikk er det benyttet et forenklet estimat, anslaget er gjort slik: Gitt 2 felt, vegbredde 7,5 meter ved gjennomsnittlig ventetidstillegg på 10 sekunder blir tidstillegget ca 1,3 sekunder i kostnadsrasteret. Ventetidstillegget er selvsagt avhengig av trafikkvolumet. Her er benyttet et utvalg av observasjoner gjort av Eriksen (2015). Ventetidstillegget gis for øvrig kun til kommunale eller private veger, mens det for fylkes-, riks og europaveger antas at trafikken er høyere slik at kryssing bare skjer i gangfelt. Kryssing i gangfelt er gitt et tidstillegg på 0,7 sekund pr meter, basert på et analogt resonnement, men denne gangen et ventetidstillegg på halvparten: 5 sekunder. Dersom det også krysses over trafikkøy tildeles et tillegg på 4 sekunder pr meter trafikkøy. De øvrige kostnadstilleggene (skog 3 sek/m, bebygd areal utenom bygninger 0,5 sek/m, åpen fastmark (0,2 sek/m) og bygninger som tillater gjennomgående ferdsel (som kjøpesentre 1 sek/m) er i denne omgangen gjort skjønnsmessig. Ganghastighet er selvsagt ikke et mål som entydig bestemmes av forholdene på bakken eller i terrenget. Variasjonsbredden er stor, påvirket av trafikantenes alder, fysiske forutsetninger og turens formål. I tillegg spiller fotgjengerstrømmens «level of service», for eksempel trengsel uttrykt ved volum/kapasitetsforholdet, en rolle for valg av hastighet. En omfattende kilde til teoretiske og empiriske observasjoner om slike faktorer er (Timmermans, 2009). I tabell 2 vises det til kartlag i et FKB-datasett, og til standard attributter for slike data (i hht SOS-standarden). 3.5 Hva er resultatet fra en «least cost path»-kalkulasjon med denne modellen? Når applikasjonen settes opp med en terrengmodell («elevation raster») kalkuleres gangtid som en funksjon av terrenghelningen. Videre spesifiseres et kostnadsraster (som uttrykker tidstillegg pr meter rastercelle). Da framkommer resultatet av kalkulasjonen i form av kumulativ kostnad (identisk med kumulativ reisetid) fra et gitt sett av punkter til alle punkter i det dekkede området. Det er ikke urimelig å benytte hastighet (eller riktigere: den inverse verdien av hastighet) som et mål på motstanden eller «impedansen» som påføres gående. Resultatet av denne tankegangen er at vi ved å vekte forflytningen i en rastercelle med den inverse av cellens estimerte eller beregnede ganghastighet, ender opp med et uttrykk for gunstigste rute («least cost path») som er lik faktisk reisetid gjennom kostnadsrasteret. Dette er det samme som uttrykket for tilgjengelighet (accessibility) som i mange formuleringer av transportmodeller er den ønskede variabelen (Iacono et al., 2010). På aggregert form brukes reisetid som mål på «tilgjengelighet» (accessibility) eller konnektivitet (connectivity) i tilgjengelighetsbaserte bymodeller (som f.eks. den norske ATP-modellen). Dersom man ønsker modell-output i form av reiselengde (i stedet for reisetid), kan walk-funksjonen produsere et resultatraster som viser faktisk tilbakelagt sti, «least cost path», som i neste omgang kan måles ved simpelthen 9 av 34
Tabell 2: Vekting av kartlag i et FKB-datasett å la applikasjonen telle tilbakelagte rasterceller. Denne metoden vil imidlertid ha svakheter med hensyn til hva den kan brukes til i praktisk modellering. Et bedre uttrykk enn den faktisk tilbakelagte avstanden vil være å bruke kumulativ kostnad (og da transformert til avstand f.eks ved å dividere på en «standard hastighet» - som Langmuirs gjennomsnitt vist over. Grunnen til at dette vil være et bedre alternativ i modeller framkommer i eksempelet gitt under. Betrakt situasjonen gitt i figur 4. De to stiene A -> B i de to figurene er nøyaktig like lange, til tross for at det nederste rasteret har langt høyere kostnad på deler av arealet. Det skyldes simpelthen at det ikke finnes noen kortere eller «billigere» sti mellom A og B, selv om altså kostnadene varierer. Begge har avstand 10 celler, og i det øverste eksempelet er kumulativ kostnad også 10 enheter (f.eks sekunder). I det nederste er kumulativ kostnad 21 enheter. I en transportmodell som bare benytter avstandsvariable (i en valgalgoritme) kommer de to alternativene likt ut, mens i modeller som benytter kumulativ kostnad vil det øverste alternativet være mye gunstigere. 10 av 34
Figur 4: To like lange stier, men med ulik kostnad 3.6 Des nasjonspunkt inne i en bygning I avsnitt 3.5.2 på side 29 i Malmin et al. (2016) beskrives problemstillingen rundt destinasjonspunkter plassert inne i en bygning. Problemet er gjengitt fra rapporten i figur 5. Figur 5: Destinasjonspunkter inne i bygninger Bygninger har en kostnad som er svært høy med 9999 sekund per meter, vist i tabell 2 på linjen Bygning, AnnenBygning. Hvis destinasjonspunktet ligger inne i bygningen vil det fortsatt bli beregnet kostnader til destinasjonspunktene men hver meter som må gå gjennom ikke-gåbar bygning øker tidsbruken med 9999 sekund. Hvis det bare finnes ett destinasjonspunkt i en analyse vil dette ikke føre til noe problem, men hvis det er flere punkt, som vist i figur 5 hvor det er ulik avstand til bygningsvegg vil det være slik at minste kostnad fra et villkårlig punkt alltid vil gå til det punktet som har minst avstand til bygningsvegg. Dette løses på to måter. Den programteknisk enkleste metoden er å flytte alle destinasjonspunkt til et sted umiddelbart utenfor bygningen, som vist i figur 6 (også fra Malmin et al. (2016)). Dette krever imidlertid en god del manuelt arbeid med destinasjonspunktene og vil være mindre hensiktsmessig for store byområder som Bergen. Hvis destinasjonspunktet representerer en svært stor bygning bør man vurdere å flytte destinasjonspunktet til der hovedinngangen befinner seg. Programteknisk løser vi dette problemet ved å identifisere hvilke bygninger i shapefilen som sammenfaller med destinasjonspunkt. For å åpne opp for tilgang til denne bygningen settes vektingen for arealet til bygningen 11 av 34
Figur 6: Destinasjonspunkter flyttet ut av bygninger med 0 sekund per meter. Dette gjør at bygningen i praksis forsvinner og blir fullt gjennomgangbar. Metoden finner korteste rute til hvert destinasjonspunkt som vil være inne i bygningen og derfor blir det ikke mulig å ta snarveier gjennom bygningen for å komme til andre destinasjonspunkt. Se figur 7 for en illustrasjon av hvordan rastermetoden gjør bygninger med destinasjoner gjennomtrengbare. 12 av 34
Figur 7: (a) To destinasjonspunkter som ligger inne i bygninger klassifisert som ikke gangbare i rastermetodikken. (b) De to bygningene identifiseres og lagres som et eget raster der gangbarheten til dette rasteret settes til å gi ingen ekstra gangmotstand. (c) Det resulterende kostnadsrasteret der vi ser at de to bygningene ikke har bidratt til ekstra gangmotstand, dvs. man kan nå gå inn i disse bygningene for å nå destinasjonsmålene uten økt motstand eller tidsbruk. (a) (b) (c) 13 av 34
4 Brukerveiledning 4.1 Beskrivelse av metode I dette kapitelet gir vi en detaljert beskrivelse av hvordan et kostnads- og avstandsraster for å beregne gangavstander kan genereres ved hjelp av en applikasjon utviklet i dette prosjektet. Applikasjonen er skrevet i Python og utnytter ulike opensource-prosjekt for GIS-analyse som Grass GIS (GRASS Development Team, 2016) og GDAL (GDAL Development Team, 2016) for å utføre en rekke ulike GIS-operasjoner. Helt overordnet utføres følende operasjoner i applikasjonen: 1. Konvertere vektorkart for høydekurver til høyderaster 2. Konvertere ulike vektorkart som beskriver ulike gangareal til motstandsraster 3. Generere kostnads- og retningsraster til definerte destinasjonspunkt 4. Generere avstandsraster basert på retningsrasteret til destinasjonspunktene 5. Henter ut avstander fra definerte startpunkt til nærmeste destinasjonspunkt Vektorkart og rasterkart kan preparerer, manipuleres og vises i både ArcGIS og gratisprogrammet QGis (QGIS Development Team, 2009). Applikasjonen leveres med alle programpakker som en nødvendig for kjøring slik at installasjon av ekstra verktøy skal ikke være nødvendig. All kode i applikasjonen er gratisprogramvare og kan distribueres fritt. Se lisenstekst i katalogstrukturen. Applikasjonen beskrevet i denne brukerbeskrivelser har blitt utviklet for å være fleksibel og uavhengig av analyseområde, men det har ikke vært fokusert på brukervennligheten. Det kan derfor oppleser som krevende å sette opp et rasterprosjekt. Hvis det oppstår feilmeldinger er den sannsynlige årsaken til dette at det ikke er samsvar mellom filnavn i konfigurasjonsfilene og filnavn eller mappenavn på disk. 14 av 34
4.1.1 Illustrasjoner av rastermetodikkens oppbygning av kostnadsrasteret I dette avsnittet skal vi gi en intuitiv og kortfattet forklaring av hvordan rastermetoden bygger opp kostnadsrasteret. Rastermetoden tar inn de ulike kartlagene vist i Tabell 2 og kostruerer et binært raster per kartlag. For eksempel vil linjer i traktorvegsti linje -laget vist i med et eksempel i Figur 8(a) buffres med 1 meter og gi et resulterende raster vist i Figur 8(b). Her ser vi tydelig at man går fra kontinuerlige linjer til en pixel beskrivelse gjennom en rasterisering. Figur 8: Rasterisering av en sti. (a) (b) Alle shape-kartlagene rasteriseres på denne måten. Et annet, og større, eksempel er vist i figur 9(a) for ARTYPE 11, det vil si bebygget areal tillatt for ferdsel. I visningen av denne rasteriseringen i figur 9 er rastercellene vist med den tilhørender vektingen, 0.5 m/s ifølge tabell 2. Figur 9: Rasterisering av ARTYPE 11. (a) (b) 15 av 34
Disse rasteriserte lagene legges så lag på lag, og nye verdier overskriver eventuelt allerede eksisterende verdier. For eksempel, fysiske bygninger vist i figur 10(a) rasteriseres, legges lag på lag med rasteret i figur 9(b) og overskriver allerede eksisterende verdier, se figur 10(b). Figur 10: Rasterisering av bygningsshape og lag på lag med rasteret fra ARTYPE 11. (a) (b) Slik fortsetter metodikken å legge lag på lag. I figur 11(a) og 11(b) er i tillegg veger av vegkategori P og K lagt til rasteret vist i figur 10(b). Etter at alle kartlagene er rasterisert og lagt lag på lag har vi det resulterende kostnadsrasteret for videre bruk i rastermetodikken. Figur 11: Rasterisering av vegshape med vegkategori P og K og lag på lag med rasteret fra ARTYPE 11 og bygninger. (a) (b) 16 av 34
4.2 Forberedelser Applikasjonen er tilgjengelig på Statens Vegvesen e-rom sammen med andre ulike transportanalyseverktøy som RTM, NTM6 osv. https://www.vegvesen.no/e-room/4/eroom/ntp/ntp-transportanalyse/0_1b0b. Applikasjonen pakkes ut fra rastermetode.zip til et egnet sted på harddisken. I denne brukerveiledningen har vi brukt c:\rastermetode\ for å gjøre det enkelt, men det er ingen begrensninger på hvor applikasjonen kan kjøres fra eller navnet på mappen den kjøres fra. Det er bare nødvendig å pakke ut applikasjon ett sted på disken. Figur 12 viser filer som pakkes ut i applikasjonsmappen. Figur 12: Filer i applikasjonsmappen I tillegg til å pakke ut applikasjonen må det opprettes en mappe for selve prosjektet som skal analyseres. I denne brukerveiledningen har vi benyttet c:\rasterprosjekt\ men det er ikke nødvendig å kalle mappen for \rasterprosjekt, for eksempel kan man benytte rasterbergen eller hva som helst. I denne mappen må det opprettes ulike mapper som inneholder ulike kategorier inndata, vist i figur 13. Figur 13: Filer i prosjektmappen Etter kjøring av applikasjonen vil de dukke opp to nye mapper, \grassdata og \raster. Disse inneholder henholdsvis midlertidige beregningsfiler og resultat i form av ulike rasterkart. I de følgende avsnitt skal vi først beskrive hvordan man oppretter et raster-prosjekt, før vi beskriver hvordan rasterkartene kan beregnes i ved hjelp av applikasjonen. 17 av 34
4.3 Se e opp et raster-prosjekt Dette avsnittet beskriver hvordan de ulike inndata prepareres og tilrettelegges for applikasjonen. Som vist i figur 13 er det fire mapper som må fylles med data: destinasjoner inneholder en shapefil med destinasjonspunkt, for eksempel interessepunkt som butikker eller bussholdeplasser (Malmin et al., 2016). shapefiler inneholder alle shapefilene som beskriver ulike areal og muligheter og hinder for gange. I tillegg inneholder denne mappen en definisjonsfil som beskriver hvilke shapefiler som representerer de ulike typene areal, hinder og muligheter. hoydekurver inneholder en shapefil med høydekurver. Høydekurvene benyttes til å beregne ganghastighet som funksjon av helning. startpunkter inneholder shapefil med eventuelle startpunkt, for eksempel boliger, som det skal beregnes avstander fra. Hvis denne mappen er tom vil det ikke bli beregnet avstander fra punkt, men kun produsert avstands- og kostnadsraster. des nasjoner I destinasjoner-mappen legges en shapefil med punkter som representerer de destinasjonene som avstander skal beregnes til i det resulterende avstandsrasteret. I denne brukerveiledningen antar vi å være interessert i punktene definert i shapet destinasjoner.shp som f.eks. kan representere dagligvarehandel eller holdeplasser. Når shapet med interessepunkter er kopiert inn i destinasjoner ser mappen ut som i figur 14. Merk at shapet som legges inn i denne mappen kan ha hvilket som helst navn. Figur 14: Filer i mappen destinasjon shapefiler I denne mappen skal alle shapefiler som representerer arealbruken legges. I utgangspunktet finnes det kun en fil her _shapefiler.txt. Denne filen er en tekstfil som vist i figur 15 og en fil som benyttes som utgangspunkt finnes og kan kopieres fra mappen rastermetode. Denne filen blir brukt for å fortelle applikasjonen hvilke arealbruksfiler den skal lese, attributter den skal rasterisere, hvor mye hvert enkelt shape skal buffres, og hvilken motstand vi ønsker å tilegne hver type arealbruk. De ulike arealbruksdata er tilgjengelig fra FKB (Felles KartdataBase). For hver linje i denne filen er det kun de to første kolonnene delt med semikolon brukeren trenger å forholde seg til i første omgang (Men denne filen åpner for muligheten til å definere egne arealtyper, motstander m.m.). I først linje vil vann_flate fortelle oss at vi må legge en shapefil med innhold vann og at det må være et flateshape til 18 av 34
Figur 15: Innhold i _shapefiler.txt mappen shapefiler. For hvert området man vil studere kan disse filene ha ulike navn, derfor må andre kolonne i _shapefiler.txt definere navnet på shapet som beskriver denne linjen med arealbrukstype. I figur 16 vises hvordan mappen ser ut når shapet med vannflater er lagt til. Figur 16: Vann flateshapet lagt til shapefiler -mappen. Figur 17 viser hvordan vi kan endre shapefilnavnet (se rød ellipse) i _shapefiler.txt for å vise til et annet filnavn for vannflateshape. Figur 17: _shapefiler.txt med korrekt henvisning til vann flateshapet Slik fortsetter vi å legge til shapefiler i shapefiler-mappen helt til alle linjene i _shapefiler.txt er riktig utfylt. En full shapefiler-mappe er vist i figur 18 med tilsvarende ferdigutfylt _shapefiler.txt vist i figur 19. Filen _shapefiler.txt gir muligheten for at man selv kan definere egne arealbruksområder som skal være med i prosjektet. Man kan legge til en ekstra linje før STOPP;, eller man kan definere egne attributter som skal tillegges allerede eksisterende filtyper. Hver linje er bygget opp som følger: Først navnet på type arealbruk, deretter filnavnet. Deretter defineres attributter som skal inngå som en gruppe med samme egenskap ved hjelp av standard SQL-spåk. Her kan flere grupper dannes, og de ulike gruppene skilles med semikolon. Deretter kommer motstanden til de definerte gruppene i klammeparentes [], der komma inne i klammeparentesen skiller vektene fra hverandre. Det må her være definert like mange vekter som grupper. Til slutt defineres bufferavstand også ved hjelp av klammeparenteser og komma. Rekkefølgen på linjene i _shapefiler.txt definerer hvilken rekkefølge de ulike arealbrukslagene benyttes for å konstruere et gangbarhetsraster. For eksempel må vann komme før veger i listen siden vegene kan være på en bro over vann. Den rekkefølgen av shape som finnes i den standard _shapefiler.txt filen har vi valgt å legge alle gangbare veger og stier som det øverste kartlaget for å være sikker på at disse ikke overskrives av gjerder, bygninger, trafikkerte veger etc. 19 av 34
Figur 18: Alle shape lagt til shapefiler-mappen. Figur 19: _shapefiler.txt med korrekt henvisning alle shape. 20 av 34
startpunkter På samme måte som for destinasjoner-mappen inneholder startpunkter et shape med punkter som representerer steder man er interessert i å regne avstanden fra, se figur 20 for et eksempel. Hvis denne mappen er tom blir det ikke beregnet noen avstander fra startpunkt, slik at denne mappen er ikke påkrevet for å generere avstandsraster. Hvis shapefilen inneholder et datafelt som beskriver hvilket grunnkretsnummer hvert startpunkt befinner seg i, vil applikasjonen beregne gjennomsnittlige avstander for hver grunnkrets. Figur 20: Shapefil med punkt i startpunkter-mappen hoydekurver Mappen ved navn hoydekurver skal inneholde en shapefil med høydekurver for modellområdet. Kun et høydekurveshape skal legges her, og dette shapet definerer det området det blir lage raster for. Det vil si, dersom arealbruksfilene er definert på mindre eller større områder enn høydekurve-shapet er det allikevel området som er definert i høydekurver som brukes. Det er viktig å merke seg at dette området bør være så rektangulært og lite skjevt som mulig. Det vil i applikasjonen defineres en rektangulær og ikke-skjev boks rundt høydekurve-shapet, og dersom store områder i denne boksen ikke inneholde høydekurver vil beregningstiden bli svært lang. Figur 21 viser et høydeshape lagt i hoydekurver-mappen Figur 21: Korrekt oppsatt hoydekurver-mappe Vi har nå satt opp et fullstendig rasterprosjekt og er klare for å generere raster ved å benytte applikasjonen. 21 av 34
4.4 Kjøre applikasjon for å generere raster og beregne avstander Applikasjonen for å generere ulike raster for å beskrive gangavstander er bygget opp av en samling batch-filer og Python-script. Selve applikasjonen startes ved å kjøre rastermetode.bat men denne batch-filen krever også en oppstartsparameter. Derfor kan ikke applikasjonen kjøres ved å dobbelklikke på filen i utforskeren. Parameteren som må gis inn er sti til rasterprosjektet. Applikasjonen har følge kommandosyntaks: rastermetode.bat datadir [grunnkrets] datadir = mappe med alle inndata som beskrevet i avsnitt 4.3 grunnkrets = (opsjon) navn på datafelt i shapefilen i startpunkter som inneholder grunnkretsnummer Hvis det oppgis et feltnavn for grunnkrets vil det bli produsert en csv-fil som inneholder gjennomsnittlige avstander for hver grunnkrets. Hvis det ikke oppgis et feltnavn vil ikke denne csv-filen produseres. For å starte applikasjonen må brukeren åpne kommandokonsollen i Windows (ctrl+r cmd.exe), gå til mappe for applikasjonen og skrive for eksempel: >rastermetode.bat c:\rasterprosjekt Figur 22 viser hvordan oppstart av applikasjonen ser ut i konsollen til Windows7. Figur 22: Oppstart av applikasjon i kommandokonsoll Når applikasjonen starter vil følgende prosesser foregå: 1. Starte opp Grass GIS 2. Konvertere høydekurver til rasterkart (surf.contour) 3. Konvertere de ulike arealbruksdataene til rasterkart 4. Sette sammen alle arealbruksrasterne til raster for gangbarhet 5. Beregne kostnads- og retningsraster til destinasjonspunkt (r.walk.inversed) 6. Beregne avstandsraster til destinasjonspunkt basert på retningsrasteret 7. Eventuelt finne avstander fra startpunkt til destinasjonspunkt og etablere ny shapefil med startpunkt som inneholder korteste avstand til det destinasjonspunkt som har raskest gangtilgjengelighet. 8. Eventuelt beregne gjennomsnittlig internavstand for hver grunnkrets. Hvis det skal beregnes avstander fra nye startpunkt i samme kartgrunnlag som finnes i rasterkartene er det ikke nødvendig å kjøre hele prosessen om igjen. For å beregne avstander fra nye startpunkt holder det å kjøre Python-scriptet finnavstander.py. Kommandoargument til denne prosessen er sti til raster-prosjektet. Husk backslash-tegn til slutt i stinavnet: Python finnavstander.py c:\rasterprosjekt\ Hvis Python ikke er installert fra før, følger det en kjørbar Python-installasjon under grass_gis_7.0.5-mappen. 22 av 34
5 Tolking av resultater I dette kapitelet skal vi se på et utsnitt av Bergen og beskrive det som genereres fra applikasjonen. Utsnittets høydekurver er vist i figur 23, og alle genererte raster blir lagt i raster-mappen som.tif-filer. Figur 23: Høydekurver for et utsnitt i Bergen For det første genereres det et raster ved navn hoyderaster.tif. Dette rasteret representerer en rasterisering av høydekurvene, der verdiene i rasterceller uten høydekurver blir satt ved å interpolere nærliggende høydekurver ved hjelp av funksjonen r.surf.contour i GRASS. I figur 24 er dette rasteret vist for vårt valgte utsnitt av Bergen. Figur 24: Rasteriserte høyder for et utsnitt i Bergen Videre genereres det et raster for hvert av kartlagene som defineres i _shapefile.txt-filen. Dette er rastere med verdien 0 og 1 i hver node, der verdien 1 indikerer at vi her har et element av den typen vi studerer. F.eks. for 23 av 34
kartlaget veg_flate lages et kartlag som inneholder vegkategoriene E, R, og F, og et kartlag som inneholder vegkategoriene K og P. For et utsnitt av Bergen er disse vist i henholdsvis figur 25(a) og 25(b) Figur 25: Binære rasterkart for; (a) vegkategoriene E, R, og F, og (b) vegkategoriene K og P. (a) (b) De binære rasterene som er omtalt over, sammen med de oppgitte vektene i _shapefile.txt-filen, danner grunnlaget for opprettelsen av rasteret ved navn kostnadsraster.tif. Dette rasteret inneholder kostnaden det tar å krysse hver rastercelle uten å ta hensyn til høydeforskjellen mellom cellene (dette er informasjon som foreløpig kun ligger i hoyderaster.tif-filen omtalt over). Kostnadsrasteret for vårt eksempel er vist i figur 26 Figur 26: Kostnadsraster for et utsnitt i Bergen Ved hjelp av r.walk.inversed-funksjonen i GRASS brukes kostnadsrasteret, høyderasteret og destinasjonspunktene til å generer rasteret akkumulert_kostnadsraster.tif. Dette rasteret viser kostnaden man trenger for å bevege seg fra all punkter i rasteret til nærmeste destinasjonspunkt (husk: destinasjonspunkter legges i destinasjoner-mappen). I figur 27(a) viser resultatet fra beregninger på utsnittet i Bergen for to tilfeldig valgte 24 av 34
destinasjonspunkter vist som røde punkter, mens figur 27(b) viser et utsnitt nærmere de to destinasjonspunktene. Figur 27: Akkumulert kostnadsraster for; (a) hele utsnittet og (b) et nærmere utsnitt rundt destinasjonspunktene vist som røde punkter. (a) (b) GRASS-funksjonen r.walk.inversed returnerer også rasteret retningsraster.tif der det i hver celle er oppgitt hvilken retning man må gå for å nå frem til nærmeste destinasjonspunkt med minst mulig kostnad. Dette rasteret er vist i figur 28 for vårt utsnitt i Bergen. Figur 28: Retningsraster for et utsnitt i Bergen Det siste rasteret er i raster-mappen er distanseraster.tif som viser avstanden det er til nærmeste destinasjonspunkt dersom ruten med minst kostnad benyttes. Dette rasteret er generert ved å forflytte seg i retningsrasteret og langs de oppgitte rutene og telle opp avstanden som gåes. Distanserasteret for vårt utsnitt av Bergen er vist i figur 29. I dette rasteret ser vi noen tydelige skiller i avstandene. For eksempel ser vi et tydelig skille langs elven. På motsatt siden av elven i forhold til destinasjonspunktene må man gå bort til en av de to bruene for å kommer 25 av 34
Figur 29: Distanseraster for et utsnitt i Bergen over, mens dette er ikke nødvendig på den andre siden av elven og avstanden blir derfor merkbart kortere. Andre barrierer, enten ugjennomtrengelig som vann, eller bare vanskelig gjennomtrengende barriere, kan også resultere i slike skarpe skiller i avstanden. Husk at det er kostnaden ved å gå som bestemmer rutene, og dette fører til at to nærliggende celler i det akkumulerte kostnadsrasteret vil ha omtrent samme verdi. Disse nærliggende cellene kan derimot ha svært ulike ruter frem til nærmeste destinasjonspunkt, og derfor kan de to nærliggende cellene i distanserasteret ha svært forskjellig verdi. Det akkumulerte kostnadsrasteret vil være mer jevn i utseende fordi kostnaden ved å gå er det som bestemmer rutevalget for gange. Distanserasteret derimot er avledet fra den akkumulerte kostnaden langs ruta, og dersom to nærliggende celler har forskjellig rute viser avstanden avledet fra og her kan rutevalgene være signifikant forskjellige selv for celler nære hverandre. 5.1 Eksempel: ByGarasjen i Bergen I dette avsnittet skal vi eksemplifisere rutevalgene som produseres av rastermetodikken ved å se på noen helt bestemte start og sluttpunkter i området nær ByGarasjen Bergen. Rutevalgene som vises i dette eksempelet er generert ved hjelp av funksjonen r.drain i GRASS, og er ikke en del av metodikken utviklet i dette notatet. I figur 30 vises et eksempel der vi bruker rastermetodikken til å bergene gåavstander til destinasjonen representert ved en rød prikk i figuren. ByGarasjen i Bergen er vist med grønt omriss, og siden dette er en bygning med med BYGGTYP_NB=321, se tabell 2, antar vi at det er mulig å gå gjennom denne, men med en høyere motstand enn for eksempel å gå på fortauet. Rutevalget til det røde destinasjonspunktet er vist for tre startpunkter vist som gul, grønt og blått punkt. Rutene er vist med røde linjer, og for gult og blått startpunkt velges en rute rundt ByGarasjen, mens for grønt punkt velges et alternativ der ruten legges igjennom bygget. Dette er et resultat av at ruten velges ved å finne det alternative med minimal kostnad, som generelt sett ikke vil være den samme som å velge korteste distanse. Legg spesielt merke til at fotgjengerovergangene velges for å krysse de trafikkerte vegene som ligger mellom startpunktene og ByGarasjen, samt at fortauene benyttes (hvit farge) i størst mulig grad. Figur 31 viser med piler hvilke retninger som må gås for å komme til destinasjonspunktet i figur 30. Bakgrunnen i figuren viser utdrag fra det akkumulerte kostnadsrasteret. Gråtonene er satt opp slik at eventuelle vannskiller i 26 av 34
Figur 30: Tre ruter fra ulike destinasjoner utregnet ved hjelp av rastermetodikk kostnadsrasteret vises. Inne i gul sirkel vises et slik vannskille som indikerer gangruter møt øst rundt et hinder samt hvor det lønner seg å gå rundt hinderet til venstre eller høyre i retning øst. Rød sirkel viser at det finnes et vannskille midt på fotgjengerovergangen. Dette viser at for alle som kommer fra nordvest og skal rundt ByGarasjen vil det være raskest å gå rundt slik som fra gult startpunkt i figur 30. Startpunkt grønt i samme figur kommer fra sørøst og dermed på andre siden av vannskillet i rød sirkel og vil derfor bevege seg gjennom ByGarasjen. Ved å justere hastighetsstraffen som ligger inne for å gå gjennom kjøpesenter vil vi kunne justere hvor dette vannskillet oppstår. Det akkumulerte kostnadsrasteret er dermed et viktig verktøy for å evaluere gangruter. Figur 31: Retninger i det akkumulerte kostnadsrasteret for destinasjon øst for ByGarasjen Figur 30 viser at gangruten gjennom ByGarasjen går korteste veg gjennom bygningen. Vi har ingen data som beskriver hvor dører og andre åpninger befinner seg. Hvis slike data hentes inn eller opprettes manuelt for viktige bygninger kan vi legge dette inn i opprettelsen av kostnadsrasteret. For å gjøre dette må det opprettes en 27 av 34
ugjennomtrengelig barriere rundt bygningen alle andre steder enn der det er dører. Tilsvarende kan det legges inn barrierer som beskriver hindringer på grunnplan inne i selve bygningene. Dessverre finnes ikke slike beskrivelser i det offentlige datakildene beskrevet her, men i prinsippet er det ingenting i veien med å legge inn slike data manuelt. 6 Bruk i RTM Applikasjonen for å beregne avstander basert på ulik type arealbruk i et avstandsraster kan benyttes til å hente ut avstander fra alle boligpunkt til ulike interessepunkter. Dette kan benyttes både til å beregne internavstander i en grunnkrets eller avstander til holdeplasser. Fokus i dette prosjektet er beregning av internavstander for gående. Med internavstand menes den gjennomsnittlige avstanden alle grunnkretsinterne reiser tilbakelegger. I Malmin et al. (2016) beskrives at vi anser interne reiser å gå mellom boliger og ulike interessepunkt som butikker, skoler og barnehager. Interessepunktene behøver nødvendigvis ikke å befinne seg i samme grunnkrets som det skal beregnes internavstand for, men bør være i noen lunde nærhet. Det må ikke oppstå en situasjon hvor avstanden til nabogrunnkretser langs nettverket er kortere enn internavstanden. Applikasjonen beregner avstander til det nærmeste destinasjonspunktet. I en grunnkrets vil derfor ulike boliger få beregnet avstander til ulike destinasjoner uten at dette behøver å være noe problem. For å beregne gjennomsnittlig avstand for en grunnkrets kan følgende prosedyre benyttes: 1. Identifisere destinasjonspunkter som beskrevet i Malmin et al. (2016). 2. Legge inn boliger som startpunkt. Det er viktig at dette karttemaet også inneholder grunnkretsnummer 3. Kjøre applikasjonen 4. Beregne gjennomsnittlig avstand for hver grunnkrets 5. Etablere internavstandfil for RTM og legge inn de gjennomsnittlige avstandene for gange Beregning av gjennomsnittlig internavstand bør fortrinnsvis gjøres ved vektet gjennomsnitt mot befolkning. Imidlertid er tilgang til datasett som inneholder boligpunkt med befolkning svært begrenset. Det er i dette prosjektet ikke laget noen egen applikasjon for å beregne gjennomsnittlige internavstander og overføre disse til RTM. Dette er gjennomførbart ved hjelp av pivot-tabeller i Excel eller å skrive et script i Python eller Cube Voyager. Figur 32 viser et utdrag fra internavstandfilen til RTM for noen grunnkretser i Bergen. Databasetabellen består av grunnkretsnummer og internavstander i kilometer for ulike transportmiddel. Internavstand for kollektivtrafikk ligger inne av historiske årsaker, men påvirker ikke resultatet av modellkjøringen siden det aldri vil forekomme interne turer med kollektiv. 6.1 Endring i modellfaktorer En av inndatafilene til etterspørselsmodellen Tramod_By, modellfaktorer.txt inneholder ulike forutsetninger for kjøringen, blant annet om minste og største internavstand for bil og gang/sykkel. Dette er beskrevet på side 122 i Rekdal et al. (2013). Årsaken til at disse verdiene ble satt er at inndata av og til inneholder feil og systemet tar høyde for dette. Minste grunnkretsinterne avstand for gange og sykkel var satt til 0,5 km. Dette er langt høyere enn de internavstandene som beregnes med denne metoden i by. Det er dermed spesielt viktig når internavstander beregnet med denne metoden skal brukes i modellen så må minste internavstand justeres ned til 0. I eksemplet i neste avsnitt har denne minsteavstanden blitt justert. 28 av 34
Figur 32: Utdrag fra internavstandfilen i RTM 7 Eksempel på beregning av internavstand for grunnkretser i Bergen 7.1 Grunnkretser I dette eksempelet har vi gjennomført en beregning av internavstander for et utvalg grunnkretser på Damsgård: 12012004 12012005 12012006 12012007 Figur 33 viser kart over de utvalgte grunnkretsene. Figur 33: Utvalgte grunnkretser for analyse i RTM. 29 av 34
7.2 Des nasjonspunkt Destinasjonspunkt for beregning av internavstand er adressepunkt med arbeidsplasser med utvalgte nace-koder (Malmin et al., 2016, p. 17): 47.10-47.29: butikker 85.2: grunnskoler 53.1: post 88.91: barnehager Vi har i dette prosjektet ikke hatt tilgang til bedriftsdata. I dette eksemplet har vi manuelt funnet to destinasjonspunkt som er nærbutikker. Plasseringen av butikkene er vist i figur 34. Figur 34: Utvalgte grunnkretser med dagens butikker for analyse i RTM. Rimi Damsgård Kiwi Svingen 7.3 Boliger som startpunkt Internavstand bør være et vektet gjennomsnitt mellom avstand og befolkning i hvert boligpunkt men dette datasetter har ikke vært tilgjengelig. Vi må dermed regne gjennomsnittlig internavstand uvektet mot befolkning. Punkt som representerer bygninger i de fire grunnkretsene ble påkodet grunnkretsnummer og lagret som ny fil. Boligpunkt i denne analysen er vist i figur 35. 30 av 34
Figur 35: Boligpunkter i utvalgte grunnkretser. 7.4 Beregning av gjennomsni lig internavstand Et rasterprosjekt ble satt opp etter oppskrift fra avsnitt 4.3 og med utklipp for området vist i figur 33. Applikasjonen ble kjørt for dette prosjektet og resultatet er vist i tabell 3. Tabell 3: Gjennomsnittlig internavstand for utvalgte grunnkretser Grunnkrets Median Mean n 12012004 319 311 268 12012005 348 351 128 12012006 182 183 174 12012007 439 429 211 7.5 Bruk av RTM l å beregne virkninger av et ltak De nye internavstandene som ble beregnet i tabell 3 ble benyttet til å beregne en ny basisberegning for delområdemodell Bergen i RTM. Vi ønsket å finne hvordan RTM beregner virkninger av å legge inn to nye destinasjonspunkter, vist i figur 36. En ny kjøring av rastermetoden med fire destinasjonspunkt ble gjennomført og vi fikk beregnet ny internavstand for de fire grunnkretsene med fire destinasjonspunkt, vist i tabell 4: Tabell 4: Gjennomsnittlige internavstander med et nytt destinasjonspunkt Grunnkrets 4 punkt 2 punkt 12012004 172 311 12012005 192 351 12012006 145 183 12012007 289 429 For å være sikker på at disse butikkene ligger inne modellen og er tilgjengelige internt i hver grunnkrets har vi endret sonedata for de fire utvalgte sonene ved å legge 20 publikumsattraktive arbeidsplasser i hver 31 av 34
Figur 36: Utvalgte grunnkretser med dagens og to nye butikker for analyse i RTM. sone under koden A31VH og FEMINT (Rekdal et al., 2013, s. 146). Samme sonedata ble benyttet i både før- og ettersituasjonen for å sikre at det ble beregnet virkninger av endret gangavstand og ikke endring av arbeidsplassdata. I tillegg til å endre sonedata ble internavstand for bil satt til 500 meter som alle de fire sonene. Dette for å unngå at bil får kortere internavstand enn gange og sikre at grunnkretsen får en viss gangandel. Resultatet av de to RTM-kjøringene for interne turer i de fire grunnkretsene er vist i tabell 5. Tabell 5: Resultater fra kjøring med RTM, turproduksjon fra grunnkretser med gange og sykkel 2 punkt 4 punkt Grunnkrets Bil GangSykkel Bil GangSykkel Endring (%) 12012004 29.01 111.52 28.96 133.59 20 12012005 11.56 46.31 11.54 59.36 28 12012006 12.76 55.01 12.76 57.46 4 12012007 9.62 27.03 9.61 33.30 23 Tabellen viser at det blir beregnet en viss økning i antall gang- og sykkelturer for de utvalgte grunnkretsene. I absoluttverdi er ikke endringene store, men prosentvis øker antall turer med en variasjon fra 4 til 28 prosent. Antall internturer med bil går ubetydelig ned. 8 Oppsummering og forslag l videre arbeid Applikasjonen som er utviklet i dette prosjektet vil kunne fungere til å beregne gangavstander mellom to punkter i et kartområde. Det er mange muligheter til hvordan denne avstanden kan benyttes videre. I transportmodeller vil metoden kunne benyttes til å beregne grunnkretsinterne avstander eller tilgjengelighet til kollektivsystemet. En utfordring med metoden er at avstand beregnes hele veien mellom to punkt, og hvis startpunktene befinner seg inne i en bygning vil kostnaden ved å komme seg ut av bygningen være svært høy. Dette fordi tilleggstiden for hver rastercelle inne i en bygning har verdien 9999 sekund per meter. Når vi beregner avstander benyttes ikke denne straffen siden vi kun benytter retningsrasteret til denne oppgaven. Metoden som er beskrevet i denne rapporten kan kun benyttes til å beregne gangavstand såfremt start- eller 32 av 34