GIS för transportlogistik – förutsättningar och möjligheter · Referat Detta examensarbete undersöker förutsättningarna för att använda sig av GIS (geografiska informationssystem)

GIS för transportlogistik – förutsättningar och möjligheter

Björn Andersson

TRITA-NA-E05152

Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science 100 44 Stockholm Royal Institute of Technology SE-100 44 Stockholm, Sweden

GIS för transportlogistik

– förutsättningar och möjligheter

Björn Andersson

TRITA-NA-E05152

Examensarbete om 20 poäng inom fristående kurs i datalogi

Stockholms universitet år 2005 Handledare på Nada var Kjell Lindqvist

Examinator var Stefan Arnborg

Referat Detta examensarbete undersöker förutsättningarna för att använda sig av GIS (geografiska informationssystem) och geografisk informationsvetenskap vid transportlogistiska beräkningar i form av nätverksanalys och ruttplanering. Arbetet har delats upp i tre delar. Dels behandlas teknologin GIS och dess förutsättningar att fungera som stöd vid transportlogistisk analys. Därefter behandlas just den specifika GIS-plattform som används som referens. Eftersom kopplingen mellan applikation och underliggande databas är av största betydelse för prestanda beskrivs till sist även den databas som använts i examensarbetet. Som referensplattform används en betaversion av ESRI:s ArcGIS 9.1 med tillägget Network Analyst. Underliggande databas är Tele Atlas MultiNet.

Syftet med arbetet är att ge övergripande kunskaper i GIS utifrån ett transport-logistiskt perspektiv. Det ska kunna användas som ett underlag för framtida beslut om eventuell införskaffning och implementering av en GIS-plattform för transportlogistiska analyser och ruttplanering.

De transportlogistiska beräkningar som användes för utvärdering av GIS-plattformen utfördes i samband med ett praktiskt fall i Falköping kommun. Fallet undersöker förutsättningarna för en omstrukturering av förnödenhets-transporter inom kommunen.

GIS som teknologi och verktyg visade sig innehålla goda möjligheter för transportlogistiska analyser. Det kan användas vid all typ av planering, strategisk, taktisk och operativ. Till dess större fördelar kan räknas den tydliga visualiseringen av resultat. GIS-plattformen som användes visade sig fungera väl i kombination med databasen. Plattformen innehåller en stor mängd funktioner som ger flexibilitet men som kräver en hel del av dess användare. För att kunna nyttja all funktionalitet krävs goda GIS-kunskaper kombinerat med lika goda kunskaper inom transportlogistik och datastrukturer. En an-passning av plattformen kan vara att föredra för att förenkla handhavande och gränssnitt.

Det underliggande topologiska nätverket är grunden till all nätverksanalys. Nätverket bygger i sin tur på den databas systemet arbetar mot. Möjligheterna till nätverksanalys är därför starkt kopplade till den information som databasen ger. Här finns svårigheter i att som användare av databas och GIS-plattform hitta och tolka informationen och sedan använda den på rätt sätt. Detta är något som bör vara konfigurerat och klart vid leverans och implementering av plattformen hos en organisation.

Nyckelord: GIS, geografiska informationssystem, geografisk informationsvetenskap, transportlogistik, nätverk, ruttplanering, Network Analyst, Tele Atlas

GIS for Transport Logistics – Conditions and Possibilities

Abstract This Master's thesis investigates the conditions for using GIS (geographical information systems) and GIScience when performing transport logistic analysis using networks and route planning. The work is split into three parts. First the technology GIS is discussed and its conditions for supporting transport logistic analysis. Then, the specific GIS-platform used in the thesis, is discussed. Finally, since the connection between application and the under-lying database is of the outmost importance for performance, the database used for this thesis is discussed. The platform used as a reference is a beta version of ESRI:s ArcGIS 9.1 with extension Network Analyst. Underlying database is Tele Atlas MultiNet.

The purpose of the project is to give comprehensive knowledge in GIS in a transport logistic perspective. It could be used as the basis for decisions in future concerning possible obtaining and implementing of a GIS-platform for transport logistic analysis using networks and route planning.

The transport logistic calculations used for evaluating the GIS-platform were performed as a practical case in Falköping municipality. The case investigates the conditions for restructuring the transports of everyday commodities in Falköping municipality.

GIS, as technology and tool, turned out to contain good possibilities for transport logistic analysis. It is useful at all levels of planning, strategic, tactical and operative. One of its greater benefits is clear and informative visualization of results. The GIS-platform, used in the thesis, turned out to be well-function in combination with the database. The platform contains a large amount of functions that give flexibility but take a lot of the user. To benefit by all functionality it takes good knowledge in GIS combined by good knowledge in transport logistic and data structures. Customizing the platform is preferred to simplify the management and the user interface.

The underlying topological network is the foundation for all network analysis. The network is built on the database that the system is operating on. The possibilities to network analysis are therefore strongly connected to the information that the database can deliver. Here are some difficulties. As a user of the database and the GIS-platform, it can be difficult to find and interpret the information and then use it in the right way. This task is something that should be done at the time of delivery and implementing of the platform within an organization.

Keywords: GIS, geographic information system, GIScience, transport logistic, network, route planning, Network Analyst, Tele Atlas

Förord Denna rapport utgör dokumentation över ett examensarbete i datalogi om 20 poäng som är utfört under vårterminen 2005. Arbetet leder till en magister-examen i datalogi och examineras av institutionen för numerisk analys och datalogi (Nada) vid Stockholms universitet. Huvuddelen av arbetet har utförts på Chalmers tekniska högskola i Göteborg under handledning av Jonas Tornberg och uppdragsgivare är Falköping kommun.

Examensarbetet är ett av fyra som genomförts inom ramarna för ett projekt som drivs av Falköping kommun under namnet Samordning av logistiska resurser inom transportområdet. Övriga examensarbeten inom projektet är:

Guy Humberto (2005), Datorstödd transportresursplanering – En GIS-studie, Examensarbete på Chalmers, 20 poäng.

Andersson Maria, Thorén Maria (2005), Kriterier för en samordningscentral – En fallstudie på Falköpings kommun, Examensarbete på programmet Industriell ekonomi, C-nivå 20 poäng.

Aronsson Madelene, Häggmark Anna (2005), Samordning av livsmedels-transporter ur mottagarens perspektiv – En fallstudie på Falköpings kommun, Examensarbete på programmet Industriell ekonomi, C-nivå 20 poäng.

Jag vill tacka Jonas Tornberg på Chalmers tekniska högskola som varit min handledare på plats, ställt upp med utrustning och bidragit med kunskaper inom GIS där mina egna inte räckt till. Tack också till Kjell Lindqvist, min handledare på Nada i Stockholm. Tills sist även ett tack till övriga som ställt upp med nödvändig information för arbetets genomförande.

INNEHÅLL 1 INLEDNING ...................................................................................................................1

1.1 Bakgrund .................................................................................................................1 1.2 Syfte ........................................................................................................................9 1.3 Problembeskrivning.................................................................................................9 1.4 Avgränsningar .......................................................................................................10 1.5 Metod ....................................................................................................................10 1.6 Läsanvisning för rapporten....................................................................................12

2 GIS .................................................................................................................................13 2.1 Geografisk information och dess egenskaper ........................................................13 2.2 Modellering och digitalisering av geografisk information ....................................13 2.3 Digitaliserad geografisk information.....................................................................14 2.4 Topologiska datastrukturer....................................................................................16 2.5 Topologiska nätverk för nätverksanalys................................................................17 2.6 Ruttberäkningar i transportsystem – definitioner och begrepp.............................17 2.7 Geokodning – adressättning ..................................................................................19

3 ARCGIS OCH NETWORK ANALYST.....................................................................20 3.1 ESRI ......................................................................................................................20 3.2 ArcGIS - plattformen.............................................................................................20 3.3 Lagringsstrukturer och datakällor..........................................................................23 3.4 Den rumsliga domänen..........................................................................................26 3.5 Adressmatchning i ArcGIS ...................................................................................26 3.6 Network Analyst ...................................................................................................27 3.7 Nätverksdataset .....................................................................................................30 3.8 Ruttberäkningar i Network Analyst.......................................................................35

4 VÄGDATABAS ............................................................................................................38 4.1 Andra vägdatabaser ...............................................................................................38 4.2 Tele Atlas ..............................................................................................................40

5 RUTTBERÄKNINGAR MED ARCGIS 9 NETWORK ANALYST OCH TELE ATLAS MULTINET...............................................................................49

5.1 Bakgrund ...............................................................................................................49 5.2 Arbetsflöde ............................................................................................................50 5.3 Partitionering och konfigurering av vägdatabas ....................................................51 5.4 Skapande av geodatabas........................................................................................53 5.5 Adressmatchning...................................................................................................56 5.6 Konfigurering av nätverksdataset..........................................................................58 5.7 Beräkningar och analys .........................................................................................60 5.8 Kvalitetskontroll av resultat ..................................................................................63 5.9 Applikationsanpassning.........................................................................................64

6 APPLIKATIONSUTVECKLING I ARCGIS 9 DESKTOP.....................................66 6.1 Översikt .................................................................................................................66 6.2 Skräddarsy gränssnitt ............................................................................................66 6.3 Modelbuilder .........................................................................................................67 6.4 Att skriva makron i VBA ......................................................................................68 6.5 Att skriva komponenter och tilläggsmoduler i något COM-kompatibelt språk.....69

7 RUTTPLANERINGSYSTEM PÅ MARKNADEN ...................................................70 7.1 Typer av transportplaneringssystem......................................................................70 7.2 Exempel hämtade från transportföretag ................................................................71

8 DISKUSSION OCH SLUTSATSER...........................................................................74 8.1 GIS som teknologi för transportlogistisk analys ...................................................74 8.2 Vägdatabasen ........................................................................................................76

8.3 ArcGIS 9.1 med Network Analyst ........................................................................76 8.4 Plattformen – Network Analyst och Tele Atlas MultiNet .....................................77 8.5 Transportföretags användande av GIS ..................................................................79

REFERENSER .......................................................................................................................80

BILAGOR A MATEMATISKA OCH DATALOGISKA TEORIER B SNABBGUIDE TILL NIAM-DIAGRAM C BESKRIVNING AV ATTRIBUT TILL TELE ATLAS NÄTVERKSDATALAGER D BESKRIVNING AV ATTRIBUT TILL TELE ATLAS DATALAGER FÖR GEOKODNING E PROGRAMVAROR – PLATTFORM F OBJEKTMODELLER – ESRI ARCGIS 9.0 G BESKRIVNING AV SVÄNGOBJEKTKLASSEN I ARCGIS GEODATABAS H EXEMPEL PÅ UPPTAGNINGSOMRÅDE (SERVICE AREA) I VALT GEOGRAFISKT OMRÅDE I FALLET FALKÖPING J EXEMPEL PÅ UTDATAFIL FRÅN RUTTBERÄKNING

1 Inledning Här beskrivs ett antal begrepp och teorier som används i arbetet. Dessa begrepp behövs sedan för att kunna tydliggöra arbetets roll och dess samman-hang i det större projekt som arbetet utgör en del av. En kort beskrivning görs även av detta större omgivande projekt.

Till sist presenteras examensarbetets mål, syfte och metod.

1.1 Bakgrund Det här arbetet utgör en del i ett större projekt vars mål är att titta på möjlig-heterna att effektivisera förnödenhetstransporter inom en kommun. Det får till följd att begrepp och fakta kommer att vara hämtade från ett antal kunskaps-fält. Dessa är, förutom datalogin, geografisk informationsvetenskap samt transportlogistik. För att tydliggöra respektive kunskapsfält görs först en beskrivning av begreppen geografisk informationsvetenskap, GIS och transportlogistik. Dessutom ges även en presentation av det större projekt som arbetet utgör en del av.

1.1.1 Geografisk informationsvetenskap Benämningen geografisk informationsvetenskap (eng: GIScience) har under de senaste åren blivit allt mer förekommande och då ofta nämnd i samband med geografiska informationssystem (GIS). Kunskapsområdet som sådant finner en allt större roll i ett samhälle där avstånden krymper, samhällen växer och miljöproblemen blir alltmer svårhanterliga. Det är tyvärr så att begreppen geo-grafisk informationsvetenskap och GIS vars innebörd är olika, ibland används utan särskiljning. Vilken benämning som används speglar sig ofta i tillämpningsområde och medverkande personers bakgrund. Oftast används begreppet GIS även som benämning på kunskapsfältet som sådant där benämningen geografisk informationsvetenskap skulle passa bättre (Eklundh red. 1999). I denna rapport kommer båda benämningarna att an-vändas beroende på sammanhang.

Geografisk informationsvetenskap är vetenskapen bakom geografiska tekno-logier som exempelvis fotogrammetriska metoder, fjärranalys och GIS. Denna vetenskap ligger till grund för teknologiernas utveckling. Den geografiska informationsvetenskapen är tvärvetenskaplig på så sätt att den under sitt tak samlar områden som t.ex. kartografi, geodesi och fotogrammetri (Goodchild, 1997).

Vad menas då med geografisk information (GI)? I Goodchild (1997) hittar man följande beskrivningar av begreppet:

Information om en plats/position på jordens yta.

Kunskapen om var någonting finns.

Kunskap om vad som finns på en given plats/position på jordens yta.

Här ska även nämnas att begreppen spatial information och rumslig information är vanligt förekommande. Dessa två begrepp som har samma betydelse (spatial = rumslig) ges ett vidare begrepp än geografisk information

1

eftersom det här handlar om bestämning i rummet i dess vidaste bemärkelse dvs även utanför vårt eget jordklot (Eklundh red. 1999).

Centralt för de definitioner man hittar om geografisk information är att det handlar om information som är knuten till en geografisk position. För att en-tydigt kunna ange en sådan geografisk position används ett s.k. geodetiskt referenssystem med tillhörande koordinatsystem. Ett vanligt sätt att ange en punkts läge på jorden är med hjälp av geografiska koordinater, longitud (öst-västlig) och latitud (nord-sydlig) riktning.

1.1.2 Geografiska informationssystem, GIS Ett geografiskt informationssystem är ett datorbaserat informationssystem för geografisk information. Allmänt är ett informationssystems syfte att förenkla informationsutbyte, förbättra hantering, bearbetning och analys av informationen samt möjliggöra effektiv och säker lagring av data. I ett GIS ingår mjukvara, hårdvara den geografiska informationen som hanteras och inte minst användare av systemet, se figur 1. Att användare av systemet innefattas är inte signifikant för GIS utan för informationssystem allmänt. Information är data tolkad av någon individ. Utan denne individ som tolkar har vi ingen information (Tarkowski, Ireståhl, Lumsden, 1995).

Ggvsiko(u

Figur 1 Funktioner och beståndsdelar i ett GIS.

enom att definiera ett GIS som ett informationssystem som hanterar geo-rafisk information och informationen i sig har den egenskapen att den ska ara knuten till en plats eller position på jordens yta har man avskrivit en del ystem och programvaror möjligheten att kallas för ett geografiskt nformationssystem. Dit hör bildbehandlingssystem som hanterar geografiska artor i form av bildfiler (jpg, gif m.fl.) men utan den egenskapen att objekt ch punkter på kartbilden har en referens till en geografisk position på vår jord Eklundh red.1999). Även de traditionella CAD-systemen faller bl.a. därför tanför ramen för ett GIS.

2

I denna rapport kommer begreppet GIS att användas dels med innebörden metod dels i dess betydelse som en teknologi.

Förenkling av informationsutbyte är en av hörnpelarna i ett GIS. En stor del av den information som är beslutsgrundande inom såväl privat som offentlig sektor är geografiskt bunden information. Att då på ett enkelt sätt kunna fram-ställa informationsmaterial kopplat till kartor som ger betraktaren det geo-grafiska sammanhanget är en möjlighet till snabbare och säkrare beslutsvägar.

Förbättrad hantering och bearbetning av den geografiska informationen nås genom att man inom ett och samma system har tillgång till all den samlade information som finns inom en organisation. Här finns däremot ett av hindren till utvecklingen av GIS-användandet. Ofta är informationen inom en orga-nisation uppdelad på ett flertal skilda datorsystem vilket medför problem vid datautbyte mellan systemen i form av överföringsprotokoll och data-konverteringar. Att ha tillgång till organisationens all information i ett och samma datorsystem väl strukturerad, förbättrar möjligheten att upptäcka nya mönster och hitta ny information. Kopplingen till geografin via kartor är sedan ytterligare en styrka.

GIS används inom en mängd tillämpningsområden. Samhälls- och trafik-planering samt försvaret är några av de vanligare exemplen men idag används GIS även inom exempelvis räddningstjänst, transportnäring, skogs- och jordbruksnäring, energidistribution etc. Marknadsföring är ett exempel på ett bredare användningsområde. En uppfattning inom branschen som emellanåt hörs är att de möjligheter och resurser som ett GIS står till förfogande med sällan utnyttjas. Detta kan bero på bristfälliga kunskaper hos användare samt skillnader i syn på arbetssätt mellan användare av ett GIS och program-varutillverkare (Eklundh red.1999). Utbildning inom GIS och förbättring av användarvänlighet hos programvaror inom området är exempel på åtgärder som kan vara positiva för ökande GIS-användning. I Sverige arbetar idag ett antal konsultföretag med att överbrygga hanterings- och gränssnittsfrågan genom att anpassa och bygga GIS-applikationer som är direkt kopplade till en specifik tillämpning.

1.1.3 Geografisk informationsteknologi, GIT Geografisk informationsteknologi är samlingen teknologier ämnade att hantera geografisk information. Exempel på sådana teknologier är:

GPS – Global Positioning System. Ett system som med hjälp av ett antal satelliter kretsande runt jorden möjliggör positionering i realtid.

Fotogrammetriska metoder. Informationsinsamling genom mätningar i bildpar tagna från flygplan. Genom att bildparet till viss del täcker över varandra och bilderna är tagna ur olika vinklar fås information om höjdskillnader i motivet.

Fjärranalys. Teknik för insamling av information från flygplan eller satellit med hjälp av avläsning av den från jorden reflekterade elektromagnetiska strålningen.

GIS, Geografiska Informationssystem. Se tidigare beskrivning.

3

För ytterligare information om GPS hänvisas till Hofmann-Wellenhof B., Lichtenegger H., Collins J. (2001).

För ytterligare information om fotogrammetriska metoder och fjärranalys hänvisas till Eklundh red. (1999).

1.1.4 Transportlogistik och planering Transportlogistik handlar om de tre begreppen gods, resurser och information samt deras flöden mellan de tre enheterna godsavsändare, godsmottagare och transportföretag. Inom transportlogistik, liksom andra typer av organisationer talar man om planeringsarbete på tre nivåer (Tarkowski, Ireståhl, Lumsden, 1995). Det är av intresse att nämna dessa här och ta upp ett par exempel för att få en bild av när och hur ett GIS skulle kunna komma till användning inom planering av transportlogistik.

Strategisk nivå innebär den långsiktiga planeringen med en planerings-horisont på mer än fem år. Här tas företagets generella riktlinjer och mål fram. Exempel på planeringsarbete på denna nivå är lokalisering av terminaler och lager samt trafikområdesbestämning. Vid planeringen av terminallokalisering ingår delproblem som att bestämma antalet terminaler och deras storlek, geo-grafiska placering samt kundfördelning på terminalerna. Trafikområdes-bestämningen, dvs vilket geografiskt område en given terminal ska ansvara för handlar till stor del om tid och avstånd kombinerat med resurser i form av transportfordon.

Taktisk nivå handlar till stor del om att välja och dimensionera transport-produktionssystem. Här bestäms t.ex. linjeval, mängden fordon och personal samt deras allokering. Tiden som planeringen täcker rör sig om ca ett till fem år.

Operativ nivå innebär transportplanering av lastbärare och resurser i gods-terminaler. Som transportföretag är målet att planera resurser så att man på ett effektivt sätt tillmötesgår kundernas serviceönskemål. På operativ nivå disponerar man de resurser som man på taktisk nivå tilldelat verksamheten. Planeringen är kortsiktig och sker ofta i realtid i den dagliga verksamheten. En stor del av denna planering är beroende av att kunna utföras genom rutin-mässiga moment och med driftsäkra metoder som inte stör produktionskedjan.

1.1.5 Transportinformationssystem Behovet av informationssystem inom transportnäringen ökar i takt med tuffare konkurrens. För att möta kundens krav på snabb och flexibel tillgång till levererat gods blir sändningarna mer frekventa och samtidigt mindre i kvantitet. Förbättrad precision ställs därför på transporter och informations-flöde. Effektivare kommunikation både inom det egna företaget och med andra instanser inom transportkedjan är också ett ökande krav (Tarkowski, Ireståhl, Lumsden, 1995).

Fram till för några år sedan handlade IT-system inom transportsektorn mest om administration i form av affärssystem. Nu ser man däremot en utveckling mot system som även behandlar resurs- och produktionsplanering, säljstöd och informationskommunikation för statistik, analys fakturaöverföringar osv.

4

Dessa system integreras eller kommunicerar gärna med de befintliga affärs-systemen. Utrustning för rörliga resurser (mobila enheter) är också ett område som kommit starkt. Små specialbyggda datorer för placering i lastbilar, bussar, truckar osv utvecklas där höga krav ställs avseende yttre påverkan i form av smuts och stötar.

Med ett ökat datoranvändande kommer också ett ökat krav på kvalitet på indata. Information ska plötsligt tolkas av datorer istället för människor. Så långt det är möjligt vill man därför undvika manuell inmatning av information. Automatiska identifieringssystem är ett medel för att uppnå detta. Den kanske vanligaste identifieringsmetoden är streckkodssystemet. Streckkoder avläses normalt med laserskanner manuellt eller automatiskt på exempelvis transportband.

RFID (Radio Frequency Identification) är ett system som med hjälp av radio-vågor skickar information om objekt. Informationen för ett objekt ligger lagrad i ett mikrochip en s.k. RFID-tagg (även RFID-transponder) som sitter fäst på objektet. Det ger möjligheten till lagring av betydligt mer data än jämfört med streckkod. Man kan då i större utsträckning låta objektet bära med sig informationen om sig själv. Dessutom finns möjligheten att använda mikro-chip som tillåter skrivning till minnet vilket gör att informationen kan redigeras vid flera tillfällen. För att läsa av en RFID-tagg krävs en radio-frekvensläsare. Ett antal ISO-standarder finns framtagna för RFID-tillämpningar.

Planerings och exekveringssystem Affärssystem, som också benämns ERP-system (Enterprise Resource Planning) arbetar mot en databas innehållande företagets kunder, ordrar, fakturor, produkter, lager, leverantörer osv. Deras syfte är att stödja ett företags affärsprocesser. Systemen är byggda så att de ska kunna formas för den egna verksamheten vilket gör att de är generella i sin funktion. Det gör att de saknar möjlighet till mer utvecklade operationer för planering och analys av verksamheten. Ett APS-system (Advanced Planning System) kompletterar därför ett affärssystem med mer logistiska tillämpningar. Exempel på detta är system för materialplanering och distributionsplanering på taktisk nivå. Här finns även system för transportplanering operativt med stöd för daglig ruttplanering.

Det finns även mer fristående system som är specialiserade på vissa logistiska aktiviteter. Ett exempel på sådana system är WMS-system (Warehouse Management System) vars syfte är att hantera lagerrelaterade uppgifter. De handhar och registrerar uppgifter om inkommande gods, godsets mottagar- och avsändaruppgifter, information om godset placering i lagret mm. Systemen servar även med praktiska detaljer som t.ex. utskrift av etiketter och annan dokumentation som hör till försändelser. Förutom de grundläggande lagerhanteringsuppgifterna kan ett WMS även stödja personalplanering och hantering av returflöden.

Detta arbete avser att behandla applikationer som benämns ruttberäknings-applikationer. Dessa ingår oftast i ett s.k. Transportation Management System (TMS). Ett TMS arbetar med distributions- och transportplanering. Syftet med denna planering är få ner kostnaderna för transporterna samtidigt som man

5

uppnår god service till kunderna. I ett TMS kan förutom själva ruttplaneringen även stöd ingå för optimering av transportflottan, schemaläggning av transportfordon, lastplanering, godsspårning mm. (Jonsson, Mattsson, 2004)

Funktioner som ingår i de ovan givna systemen kan betraktas som funktioner ingående i en planeringsstruktur enligt figur 2. Observera att gränsdragningen mellan vilka funktioner som ingår i vilka system är inte är knivskarp. Likaså kan ofta en och samma funktion praktiseras på mer än en planeringsnivå.

1Gslobhif

Aknpoitlsm 1

Figur 2 Skiss över ett antal funktioner som används vid planering av ett transportsystem. Funktionerna har indelats i de planeringsnivåer de i första hand kan komma till användning. Affärssystemen innehåller ofta en del av funktionerna.

.1.6 Transportlogistik och GIS IS som teknologi och metod kan användas på alla nivåer av planering. I den

trategiska planeringen är tillgänglighetsanalys en metod att använda sig av för okalisering av terminaler. Planering av trafikområden baserade på antal stopp ch/eller geografisk placering är ett annat exempel. På taktisk nivå kan ett rutt-eräkningsprogram i ett GIS ge stöd för linjeplanering. Operativ planering andlar mycket om fordons-, personal och lastplanering baserat på den nkommande ordermängden men även här finns behov av ruttplanering i de all förändringar av rutterna sker med korta tidsintervall.

nvändandet av informationssystem och därmed GIS inom transportsektorn an ses som väldigt låg i förhållande till t.ex. kollektivtrafikens och taxi-äringens användande. Inom dessa områden har det sedan en längre tid funnits lanerings- och ledningssystem (Tarkowski, Ireståhl, Lumsden, 1995). En rsak till detta skulle kunna vara att man tidigare inte sett tillräckligt stor vinst att t.ex. implementera ett ruttplaneringssystem jämfört med att satsa på andra yper av verksamhetsstöd.1 En annan trolig orsak är att teknik och under-iggande datastöd i form av vägdatabaser inte funnits tillgängligt i tillräckligt tor omfattning och med tillfredsställande kvalitet. En jämförelse kan göras ed USA där marknaden för denna typ av IT-stöd är större. Där hittar man

Muntlig källa P-O Knöös, Schenker 2005-03-31

6

idag många av de marknadsledande företagen inom både GIS och transport-logistiska informationssystem.

1.1.7 Ruttplanering – ruttberäkning – ruttbeskrivning Observera att i uppräkningen av funktioner i ett transportplaneringssystem som gjordes tidigare så angavs ett antal där man kan ta hjälp av s.k. rutt-beräkningar. Det gäller funktionerna ruttplanering, linjeval och trafikområdes-indelning.

Ruttberäkningar har sin bakgrund i det klassiska en handelsresandes problem (eng: Traveling Salesman Problem, TSP). Det kan beskrivas på följande sätt:

Problem 1a: Man har en bil som ska besöka ett antal platser i ett visst område. Vad som önskas är ett förslag på i vilken turordning bilen ska besöka platserna samt efter vilka vägar bilen ska färdas för att besöksrundan ska bli så effektiv som möjligt.

En annan formulering av samma problem:

Problem 1b: Givet en transportbärare som ska besöka ett antal stopp. Ange en så effektiv rutt som möjligt där alla stopp besöks minst en gång.

Här finns ett antal parametrar att ta hänsyn till som kommer att diskuteras senare i rapporten. Vad menar man med så effektiv som möjligt? Är det avseende på tid, kostnad i kronor eller något annat? Är det tillåtet att göra u-svängar? Är det okej att passera samma stopp flera gånger?

Om man på ett enkelt sätt vill avbilda ruttberäkningsproblem med en skiss används vanligtvis grafer. Figur 3 visar ett exempel på problem 1a och 1b med ett förslag på lösning redovisad.

F

Or

Figur 3 Exempel på ett ruttberäkningsproblem presenterad med en graf. De fyra stoppen ska besökas på ett så effektivt sätt som möjligt avseende kostnad som är angiven.

ör en mer detaljerad beskrivning av grafer och topologier se bilaga A.

vanstående är en ruttberäkning. Ruttberäkningar kan användas som stöd för uttplanering som i sin tur ger en eller flera ruttbeskrivningar. Ruttberäkningar

7

kan också användas som stöd till linjeval, trafikområdesindelningar, lokalisering mm.

1.1.8 Fallet Falköping kommun I Falköping kommun genomförs under perioden 2004-06-03 - 2006-08-31 ett projekt som heter Samordning av logistiska resurser inom transportområdet. Projektet har som utgångspunkt att samordning av logistikresurser som transporter, lagring och administration kan resultera i besparingar för såväl den offentliga som den privata sektorns materialflöden. Dessutom kan det vara så att de lokala företagen i och med detta ges större möjlighet att konkurrera på lika villkor. För att se förutsättningar och möjligheter med en samordning vill man skaffa sig en överblick över materialflöden och logistikaktiviteter. Denna överblick ska sedan kunna ligga till grund för fortsatta diskussioner och planering av infrastrukturella resurser.

Syftet med projektet är att med hjälp av metoder inom geografisk informationsvetenskap och GIS skaffa en överblick över kommunens resurs-flöden både till offentlig och privat sektor. Man vill också klargöra nyttan av att använda sig av GIS som effektiviseringsinstrument.

1.1.9 Examensarbetets roll i projektet Idag sker alla transporter av mat och förnödenheter inom kommunal regi direkt från leverantör till respektive kommunal enhet. Ingen samordning sker. Som ett delmoment i huvudprojektet undersöks nu om en effektivisering av dessa transporter skulle kunna nås genom en samordningscentral dit alla leverantörer levererar och varifrån mottagarna sedan får sina leveranser. Para-metrar som beaktas vid denna undersökning är bl.a. transportkostnader avseende distans och tid, miljöaspekter samt trafiksäkerhetsfrågor.

Inom projektets ramar genomförs under våren -05 tre stycken delprojekt/examensarbeten om 2 x 20p vardera. Två av dessa går genom Högskolan Skövde under namnen ”Samordning av livsmedelstransporter” samt ”Kriterier för en samordningscentral”. Dessa arbeten undersöker inkommande materialflöden dels med hänsyn till hantering på kommunernas enheter dels med hänsyn till dess väg från leverantör till kommun.

Det tredje examensarbetet (om 2 x 20 p) som går genom Chalmers och Stockholms universitet tittar på ett före respektive efterscenario av en samordningscentral. Utifrån detta tydliggörs om effektivisering av förnöden-hetstransporter till kommunens enheter är möjlig. Arbetet utförs med hjälp av geografisk informationsvetenskap och ett GIS som verktyg. Dessutom behandlas nyttan av ett GIS vid denna typ av undersökning.

Denna rapport och examensarbete behandlar hantering och utvecklings-möjligheter av GIS-programvaran som använts i arbetet och är samtidigt ett examensarbete inom datalogi om 20 poäng under Stockholms universitet.

8

1.2 Syfte Syftet med detta arbete är att ge övergripande kunskaper i geografisk informationsvetenskap och GIS utifrån ett transportlogistiskt perspektiv. Framförallt ska det ge kunskaper i hur väl ett GIS kan stödja och utföra transportlogistiska beräkningar avseende ruttberäkningar och transport-planering. Det redskap som används som referens i denna bedömning är ESRI:s ArcGIS 9.1 Network Analyst.

Arbetet ska kunna användas som ett underlag för framtida beslut om eventuell införskaffning och implementering av en GIS-plattform för transportlogistiska analyser och ruttplanering.

1.3 Problembeskrivning Detta examensarbete undersöker förutsättningarna för

att på ett effektivt sätt och med tillräckligt god noggrannhet utföra transportlogistiska beräkningar med hjälp av geografisk informationsvetenskap och ett lämpligt GIS

utveckling av en tillämpningsanpassad applikation baserad på ett lämpligt GIS.

Den GIS-plattform som används är en betaversion av ESRI:s ArcGIS 9.1.

Releasen av ESRI:s nya Network Analyst som är satt till maj 2005 är av GIS-branschen en efterlängtad händelse. I detta arbete görs en genomgång av funktioner i ArcGIS 9.1 Network Analyst med tyngdpunkt på ruttberäknings-funktioner. Möjligheterna till funktioner och beräkningar är starkt kopplade till vilken underliggande vägdatabas som används och därför görs även en analys av denna. Under arbetet används Tele Atlas MultiNet vägdatabas som är en kommersiell produkt. Arbetet kommer även att belysa den arbetsgång som krävs vid användning av programvaran.

I samband med funktionsöversynen i Network Analyst ges också en beskrivning över de problem som man som användare kan stöta på. Detta är problem i form av

kompatibilitetsproblem mellan vägdatabas och applikation

in- och utdataformatering

ej tillräckligt stor noggrannhet i beräkningar.

En utvärdering av utvecklingsmöjligheter av gränssnitt och funktionshantering med hjälp av ArcGIS 9.1 Network Analyst görs i detta arbete. Detta mynnar ut i en vägledande beskrivning och diskussion inför ett införskaffande av en sådan plattform.

Förutom de två inledande problemställningarna kommer även följande att tas upp:

En överblick av marknaden i övrigt avseende ruttberäkningsapplikationer.

Exempel på hur aktörer inom transportnäringen använder sig av GIS. De transportföretag som arbetet kommer att koncentrera sig på är

9

DHL, Posten och Schenker. Dessa företag ingår i en referensgrupp i det övergripande projektet som drivs av Falköping kommun (se 1.1.8).

1.4 Avgränsningar För att titta på GIS avseende transportlogistisk analys används ESRI:s ArcGIS 9.1 med Network Analyst som referensplattform. Motiveringen till varför just denna programvara får representera en hel teknologi är att den är väldigt väl representerad som GIS-plattform bland användare i såväl privat som offentlig sektor. ESRI har idag 35 % av världsmarknaden inom GIS och har med den nya versionen av Network Analyst något som ses som en stark produkt av branschfolk.

Jämförelser med någon annan GIS-plattform görs inte i detta arbete eftersom tidsramarna inte räcker till för detta.

I samband med marknadsöversikten av övriga programvaror för transport- och nätverksberäkningar kommer inte några jämförelser i prestanda och funktionalitet att göras.

Detta examensarbete kommer inte att innefatta analys och utvärdering av transportlogistiska data som används vid testning av applikationen. Däremot kommer resultatet av dessa beräkningar att användas för att bedöma applikationens korrekthet i funktionalitet och beräkningar.

Beskrivningen av möjligheterna till en gemensam plattform för transport-optimering hos kommun och leverantörer begränsar sig till en allmän beskrivning av de olika typer av system som kan byggas med hjälp av ESRI:s produkter. Detta är dock oftast direkt överförbart till andra liknande plattformer/produkter på marknaden.

1.5 Metod Följande genomfördes för att ge svar på problembeskrivningen:

Teori och inläsning För att få förståelse för den bakomliggande datalogiska strukturen vid hantering av geografisk information, topologiska strukturer och nätverksberäkningar har teoriinläsning gjorts där följande moment tas upp:

Grundläggande grafteori.

Topologiska nätverk.

Algoritmtekniker och grafteoretiska algoritmer.

Datastrukturer för spatial information.

Objekt- och datamodeller för topologiska nätverk.

Databasimplementation av topologiska nätverk.

Instudering av vägdatabasen Tele Atlas MultiNet gjordes med hjälp av den medföljande dokumentationen. Speciellt studerades de delar av databasen som är relevanta för att bygga ett topologiskt nätverk som kan användas för ruttberäkningar.

10

Objekt- och datamodell för ESRI:s Network Analyst fanns att tillgå i dokumentation för verktyget ArcGIS Desktop Developer Kit.

Funktionalitet och hantering av ArcGIS Network Analyst Arbetet med att undersöka funktionalitet på ESRI:s ArcGIS 9.1 Network Analyst har skett med hjälp av en betaversion av programvaran. Den skarpa versionen släpps i maj 2005 och har inte varit tillgänglig under examens-arbetets gång. Det gör att dokumentation i form av manualer varit bristfällig. Den dokumentation som funnits tillgänglig är ArcGIS Desktop Help som är integrerad i ArcGIS Desktop. Support från ESRI har heller inte varit möjlig då deras supportavdelning ej under detta arbetes gång varit utbildad på produkten. Vid ett antal tillfällen har mailkorrespondens med för Network Analyst ansvarig person på ESRI Sweden varit till hjälp. Vid detta arbetes slutfas gjordes även en slutkontroll personligen med ESRI där problem och slut-resultat togs upp för diskussion.

Funktionsgenomgång av ArcGIS Network Analyst har skett med hjälp av tester på data från Tele Atlas MultiNet och ett geografiskt utsnitt som inne-fattar delar av Västra Götalands län med koncentration på Falköping kommun. I arbetet har därför kompatibiliteten mellan ArcGIS och Tele Atlas varit särskilt intressant att beakta. Information om detta har inhämtats genom mail-korrespondens med svenske återförsäljaren för Tele Atlas och ansvarig personal på ESRI Sweden.

Övriga data som använts i samband med tester av ruttberäkningar har till största delen utgjorts av det material som analyserats i samband problematiken av transporteffektivisering i Falköping kommun.

Kvalitetskontroll av utdata Kvalitetsbedömning och kontroll har gjorts av ruttberäkningar på grundval av den tillämpning som ruttberäkningsapplikationen varit ämnad för. (Se avsnitt 1.1.7.)

Kvalitetskontroll av rutters avstånds- och tidsangivelser har utförts genom loggning av med personbil genomförda rutter i Falköping kommun.

Transportföretagens GIS-användning För att få en översyn av de på transportmarknaden stora aktörernas GIS-användning har intervjuer skett av personal som är ansvarig för denna typ av verksamhet eller på annat sätt arbetar inom området på respektive företag.

Andra verktyg på marknaden Översyn över andra verktyg på marknaden har utförts på följande sätt:

Intervjuer med branschkunniga personer. Dessa personer är:

o Jonas Tornberg, examinator och forskningsingenjör, Chalmers

o Mikael Elmqvist, VD för Swegis AB

o Thomas Rickne, DSP International

11

o Thorbjörn Schmidt-Jacobsen, Sales Manager på Transvision A/S.

Sökning på Internet.

Besök gjordes även på ESRI Sweden:s GIS-konferens i Stockholm 3–4 februari 2005.

1.6 Läsanvisning för rapporten Syftet med detta arbete är att ge ökade kunskaper om geografiska informationssystem och då främst dess användning i samband med rutt-beräkningar i transportsystem. Rapporten är därför skriven med målet att personer med skiftande bakgrundskunskaper inom GIS och datalogi ska kunna ta del av valda delar i rapporten. Därför ges här en beskrivning av rapportens upplägg.

Kapitel 2 behandlar GIS i allmänhet. Grundläggande begrepp som används i rapporten i övrigt tas upp och beskrivs. Speciellt behandlas begrepp knutna till nätverksanalys. Kapitlet hoppas med fördel över av den läsare som sedan tidigare är insatt i geografiska informationssystem och geografisk data-bearbetning.

Kapitel 3 behandlar den plattform som används och utvärderas. Plattformen som är ArcGIS 9.1 med tilläggsmodulen Network Analyst, beskrivs först allmänt och sedan mer detaljerat avseende tilläggsmodulen som är mest intressant i sammanhanget. Detta kapitel läses med fördel för att få förståelse för arbetsgången i det praktiska fallet presenterat i kapitel 5.

Kapitel 4 beskriver den vägdatabas som används i detta arbete. Vägdatabasen är väldigt viktig i sammanhanget och påverkar möjligheter i funktionalitet och kvalitet i resultat som verktyget ger. Läses av den tekniskt orienterade. Även om läsaren väljer att hoppa över kapitlet nås tillräcklig förståelse i den fortsatta rapporten.

Kapitel 5 behandlar det praktiska fall i Falköping kommun som verktyget använts till. Kapitlet beskriver konfigurering och användning av verktyg och vägdatabas samt viss utveckling av användargränssnitt. I detta kapitel återfinns kopplingen till examensarbetet Datorstödd transportresursplanering – En GIS-studie som utförts av Guy, 2005 och som behandlar fallet Falköping mer ingående.

Kapitel 6 ger en kort överblick över möjligheter till applikationsutveckling inom ramen för ArcGIS.

Kapitel 7 ger en översikt över hur andra verktyg på marknaden inom transportplanering ser ut. Dessutom ges exempel på hur några större transport-företag arbetar med transportplanering.

Kapitel 8 avslutar rapporten med en diskussion.

I bilaga A beskrivs underliggande matematiska och datalogiska teorier som används inom nätverksanalys. Stycket är utlyft ur rapporten p.g.a. att språket direkt avviker från rapporten i övrigt och styckets innehåll inte krävs för förståelse av rapporten.

12

2 GIS Följande kapitel ger en kort introduktion till geografiska informationssystem (GIS) avseende i första hand datamodellering. Ett par olika sätt att modellera verkligheten tas upp liksom två motsvarande sätt att digitalisera dessa modeller. Topologiska datastrukturer beskrivs därefter följt av en redogörelse för begrepp inom nätverksanalys som kommer att användas i denna rapport. Avslutningsvis beskrivs begreppet geokodning.

2.1 Geografisk information och dess egenskaper Geografisk information är som tidigare nämnts information som är knuten till en geografisk plats. Även rumslig information används för detta även om det ger begreppet en vidare betydelse. Geografisk information har två olika typer av egenskaper: rumsliga och icke-rumsliga egenskaper. Rumsliga egenskaper i sin tur beskrivs med hjälp av geometriska och topologiska egenskaper. Geometriska egenskaper är mätbara egenskaper som t.ex. längd, bredd, utbredning, position osv. Topologiska egenskaper är inte mätbara på samma sätt utan anger angränsning, anslutning och innehåll (se avsnitt 2.4).

Icke-rumsliga egenskaper även kallade attribut används för att ge mer infor-mation om de geometriska objekten. Ett exempel är en väg vars rumsliga egenskaper som längd och geografisk position kan kompletteras med attribut som hastighetsbegränsning, bärighet, trafikflöde osv.

2

Ivvi

Figur 4 Beskrivning av geografisk information och dess egenskaper med exempel.

.2 Modellering och digitalisering av geografisk information

nom geografisk informationsvetenskap vill man modellera och beskriva erkligheten. För att detta ska vara genomförbart krävs en tankemodell av erkligheten. Oftast arbetar man med tematiska skikt som grundar sig på en ndelning av verkligheten i teman. Så kan t.ex. vägar, tätorter, jordarter,

13

befolkningsgrupper vara exempel på tematiska indelningar. Varje tema kan sedan representeras av ett eller flera tematiska skikt som vardera består av en sammanhållen mängd information. Exempelvis kan temat vägar delas upp på flera tematiska skikt, ett för europavägar, ett för riksvägar och ett för länsvägar och övriga vägar.

Ytterligare en typ av indelning av verkligheten grundar sig på egenskaper hos de företeelser som beskrivs i de tematiska skikten. En del element i verklig-heten kan man betrakta som enskilda objekt, klart avgränsade i geometrisk mening från andra omkringliggande objekt. Exempel på den typen av element är vägar, vattendrag, administrativa indelningar som kommuner etc. Benämningen på dessa objekt är geografiska objekt eller kort geoobjekt2.

Dessa geoobjekt låter vi representeras av de fyra geometriska grundelementen:

Punktelement används då form och utbredning för ett geoobjekt inte är relevant. Det som är av intresse är i huvudsak objektets geografiska placering. Exempel: Städer, byggnader.

Linjeelement representerar endimensionella geoobjekt där bredden är utan betydelse. Exempel: Vägar, bäckar.

Ytelement eller polygoner används för geoobjekt som kan betraktas som homogena ytor med klart definierade gränser. Exempel: Sjöar, städer.

Observera att många geoobjekt från verkligheten kan modelleras med olika typer av geometriska grundelement beroende på skala på modellen. En stad i liten skala kan modelleras med ett punktelement medan samma stad i större skala gärna modelleras med ett ytelement. På samma sätt kan en väg i liten skala modelleras av ett linjeelement och av ett ytelement i större skala.

Kroppar används för att representera geoobjekt i tre dimensioner.

Andra typer av geografiska företeelser kan vara svårare att kunna betrakta som enskilda element. Exempel på sådana företeelser är topografi, dvs markytans höjd över havet, jordarter, lufttemperatur etc. Dessa egenskaper betraktas och modelleras istället som kontinuerliga ytor i rummet.

(Eklundh red. 1999)

2.3 Digitaliserad geografisk information Den konceptuella modellen av verkligheten som beskrevs i föregående avsnitt digitaliseras i ett GIS huvudsakligen genom två datastrukturer. Vilken data-struktur som används är beroende av vilken typ av företeelser ur verkligheten det tematiska skiktet representerar och/eller vilken typ av analys man som användare av GIS-verktyget vill göra. Här kommer också termen datalager att användas istället för tematiskt skikt för att tydliggöra övergången till digitali-serad geografisk information.

2 Muntlig källa: Håkan Nordlund, ESRI, 2005-06-02

14

2.3.1 Vektorstruktur Vektorstrukturen används i de fall man modellerar geografiska företeelser som distinkta objekt. Eftersom objekten representeras av de tidigare beskrivna geo-metriska grundelementen kan man numeriskt beskriva objekten med hjälp av ett antal talpar som anger koordinaterna för elementen i något koordinat-system. I vektorstrukturen är det lätt att arbeta med många attribut. Varje geo-objekt tilldelas ett unikt ID som sedan används i attributtabeller.

Fa

Vmeggkg

2Rhbk(emsE

Figur 5 Exempel på datalagringsstrukturer för linjer. I den filbaserade lagringsstrukturen inleds varje linje med ett heltal för linjens id följt av ett heltal som anger antalet punkter som representerarlinjen. Därefter följer koordinaterna för varje ingående punkt. Lagringsstrukturen i ett RDBMS bygger på två tabeller. En med alla punkter representerade och en med alla linjer. Fältet punktid refererar till en punkt i punkttabellen.

igur 5 visar exempel på hur linjer kan lagras i en vektorstruktur. Observera tt detta är ett exempel på lagringsstrukturer bland många.

ärt att nämna här är att skillnad bör göras mellan geografiska objekts geo-etriska egenskaper och vårt sätt att lagra dessa geometriska egenskaper. För

n väg kan dess geometriska egenskap bredd lagras och hanteras digitalt i eometrin för objektet. Med detta menas att bredden framgår av objektets eometriska representation i form av talpar. Men denna geometriska egenskap an likaväl lagras som ett attribut i en attributtabell. Egenskapen är fortfarande eografisk men den lagras som ett attribut.

.3.2 Rasterstruktur asterstrukturen används för att representera och lagra företeelser från verklig-eten som betraktas som kontinuerliga ytor. Den består oftast av en regel-unden tesselering (indelning av en yta) och byggs då upp av ett rutnät med vadrater. En yta som ska avbildas delas in i ett antal rutor eller celler benämns även pixlar). Varje cell tilldelas ett värde som ska återspegla någon genskap för just den delytan. Vanligt är att värdet som tilldelas cellen är edelvärde, typvärde eller mittvärde för den yta som cellen täcker. Raster-

trukturen resulterar i en matris som används för bearbetning och lagring. xempel på en rasterstruktur visas i figur 6.

15

IfNOi

2OaftlEoad

Aaa

A

I

(

Gdeotbug”bls

Figur 6 Exempel på rasterstruktur. Längst till vänster en karta med isolinjer. I mitten är kartan (ytan)tesselerad och varje cell tilldelas värdet för höjden i mitten av cellen. Längst till höger visas den resulterande matrisen.

de enklaste fallen knyts endast ett attribut (en egenskap) till den geografiska öreteelsen i rasterstrukturen och det är attributets värde som lagras i cellerna. ackdelen med detta är att för varje attribut måste ett nytt datalager skapas. m man istället tilldelar varje cell ett ID-nummer som man sedan relaterar till

en tillhörande attributtabell går det att använda sig av flera attribut.

.4 Topologiska datastrukturer rdet topologi förekommer inom ett antal kunskapssfärer. Inom geografin

nvänds ordet som en beteckning på terrängens former. Här utgår vi däremot rån den betydelse ordet har inom matematiken och då speciellt geometrisk opologi. Topologi är i det avseendet en matematisk metod för att definiera ogiska relationer mellan objekt (MultiNet_UserGuide_Shapefile_v1.41.pdf). n topologisk modell bibehåller sin struktur oberoende av de ingående bjektens skala, form och storlek. De logiska relationer som avses är ngränsning, anslutning och innehåll. Topologi kallas populärt för gummi-uksgeometri.

ngränsning är den egenskap som anger om två geometriska objekt delar vgränsningslinje med varandra. Så kan t.ex. två ytor i form av fastigheter ngränsa mot varandra om de delar tomtgräns.

nslutning anger om två linjeobjekt är sammankopplade eller ej.

nnehåll anger om ett areaobjekt innesluter ett annat objekt eller ej.

Eklundh red. 1999)

eometriska lagringsstrukturer har olika grad av topologi inbyggt i sig. Med et menas möjligheten att direkt ur lagringsstrukturen avläsa de topologiska genskaperna. Om man betraktar den filbaserade lagringsstrukturen i figur 5 ch tänker sig vilja svara på frågor som rör anslutning, t.ex. ”ansluter linje a ill linje b?” inses att detta inte på något enkelt sätt kan kontrolleras. Metoden lir att hitta respektive linje, jämföra linjernas alla x- och y-koordinater och tifrån det klargöra om linjerna ansluter varandra. Om sedan mer komplexa eometriska element lagras på detta sätt och topologiska sökningar i form av hitta alla objekt som ligger inuti objekt b” ska göras blir det relativt tunga eräkningar för en dator att uträtta. En lösning på problemet är att införa agringsstrukturer som till större del separat lagrar de topologiska egen-kaperna. Redan i strukturen för ett DBMS i figur 5 anas en viss grad av

16

topologi. Där är det möjligt att enbart med hjälp av linjetabellen avgöra om två linjer ansluter till varandra och detta utan att veta något om linjernas (eller punkternas) rumsliga position.

Vad som kan vara önskvärt att nå är det som kallas en fullständigt topologisk lagringsstruktur. I en sådan struktur lagras topologin separerad från geometrin i egna tabeller med referenser till den geometriska strukturen.

2.5 Topologiska nätverk för nätverksanalys Topologiska nätverk används för att beskriva flöden eller förflyttningar i olika system. Ett vanligt exempel är vägnät. Andra exempel är elkretsar, vatten- och avloppsnät, materialflöden osv. För den logiska modelleringen av topologiska nätverk används grafteorin från matematiken (se bilaga A). Den ger då även ett redskap för fysisk datamodellering av topologiska nätverk genom grann-listor och grannmatriser (Shashi & Chawla, 2003).

Nätverk ses som ett antal linjer sammankopplade med varandra. De ingående objekten i nätverket kallas för nätverkselement och består av länkar som representerar linjerna och noder som är de punkter där linjerna är samman-kopplade. (Jämför med kanter och hörn i grafteori, bilaga A.) För att definiera en riktning på länkarna benämns ofta noderna till att vara en länks startnod respektive slutnod. Den topologiska egenskap som är aktuell är anslutning.

I ett vägnätverk är det vanligt att länkar representerar vägar och noder anger var anslutningar mellan vägar sker. Observera att noder inte alltid behöver representera punktobjekt från verkligheten på samma sätt som inte länkar alltid måste representera linjeobjekt. Som exempel kan nämnas en modell av ett flodsystem där noderna representerar floderna och om en flod rinner in i en annan så representeras detta av en länk mellan motsvarande noder (Shashi & Chawla, 2003). Samma flodsystem skulle även kunna modelleras på det för många naturligare sättet med länkar som representerar floderna och noderna de platser där floderna sammanstrålar. Vilken modell som passar bäst beror på tillämpning.

När ett topologiskt nätverk ska användas för analys av något slag är en förut-sättning att information om flöde, kapacitet, restriktioner, avstånd m.m. finns tillgängligt för varje länk och/eller nod i systemet. Denna information lagras därför kopplat till respektive nätverkselement.

Nätverksanalys handlar många gånger om flöden. En nod som genererar ett flöde kallas källa. En nod som utgör slutpunkt för ett flöde benämns sänka.

2.6 Ruttberäkningar i transportsystem – definitioner och begrepp

Ett transportsystem kännetecknas av att gods måste förflyttas från ett antal punkter till andra punkter (Lumsden, 1995). Detta kan modelleras med ett transportnätverk. Ett transportnätverk i den här meningen är ett transport-system som kan modelleras med en sammanhängande graf. Här finns dock två typer av nätverk vars definition måste förtydligas. Skillnad görs mellan transportnätverk som:

17

fysisk resurs

operativt system.

Transportnätverk som fysisk resurs är t.ex. ett vägnät. Det ligger nära till hands att även benämna det geografiskt nätverk eftersom nätet är en fysisk geografisk företeelse. Vägnätet är en fysisk resurs som i sig (oftast) inte har några tidsrestriktioner. Flödet, dvs fordon och gods är fritt att när som helst förflytta sig i nätverket.

I dessa nätverk görs ruttberäkningar. Med en rutt avses här en geografisk för-flyttning av ett fordon inom ett geografiskt nätverk via länkarna från en punkt kallad startpunkt till en punkt kallad slutpunkt. Observera att start- och slut-punkt inte är detsamma som nod. En start- eller slutpunkt måste vara ansluten till nätverket via en länk eller en nod. I en rutt är det tillåtet att passera samma nod flera gånger liksom att färdas längs med samma länk flera gånger. Denna förflyttning är vad som i grafteorin kallas för en promenad. Start- och slut-punkt kan vara samma punkt. Rutten är då en cykel.

Ett stopp är en punkt i transportnätverket som ska ingå i rutten. En annan benämning är besökspunkt som kommer att användas i samband med Network Analyst. En rutt kan innehålla 0 eller flera stopp. Ett stopp måste vara anslutet till nätverket via en länk eller nod och kan tilldelas ett eller flera tidsfönster som anger tidsintervall inom vilket fordonen i rutterna måste (bör) besöka stoppet.

Transportnätverk som operativt system är t.ex. ett busslinjenät eller distributionsnät. Läser man t.ex. Lumsdens (1995) definition av ett transport-nätverk så är det denna typ av nätverk som avses. Fordon och vägar utgör de fysiska resurserna men det som modelleras i nätverket är godsflödet. Flödet som består av det gods som transporteras i nätverket är i olika grad bundet till tider. Näten kan modelleras med en sammanhängande graf. Här behövs inte det geografiska nätverket som grund utan det är det logiska nätverket (som innehåller topologin) som är intressant vid analysen. Med länk menas i detta sammanhang transportsträckan mellan två noder och en nod representerar då oftast de ställen där transportfordon stannar för att lasta på eller av. (Jämför med stopp i det geografiska transportnätverket.) Begreppen källa och sänka används även i detta sammanhang. Dessutom finns uttrycket genom-strömningsnod (eng: transshipmentnodes) som representerar platser där ingen efterfrågan eller nyproduktion av gods finns. Platsen används enbart för exempelvis omlastning (Lumsden, 1995).

Begreppet rutt i detta avseende får en något konstig betydelse. När begreppet används är det ändå oftast förflyttningen i det geografiska transportnätet som avses. Om man vill hitta en betydelse för begreppet rutt avseende det operativa transportsystemet så är det möjligt att definiera det som en förflyttning av ett specificerat gods från en nod till en annan nod.

Detta arbete tar endast upp beräkningar på geografiska transportnätverk. När det gäller beskrivningen av ESRI:s modeller kommer denna terminologi att användas. Ett visst avsteg kommer dock att göras i samband med beskrivningen av nätverksmodellen för Tele Atlas vägdatabas. Detta för att anpassning behövs till deras egna uttryck.

18

2.7 Geokodning – adressättning Geokodning innebär att koppla objekt till en geografisk punkt eller med andra ord tilldela objekt en geografisk referens. Oftast används dock uttrycket mer i betydelsen adressmatchning, dvs att utifrån objekts belägenhetsadresser bestämma deras koordinater i ett givet referenssystem. Belägenhetsadresser kan ses som ett indirekt referenssystem (SIS, 2005). Det anger en geografisk plats utan att använda sig av koordinater. Adressmatchning handlar därmed om att översätta en typ av geografisk referens (belägenhetsadressen) till annan typ av geografisk referens (koordinater angivna i ett referenssystem).

I ett GIS kan adressmatchning genomföras manuellt eller på automatiserad väg. Manuellt utförs det genom att en geografisk punkt för ett givet objekt med adress anges med musmarkören i en kartvy. Denna kartvy ligger inlagd i ett givet referenssystem. Möjligheten kan även finnas att skriva in koordinater för objektet.

När adressmatchning ska göras på automatiserad väg krävs referensdata som innehåller information om belägenhetsadressers koppling till ett givet referens-system samt någon form av applikation för geokodning. Viktigt är att appli-kation och referensdata fungerar tillsammans. Standardisering av belägenhets-adresser är därför ett viktigt område inom GIS. Stanli arbetar nu med revidering av standarden SS 63 70 03, Geografisk information – Belägenhetsadresser – Begreppsmodell från 1998 (SIS, 2005).

Applikationer för adressmatchning finns som fristående applikationer och inbyggda i GIS.

19

3 ArcGIS och Network Analyst Detta kapitel beskriver den GIS-plattform som behandlas i arbetet. Det inleds med en kort presentation av företaget ESRI följt av en allmän översikt av de applikationer som deras GIS-plattform ArcGIS innefattar. Lagringsstrukturer och gränssnitt tas upp eftersom detta är intressant för det fortsatta arbetet.

Tilläggsmodulen Network Analyst beskrivs separat. Här tas applikationens funktioner upp med tyngdpunkt på ruttberäkningsfunktioner.

3.1 ESRI ESRI (Environmental Systems Research Institute) är ett amerikanskt företag med huvudkontor i Redlands, California. Det startades 1969 och koncentrerade sig redan från början på hantering av geografisk information. Idag är företaget en av världens ledande GIS-leverantörer med en omsättning på 469 miljoner USD och 35 % av marknaden. Antalet anställda är totalt ca 3000 personer (ESRI Sweden AB).

ESRI Sweden har funnits som eget företag sedan 1991 och driver marknads-föring, försäljning, utbildnings och support kring ESRI:s produkter. Kontor finns belägna i Falun, Stockholm och Gävle.

3.2 ArcGIS - plattformen ArcGIS är samling applikationer utvecklade av ESRI för att kunna erbjuda organisationer en komplett GIS-plattform. I samlingen ingår programvaror för desktop, server, webb och mobila enheter. Dessutom finns en utvecklings-plattform med objektbibliotek för utvecklare. Tanken med ArcGIS är att man som organisation ska kunna forma en GIS-plattform anpassad för den egna verksamheten. Detta utförs genom konfigurering och utveckling av applikationens funktioner, gränssnitt och dataåtkomst så att det passar den specifika kunskapsnivån och tillämpningen på en given avdelning inom en organisation.

ArcGIS delas in i fyra delar. Dessa är:

Desktop GIS

Server GIS

Embedded GIS

Mobile GIS.

Desktop GIS innehåller klientprogramvaror med tillhörande utvecklings-verktyg. Mjukvara ämnade för alla typer av servertillämpningar hittar man i Server GIS. Dessa två paket ges en närmare beskrivning nedan. Vad gäller Embedded GIS och Mobile GIS hänvisas till ESRI på http://www.esri.com/software/arcgis/index.html varifrån informationen om ArcGIS är hämtad. En översiktsbild av hela ArcGIS-konceptet visas i figur 7.

20

.

3DkA

AGv

APig

AM

Figur 7 Översiktsbild över ArcGIS 9. (ESRI, 2001–2004)

.2.1 Desktop GIS esktop GIS är ArcGIS:s klientprogramvara. I paketet återfinns dels det som allas ArcGIS Desktop dels utvecklingsprodukten Desktop Development Kit. rcGIS Desktop finns i fyra versioner med ökande grad av funktionalitet:

rcReader ratis tittskåp skapat för att kunna titta på och skriva ut kartor. Kartorna måste ara skapade med ArcGIS Publisher Extension.

rcView rogramvara där man har möjlighet till analysarbete av och med geografisk

nformation. Dessutom går det att skapa kartor för publicering samt att anpassa ränssnittet.

rcEditor ed detta verktyg ingår utöver funktionaliteten i ArcView även möjlighet till:

redigering av de geografiska objekten

skapande av geodatabaser

redigering av geografiska data av flera användare

hantering av topologiska relationer mellan geografiska objekt

versionshantering.

21

ArcInfo ArcInfo är toppversionen av ArcGIS Desktop. Utöver funktioner i ArcEditor finns bl.a:

större möjligheter att bygga avancerade verktyg för geobearbetning

överlagringar av vektorbaserade datalager, närhetsanalys och statistiska analyser

datakonverteringar.

Dessa fyra versioner av ArcGIS Desktop är i sig uppbyggda med hjälp av ett antal applikationer och tilläggsmoduler. Applikationerna ingår i plattformen med olika grad av funktionalitet beroende på version.

ArcMap är den centrala applikationen i ArcGIS Desktop där man arbetar med analys och redigering av kartor och övriga geografiska data.

ArcCatalog organiserar och hanterar den information man vill använda sig av i sitt GIS.

ArcToolbox innehåller färdiga verktyg (eng: tools) för geobearbetning. Ett verktyg utför en väl definierad process på GIS-data med inparametrar och utdata. Verktygen är sorterade i verktygsgrupper (eng: toolsets) där verktyg med liknande uppgifter samlas. Dessa verktygsgrupper sparas sedan i verktygslådor. Man kan som användare själv sortera och skapa egna verktygs-lådor.

ModelBuilder är applikationen för att på grafisk väg skapa egna verktyg s.k. modeller för arbetsflöden och processer man som användare vill automatisera. Modellerna sparas i ArcToolbox.

ArcGlobe används för visualisering och hantering av geografiskt data i 3D.

Utöver dessa applikationer finns sedan möjligheten att utöka programvaran med tilläggsmoduler (eng: extensions). Dessa tilläggsmoduler kan vara ESRI-moduler men det går även att integrera moduler från andra leverantörer eller egenhändigt utvecklade. Den tilläggsmodul som används i detta arbete är ArcGIS Network Analyst (se avsnitt 3.6).

3.2.2 Server GIS Server GIS används för alla typer av centralt hanterade GIS-aktiviteter. I server GIS ingår tre mjukvaruprodukter: ArcSDE, ArcGIS Server och ArcIMS.

ArcSDE är den programvara som behövs för att hantera spatial data i ett DBMS.

ArcGIS Server är en plattform för utveckling av serverbaserade GIS-lösningar och webbapplikationer. Används för att bygga flerskiktslösningar och applikationsservers.

ArcIMS är ESRI:s webbserverlösning. Den används för att leverera kartor, övriga geografiska data och tillämpningsanpassade applikationer via webben till användare. Webbläsare, ArcGIS Desktop-klienter och mobila enheter kan koppla upp sig mot ArcIMS.

22

3.3 Lagringsstrukturer och datakällor ArcGIS arbetar i huvudsak med tre lagringsstrukturer. Förutom de tidigare beskrivna raster- och vektorstrukturerna kan ett datalager lagras som ett TIN (Triangulated Irregular Network). TIN:s är en vektorstruktur som används för att representera ytor och består av sammanlänkade trianglar.

Dessa lagringsstrukturer används sedan för lagring och läsning från en mängd olika datakällor i både filformat och DBMS. De två typer som använts i detta arbete är shapeformatet och geodatabasen. En annan lagringsstruktur som är vanligt förekommande i ESRI:s produkter är coverage-strukturen som används i framförallt applikationen ArcInfo Workstation.

3.3.1 Shapeformatet Shapeformatet är ett filformat framtaget av ESRI. Det lagrar geometriska egenskaper och attribut i vektorformat. De geometriska grundelement som formatet klarar är punkter, linjer och ytor. Topologiska egenskaper hanteras inte.

Shapeformatet består alltid av minst tre filer (ESRI, 1998):

Huvudfil filnamn.shp Innehåller geometrin Indexfil filnamn.shx Innehåller indexering till huvudfilen Attributfil filnamn.dbf Innehåller attributtabell i dBASE-format

3.3.2 Geodatabasen ESRI:s geodatabas är en objektorienterad datamodell för hantering av rumsligt data. Med en objektorienterad modell vill man låta den fysiska implementeringen närma sig den logiska modellen. De geografiska objekten ska själva hantera egenskaper och funktioner som exempelvis topologiska relationer, äganderelationer, kartografiska egenskaper (hur objekten ska ritas ut på en karta) m.m.

Andra mål man vill uppnå med geodatabasen är:

All geografisk information samlad i en central databas.

Hög kontroll av dataredigering genom att objekten validerar sina egna indata.

Intuitiv och enkel hantering av geografiska data i och med att användare inte arbetar med enbart de grundläggande geometriska grundobjekten utan med geoobjekt som vägar, sjöar osv.

Bra kontroll för fleranvändarsystem. Många användare kan redigera data samtidigt.

En geodatabas kan innehålla alla de ovan nämnda lagringsstrukturerna: TIN:s, vektor- och rasterdata men arbetar i huvudsak med vektordata. Dessutom finns här ytterligare en typ av datastruktur som hanterar adresser och s.k. address locators (Zeiler, 1999).

23

Figur 8 Geodatabasen som ett applikationslager ovanpå databasen. (ESRI, Geodatabase)

Geodatabasen fungerar som ett applikationslager mellan klient och databas och tillhandahåller sammansatta datatyper för geometriska objekt samt en mängd funktioner för hanteringen av dessa (se figur 8). Den underliggande databasen kan vara någon av de på marknaden befintliga DBMS. Enanvändar-systemet använder sig av Microsofts Jet Engine (Access). Hela databasen sparas då som en mdb-fil i filsystemet. För att implementera ett fleranvändar-system krävs ett DBMS som tillåter flera användare (se tabell 1). Detta kräver också installation av ArcSDE.

Tabell 1 Olika implementeringar av en geodatabas. (ESRI, Geodatabase) Typ av geodatabas:

DBMS: Kortfakta:

Personlig geodatabas

Microsoft Jet Engine (Access) o Enanvändarsystem o Max 2GB o Ingen versionshantering

Geodatabas för fleranvändare

o Oracle o Oracle med Oracle Spatial

eller Oracle Locator o IBM DB2 o IBM Informix o Microsoft SQL Server

o Kräver ArcSDE o Fleranvändarsystem o Versionshantering o Databasstorlek och antal

användare begränsas av RDBMS

Den vektorbaserade strukturen hanteras i geodatabasen av geoobjektklasser (eng: feature class). En geoobjektklass innehåller en samling geoobjekt (eng: feature) och visas i ArcMap som ett datalager. Ett geoobjekt innehåller alltid ett fält som heter shape och är av typen geometry. Shapefältet refererar till ett geometry-objekt som innehåller geometri och lokalisering för geoobjektet. Alla geoobjekt i en geoobjektklass har samma typ av geometri. Geometrin är en av följande:

Point är ett geoobjekt med en x, y-koordinat (ev. x, y, z).

Multipoint är ett geoobjekt med ett antal x, y-koordinater (ev. x, y, z). Ingen ordning mellan koordinaterna.

Polyline är ett geoobjekt med en eller flera paths. En path är en samling segments som var och en kan vara av typen line, circular arc, elliptical arc eller Bézier curve.

24

Polygon är ett geoobjekt med en eller flera rings. En ring är en cykel samman-satt av en mängd segments. En ring kan inte korsa sig själv men kan korsa andra rings i en polygon.

Multipatch är ett geoobjekt i 3D. Genereras med hjälp av TIN:s och geoobjekt av typer polygon.

I beskrivningen ovan har de engelska namnen på datatyperna (klasserna) behållits men skrivits i kursiverad stil. En förenklad objektmodell för geometri och lagringsstrukturer i geodatabasen finns i bilaga F.

Administration av geodatabasen sköts genom ArcCatalog via ett gränssnitt som påminner om utforskaren i Windows. I denna applikation skapas personliga geodatabaser, geoobjektklasser och geodataset. Ett geodataset kan ses som en samling av geoobjektklasser som har samma referenssystem. Här finns möjligheten att samla geoobjektklasser som har någon gemensam koppling i övrigt till varandra. Exempelvis kan det vara lämpligt att samla datalager som fungerar som bakgrundskartor i ett dataset. Topologiska nätverk måste ligga i ett geodataset. Figur 9 visar hur en geodatabas åskådliggörs i ArcCatalog samt några olika typer av dataobjekt och strukturer.

3Vsiagä

Dis

Fs

Figur 9 Vy från ArcCatalog över en geodatabas med ett antal dataobjekt. Skärmdump från ArcGIS 9.1 Network Analyst.

.3.3 Kartor och lager id all hantering av kartor i ArcMap skapas ett kartdokument (.mxd) som

paras i filsystemet. Kartdokument innehåller i sig ingen geografisk nformation utan är ett dokument med länkar till resurser som datalager och ndra datakällor. Annan information som sparas i kartdokumentet är karto-rafiska egenskaper (t.ex. symbologi) och applikationsinställningar. Det finns ven möjligheten att skapa kartmallar (eng: templates).

atalagren i en kartfil kan sparas som separata lagerfiler (.lyr). Lagerfiler nnehåller även de endast länkar till datalagrets geografiska information plus ymbologi.

ör att underlätta hantering av konsekvent symbologi finns möjligheten att para och läsa separata style-filer som innehåller de kartografiska symbolerna.

25

3.4 Den rumsliga domänen Att på digital väg arbeta med geografiska koordinater kräver förutom ett referenssystem även en definierad rumslig domän (eng: spatial domain). I den rumsliga domänen anges hur stort geografiskt område som ska täckas samt med vilken precision koordinater anges.

Geodatabasen sparar en koordinat som ett positivt 4-bytes heltal med ett max-värde på 2 147 483 648. Detta gör att all databearbetning med koordinater görs på heltal. Fördelen med detta är att operationer med heltal går snabbare än motsvarande operationer med flyttal. Dessutom är det möjligt att komprimera heltal vid lagring vilket ger möjligheten att spara minnesplats, något som ArcSDE utnyttjar.

För att kunna representera koordinater med olika precision använder sig geo-databasen av begreppet minsta lagringsenhet (eng: storage unit). Heltalet på 4 bytes representerar just den minsta lagringsenheten. Detta får till följd att även om koordinatsystemets enhet är meter kan heltalet representera t ex 1 cm. För att konvertera mellan lagringsenheten och koordinatsystemets enhet lagras en precision som beskriver förhållandet mellan dessa enligt följande:

Lagringsenhet = koordinatsystemets enhet / precision

Följande tabell fås ur detta förhållande:

Lagringsenhet Koordinatsystemets enhet

Precision

1 cm meter 100 1 mm meter 1000 2 cm meter 50

Förhållandet styr också direkt max- respektive minvärde för koordinater angivna i geodatabasen dvs den rumsliga domänen. Hög precision ger liten rumslig domän (litet geografiskt område) mindre precision ger större rumslig domän. Den rumsliga domänen bestämmer inte bara utbredningen i planet, dvs x/y-koordinaterna utan innefattar även höjd (z-koordinaten) och mätningar (m-värden). Ofta benämns utbredningen i planet för x/y-domänen (ESRI, ArcGIS Desktop Help).

Att försöka lägga till ett datalager vars koordinater ligger utanför den satta rumsliga domänen kommer att resultera i ett felmeddelande som anger att x/y-koordinaterna ligger utanför x/y-domänen.

3.5 Adressmatchning i ArcGIS Vid automatiserad adressmatchning i ArcGIS används en s.k. adressplacering (eng: adress locator) som är en fil med referenser till de resurser som krävs för adressmatchningen. Resurserna består bl.a. av en eller flera referensdatakällor och regelverk för adressmatchningen. Förfarandet vid adressmatchning av en adress är indelat i ett antal moment. I första steget delas adressen upp i ett antal adresselement. Dessa kan vara gatunamn, gatunummer, postnummer etc. Adresselementen skickas sedan vidare för standardisering. Detta kan exempelvis innebära att ändelsen -gatan i gatunamn (ex: Storgatan) som ofta

26

skrivs som endast -g (ex: Storg.) konsekvent skrivs och hanteras som -gatan. En del av adresselementen indexeras därefter så att snabb sökning i referens-datakällor kan utföras. Alla möjliga matchningar returneras med en beräknad matchningspoäng (se figur 10). Olika möjligheter finns sedan att välja den slutgiltiga matchade adressen baserat på matchningspoängen.

Fpfm

FR

3TrtAheme

3A

RRkah

Figur 10 Översiktlig beskrivning av förfarandet i ArcGIS vid adressättning.

ör att skapa en adressplacering använder man en mall som benämns adress-laceringsstil (eng: address locator style). Sådana mallar finns för adress-ormat i ett antal olika länder t.ex. Sverige. Dessutom finns mallar för att atcha mot gatuadresser, postnummerområden osv.

ör mer läsning om adressmatchning hänvisas till ESRI (2003), Geocoding ule Base Developer Guide.

.6 Network Analyst illäggsmodulen Network Analyst (NA) ger användare möjligheten att utföra

umsliga analyser som bygger på ett nätverk av något slag. NA finns sedan idigare som tillägg till ArcView 3.x och ArcInfo Workstation. Network nalyst för ArcGIS har varit utannonserad sedan ett antal år tillbaks men det ar tagit sin tid innan releasen blev ett faktum. Inom detta projekt är det därför n betaversion som testats. Den skarpa versionen släpptes i slutet av maj ånad 2005. NA för desktop kräver en installation av ArcView, ArcEditor

ller ArcInfo.

.6.1 Funktioner nalysfunktionerna i NA är:

uttberäkningar (eng: routing) uttberäkningar görs över ett eller flera sammankopplade nätverk, det senare allat multimodala nätverk. Exempel när multimodala nätverk kan komma till nvändning är när tillgänglighetsanalys inom ett samhälle ska göras och änsyn ska tas till transport med bil via vägnät och kollektivtrafik i form av

27

busslinjer. Då fungerar vägnätet och busslinjenätet som två separata transport-nätverk som kopplas ihop till ett multimodalt nätverk.

Multipunktsrutter (eng: Multipoint routing) kan utföras med eller utan om-ordning av stoppen. Med omordning innebär ett TSP-problem. Tidsfönster kan användas. Detta innebär att de ingående stoppen i en rutt tilldelas ett tids-intervall inom vilket besöket (stoppet) måste utföras. Ruttberäkningen görs sedan med hänsyn till dessa tidsintervall. Går ej rutten att genomföra utan att bryta något stopps tidsfönster ges ändå ett förslag på rutt med de överskridna tidsfönstren angivna. För ytterligare beskrivning av vad ruttberäkningar innebär se avsnitt 2.6.

Körinstruktioner Utifrån en angiven rutt kan körinstruktioner ges. Körinstruktionerna innehåller en detaljerad beskrivning över vägval och avstånd med möjlighet att få med kartbilder över vägvalssituationer och stopp.

Upptagningsområde (eng: Service areas) Beräkning av upptagningsområde kan användas för att modellera:

försörjningstider genom ett transportnätverk

utryckningstider genom ett vägnät

upptagningsområde av exempelvis elever till skolor.

Nytt för denna version av NA är att upptagningsområdena nu visas med komplexa polygoner. Detta innefattar även ”öar” i polygonerna dit inte nät-verket når (se bilaga H).

Närmsta facilitet (eng: Closest facility) Beräknar avstånd till närmaste facilitet. Kan användas av exempelvis räddningstjänst för att ange närmaste sjukhus från en olycksplats. Ett annat användningsområde av denna funktion är i transportnavigeringssystem som anger t.ex. närmaste bensinstation utifrån fordonets aktuella position.

OD-matris (eng: Origin – Destination matrix) NA kan utifrån angivna startpunkter (eng: origins) och destinationspunkter beräkna en OD-matris. Detta är en matris som anger kostnaden att ta sig från en startpunkt till en destinationspunkt. Kostnaden kan t.ex. vara avstånd eller tid beroende på vald impedans. Exempel på en OD-matris visas i figur 11.

28

3.6.2 Arbetsmiljö När man som användare arbetar med Network Analyst görs det i huvudsak via tre gränssnitt:

ArcCatalog och guiden ”New Network Dataset”.

ArcMap och fönstret ”Network Analyst”.

ArcMap och verktygsfältet ”Network Analyst”.

Dessutom finns i ArcToolbox ett antal verktyg för geobearbetning i Network Analyst.

Guiden ”New Network Dataset” hjälper användaren att skapa ett nätverksdata-set som sedan används vid analysen i Network Analyst. Här sätts parametrar och ingående underliggande vägnät som nätverket ska bygga på.

Verktygsfältet ”Network Analyst” tillhandahåller de verktyg som krävs vid analys av nätverk. Här finns också verktyg för att skapa nya analyslager och bygga och titta på nätverksdataset. (Se figur 12.)

Figur 12 Vy över verktygsfältet Network Analyst. (ESRI, ArcGIS Desktop Help)

Figur 11 Exempel på OD-matris som visar avståndet mellan att antal orter i Sverige. Här används samma geografiska punkter som både start- och destinationspunkter.

29

Fönstret ”Network Analyst” visar stopp, barriärer och rutter för valt analys-lager. Härifrån kan man också komma åt konfigurationsinställningar för analyslagret. (Se figur 13.)

En del av de begrepp som använts här beskrivs i avsnitt 3.7.

3TAEnteni

Eggvggnn

Figur 13 Vy över fönstret ”Network Analyst”. (ESRI, ArcGIS Desktop Help)

.7 Nätverksdataset ill grund för alla typer av analyser i Network Analyst ligger ett nätverk. I rcGIS geodatabas benämns detta för nätverksdataset (eng: network dataset). tt nätverksdataset byggs (genereras) av NA med hjälp av tre olika typer av ätverkselement. Det är de geoobjekt som ingår i nätverket. Dessa kan vara av ypen linje-, punkt- eller svängobjekt. Linjeobjekt representerar oftast vägar ller andra typer av transportlänkar medan punktobjekt representerar noder i ätverket där linjeobjekt ansluter varandra. Svängobjekt representerar svängar nätverket (se avsnitt 4.2.7).

tt nätverksdataset i en geodatabas måste byggas i ett geodataset. De eoobjekt som nätverksdatasetet ska genereras från hämtas från ett antal eoobjektkällor som då är geoobjektklasser liggandes i datasetet. När ett nät-erksdataset är byggt visas det i ArcCatalogs gränssnitt som en eoobjektklass. Förutom själva nätverksdatasetet genereras även en eoobjektklass innehållandes de noder som agerar anslutningspunkter i ätverket. I figur 14 visas en exempelvy ur ArcCatalog efter att ett ätverksdataset byggts.

30

Mfln

Sbbk

Aneseu

3Ma(eee

Figur 14 Exempelvy ur ArcCatalog efter att ett nätverksdataset skapats. Skärmdump från ArcGIS 9.1 Network Analyst.

öjligheten finns även att skapa ett nätverksdataset som bygger på shape-ormatet. Begränsningen ligger då i att antalet geoobjektkällor begränsas till en injeobjektskälla och en svängobjektskälla. Detta medför att multimodala ätverk ej kan byggas på shapeformatet.

kapandet av ett nätverksdataset delas in i två moment: konfigurering och ygge. Vid konfigurering sätts alla parametrar för nätverksdatasetet. Därefter yggs datasetet och det är då de topologiska strukturerna skapas. Ändras onfigurationen för nätverksdatasetet efteråt måste det byggas på nytt.

ll konfiguration görs i guiden ”New Network Dataset” vid skapande av ett ätverksdataset. I följande avsnitt följer en beskrivning av ett urval av de genskaper som ska sättas. Urvalet är baserat på vilka egenskaper som är av törre relevans för fallet Falköping. För beskrivningar av resterande genskaper hänvisas till ArcGIS Desktop Help avsnittet för Network Analyst r vilket nedanstående beskrivning är hämtat.

.7.1 Anslutning ed anslutning menas här anslutning mellan länkar. Informationen om hur

nslutningar ska göras ligger i något som kallas anslutningsgrupper eng: connectivity groups). Eftersom det är möjligt att i ett nätverksdataset (i n geodatabas) använda sig av flera geoobjektkällor tilldelas varje linjekälla xakt en anslutningsgrupp. En punktkälla används som koppling mellan två ller flera anslutningsgrupper genom att tilldelas de relevanta grupperna.

31

ODle”afdpd

Ä”gn

Figur 15 Exempel på hur anslutningsgrupper kan användas för att skapa ett multimodalt nätverk. Här går transportflödet mellan de båda nätverken järnvägar och vägar via noderna/hörnen järnvägsstationer. Skärmdump från ArcGIS 9.1 Network Analyst.

bservera att val ska göras av anslutningspolicy (eng: Connectivity Policy). enna egenskap anger på vilket sätt anslutningar ska göras mellan länkar. För

injekällor finns två valmöjligheter. Värdet ”End Point” anger att länkarna ndast ska anslutas i länkarnas sammanfallande start- och slutnoder. Värdet Any vertex” medför att länkarna i en anslutningsgrupp ansluts med varandra i lla korsande punkter. Detta medför också att länkarna delas i varje samman-allande punkt och en nod läggs till vid den punkten. Skillnaderna mellan essa två lägen kan också beskrivas som att värdet ”Any Vertex” ger en s.k. lanär graf medan värdet ”End Point” kan ge en icke-planär graf beroende på e ingående kanternas geometriska förhållande till varandra (se figur 16).

Figur 16 Beskrivning av skillnaden mellan värdena ”End Point” och ”Any Vertex” för egenskapen Connectivity policy i ett nätverksdataset.

ven för punktkällor ska val av anslutningspolicy göras. Där finns värdet Honor” som anger att anslutningspolicyn för linjekällorna ska följas vilket er att punkterna i punktkällan kommer att fungera som anslutande noder i ätverket endast om de sammanfaller med noder för de ingående linjekällorna.

32

Värdet ”Override” anger att punkterna alltid kommer att fungera som anslutande noder i nätverket. Det räcker med att de sammanfaller med länkarna i linjekällorna.

3.7.2 Nätverksattribut Nätverksattribut (eng: network attributes) anger egenskaper som påverkar framkomligheten i nätverket. Exempel på sådana attribut är tid för att ta sig fram över en väg, längden på vägen eller om en väg är enkelriktad. Nätverks-attributen delas in i fyra kategorier:

Kostnad (eng: cost) är det attribut som används för att modellera impedans i ett nätverk. Det är en typ av attribut som är proportionellt fördelad längs med en länk. Typfallen är tid eller sträcka. Om det tar 50 minuter att färdas längs med en länk i nätverket tar det 25 minuter att förflytta sig halvvägs längs med länken. Datatypen för en kostnad måste vara någon av Integer, Float eller Double.

Observera att man gärna skiljer på begreppen kostnad och impedans i detta avseende. Kostnad är en egenskap som de ingående nätverkselementen har. Nätverkselementen i ett nätverksdataset kan ha flera kostnader. När väl en analys (beräkning) ska göras på nätverket väljs en kostnad som den modellerade impedansen.

Beskrivning (eng: descriptor) är attribut som till skillnad från kostnad inte kan ses som fördelad längs med en länk. Det är istället en egenskap som gäller för hela länken. Exempel på detta kan vara att en väg består av två körbanor eller vägens lutning. Datatypen för en beskrivning måste vara någon av Boolean, Integer, Float eller Double.

Ett attribut av typen beskrivning kan användas för att modellera en impedans tillsammans med exempelvis tid eller sträcka. Till exempel kan vägens lutning kombinerat med vägens längd användas som impedans vid ruttberäkningar.

Restriktioner (eng: restrictions) används för att ange om hinder i fram-komlighet på en väg föreligger. Exempel på restriktioner är enkelriktat, max totalvikt eller förbjuden infart. Datatypen för en restriktion är Boolean.

Hierarki (eng: hierarchy) är ett attribut som används för att indela de ingående länkarna i en hierarkisk struktur. Används framförallt när man vill ta hjälp av en vägklassindelning för att prioritera trafik längs vägar av högre standard eller större betydelse. Datatypen är Integer.

Samtliga typer av attribut kan sättas på alla tre typer av nätverkselement, dvs länkar, noder och svängar.

3.7.3 Evaluerare Nätverksattributen måste tilldelas ett värde. Detta görs via evaluerare (eng: evaluators). Till varje kombination av attribut och geoobjektkälla tilldelas en evaluerare som genererar attributets värde. Fyra typer av evaluerare finns:

Fältevaluerare (eng: field evaluator) hämtar värdet från ett specifikt fält i attributtabellen till geoobjektkällan.

33

Fältuttrycksevaluerare (eng: field expression evaluator) ger ett värde som baserat på ett fältvärde, beräknats med hjälp av ett uttryck. Kan användas om man t.ex. vill räkna om värden i ett fält från en enhet till en annan.

Konstantevaluerare (eng: constant evaluator) tilldelar attributet ett angivet konstant värde.

VB-scriptevaluerare (eng: VBScript evaluator) innebär att attributet tilldelas ett värde som returneras av ett VB-script.

En viktig skillnad mellan de tre först nämnda evaluerarna och VB-script-evalueraren är att de tre första sätter värdet när nätverksdatasetet byggs. Detta innebär att om man vill ändra dessa värden måste nätverket byggas om. VB-scriptevalueraren däremot generar värdet under analysens gång och då attributets värde behövs. Detta ger möjligheten till dynamiska analyser med realtidsdata. Exempelvis kan en kostnad baserad på den momentana trafik-mängden för en väglänk användas som impedans i en navigeringsapplikation.

3.7.4 Svängar Svängar (eng: turn features eller bara turns) används för att representera svängar i korsningar i ett transportnätverk. De modelleras i geodatabasen som geoobjekt. Skillnaden mot andra geoobjekt är att svängobjekten saknar betydelse utanför ett nätverksdataset. Svängobjekten består av referenser till de i nätverksdatasetet ingående linje- respektive punktobjekten. Detta gör att en svängobjektklass alltid måste lagras i ett geodataset eller kopplat till shape-formatet.

En sväng består av två eller fler länkar som anges i sekvens i den ordning de uppträder i svängen (se figur 17).

Figur 17 Representation av svängobjekt görs genom att ange en sekvens av länkar som ingår i svängen.

Svängobjekten sparas i en svängobjektklass (eng: turn feature class). Observera att svängobjektet refererar till de underliggande ingående länkarna men har ändå en egen geometri kopplad till sig som används vid utritning och redigering av svängobjektet. Dess attributtabellstruktur finns specificerad i bilaga G.

34

3.7.5 Bygge av nätverksdataset När väl alla geoobjektkällor och parametrar är satta skapar NA en instans av ett nätverksdataset. I nästa steg bygger NA sedan upp det topologiska nätverk som ska användas för analys. Så länge inte nätverksdatasetet är korrekt byggt går det inte att genomföra någon analys med hjälp av det.

3.8 Ruttberäkningar i Network Analyst Här följer en beskrivning över tillvägagångssätt och konfigurering för att utföra ruttberäkningar i NA. Som det beskrevs i avsnitt 3.6.1 är rutt-beräkningar en av ett antal möjliga typer av analyser. Det är dock endast ruttberäkningar som behandlas i det här arbetet.

3.8.1 Analyslager Alla typer av analyser i NA redovisas och hanteras via ett analyslager (eng: analysis layer) så även ruttberäkningar. Ett analyslager har samma egenskaper som andra datalager förutom att det inte sparas som en enskild fil eller geoobjektklass av operativsystemet. Lagret hanteras i internminnet och sparas tillsammans med kartfilen (.mxd). Möjligt är däremot att exportera analys-lagret till en fil eller geoobjektklass.

3.8.2 Network locations (platser) Network locations är olika typer av geoobjekt som används vid analyser i NA. I samband med ruttberäkningar är det två typer av network locations som är aktuella, stopp (eng: stop) och barriär (eng: barrier). Ett stopp är ett objekt som kan representera ruttens start- eller slutpunkt likaväl som det kan representera ruttens besökspunkter (tidigare även benämnt stopp). En barriär representerar en passage som inte kan genomkorsas. Används till exempel vid ruttberäkningar då ett vägbygge omöjliggör framkomst över en korsning.

Stopp kan läggas till ett analyslager på två sätt. Antingen görs det manuellt via skärmens kartvy eller genom att importera geoobjektklasser med punktobjekt. Den manuella metoden innebär att interaktivt lägga till ett stopp i taget i den kartvy som visar analyslagret. Import av geoobjektklasser tillåter däremot att stora mängder stopp på ett enkelt sätt kan hanteras.

Gemensamt för de båda metoderna är att stoppen måste anslutas till nätverket. Det är högst troligt att punkten som representerar stoppet inte har koordinater som exakt ansluter till någon av nätverkets länkar eller noder. För att lösa detta söker NA i en omgivning kring stoppet efter länkar och/eller noder som stoppet kan anslutas till. Hur stor omgivning som ska genomsökas sätts med egenskapen sökområde (eng: search tolerance). I första hand väljs det närmaste nätverkselementet men andra möjligheter finns t.ex. i samband med multimodala nätverk. Om ett stopp inte kan anslutas kommer det inte kunna användas vid ruttberäkningar.

Stoppen lagras i analyslagret och de är därmed inte geoobjekt i den meningen att de lagras i en separat shapefil eller som en egen geoobjektklass. Däremot finns en attributtabell för stoppen. I denna tabell finner man bl.a. tidsfönster för vardera stopp.

35

3.8.3 Egenskaper för rutten/analyslagret Innan NA utför några ruttberäkningar är det ett antal egenskaper för analys-lagret och därmed för ruttberäkningen i sig som ska beaktas. Några av dessa är:

Impedans – Ruttberäkningen är en effektivitetsberäkning som ska baseras på någon impedans eller kostnad. Vilka impedanser det finns att välja mellan bestäms av det nätverksdataset som analyslagret använder sig av.

Tidsfönster – Om tidsfönster ska användas eller ej.

Omordning – Om omordning av stoppen i rutten ska göras eller ej. Om så är fallet är ruttberäkningen ett TSP-problem med tillägget att noder (och stopp) får besökas flera gånger. Här bestäms också om första och/eller sista stopp, sett utifrån den ordning man som användare placerat dem i, ska behålla sin plats.

Hierarki – Om hänsyn ska tas till eventuell hierarkisk struktur på transport-nätverket.

Restriktioner – Här anges om hänsyn till restriktioner ska tas. Varje specifik restriktion som finns med i nätverksdatasetet återfinns i en lista och kan väljas med eller ej.

Ytterligare några egenskaper är möjliga att sätta men tas inte specifikt upp här.

3.8.4 Val av algoritm Network Analyst använder sig slutligen av analyslagrets satta egenskaper när ruttberäkningen körs. Val av algoritmer görs utifrån dessa värden. Exakt vilka algoritmer som faktiskt används av en produkt vid ett specifikt problem är oftast en väl bevarad hemlighet. När det gäller ESRI:s produkter nämns det i ett antal publikationer att algoritmen (-erna) som används är Dijkstras. Någon tydligare förklaring har varit svår att finna. Därför ställdes frågan till ESRI Sweden som vidarebefordrade den till berörd personal på ESRI:s huvudkontor i USA. Svaret som ges är följande:

För ruttberäkning utan omordning av stopp och utan hänsyn till hierarkiskt nätverk används Dijkstras kortaste-väg-algoritm med heapimplementation. Om hänsyn ska tas till hierarkiskt nätverk används en algoritm baserad på Dijkstra men med heuristiskt baserade val när det gäller val av vägklass.

För ruttberäkningar med omordning av stopp används metoden där man i ett första steg tar fram en OD-matris med hjälp av Dijkstras algoritm. I ett andra steg används den heuristiska metoden Tabu-sökning (se bilaga A).

3.8.5 Resultat Resultatet av en ruttberäkning ses bäst i attributtabellen för stoppen. Där finns en mängd information att hämta. Som användare gäller det att hitta det som är relevant för den genomförda analysen. Informationen lagras i tabellen som egenskaper för respektive stopp. Exempel på information som kan utläsas i tabellen är:

36

Sekvensnummer i rutten. (Intressant om omordning av stoppen använts.)

Start och sluttid av tidsfönster.

Av rutten utförd ankomsttid och avgångstid.

Status – dvs om tidsfönstret för stoppet lyckats hållas i rutten.

Stopptid – dvs hur lång tid stoppet beräknas ta.

Ackumulerad restid fram till och med stoppet.

Ackumulerad avverkad distans fram till och med stoppet.

37

4 Vägdatabas För att arbeta med ruttplanering och ArcGIS Network Analyst krävs en under-liggande vägdatabas. Denna används av NA för att bygga upp det topologiska nätverk som sedan används vid nätverksberäkningar. Kapitlet ger en över-siktsbild över vägdatabasen Tele Atlas MultiNet. Strukturen på databasen vid leverans i shapeformat beskrivs. Tabeller och attribut som är relevanta för genomförandet av ruttberäkningar i fallet Falköping redovisas. Framförallt är det databasens nätverksdatalager som tas upp men även datalagret för geo-kodning nämns.

Inledningsvis nämns några andra förekommande vägdatabaser.

4.1 Andra vägdatabaser Inom GIS-branschen i Sverige nämns idag framför allt två kommersiella väg-databasleverantörer, Navteq och Tele Atlas. I dessa sammanhang nämns gärna också den av Vägverket framtagna nationella vägdatabasen (NVDB). En stor skillnad mellan NVDB och de kommersiella databaserna är att NVDB inne-håller rådata som inte är direkt anpassat för en specifik applikation. De kommersiella produkterna levererar däremot data i format som är direkt tillämpningsbara för exempelvis ArcGIS desktop-produkter.

Nationell vägdatabas Nationell vägdatabas (NVDB) är en rikstäckande vägdatabas framtagen av Vägverket på svenska regeringens direktiv. Ett allt större behov av digital väg-information på såväl privat som offentlig marknad låg bakom detta direktiv. NVDB drivs idag av Vägverket tillsammans med Lantmäteriverket, Svenska kommunförbundet och skogsnäringen. Tänkta användningsområden är väg-informatik, samhällsplanering och väghållning. Med begreppet väginformatik menas ”användandet av informationsteknologi i vägtransportsystem” (Vägverket).

NVDB innehåller information om statliga, kommunala och enskilda vägar. Dataleverantörer till NVDB är förutom vägverket även kommuner, skogs-näring och lantmäteriverket (Vägverket).

38

LIaDkamat

L

NNpouVå

Figur 18 Verksamhetsmodell NVDB. (Vägverket)

VDB T-företagen Tekis AB, TDP Trafikdata Produkter AB och Decerno AB rbetar med en vägdatabas som går under namnet Lokal Vägdatabas. atabasen utvecklades för Stockholms kommun men har nu köpts in av andra ommuner som t.ex. Göteborg och Malmö (Tekis AB, 2004). LVDB är tänkt tt agera som ett referenssystem till det data som kommunen redan arbetar ed. Informationen struktureras så att den blir lättare tillgänglig för olika

pplikationer. Detta möjliggör också fortlöpande utbyte mot externa data som .ex. NVDB (Wiik, 2003).

VDB baseras på standarden för Väg och Järnväg, SS 63 70 04 (Stanli, 2003).

avteq avteq är ett amerikanskt företag som levererar digital kartdata. Deras rodukter används i navigationssystem och GIS-applikationer i Nordamerika ch Europa. Enligt deras egen information ombesörjs insamlandet av data av pp till 500 personer som helt enkelt testkör och loggar vägnätet. ägdatabasen används exempelvis i DPS Internationals Route-LogiX. Svensk

terförsäljare finns i Nacka, Stockholm. (Navteq)

39

4.2 Tele Atlas Tele Atlas är ett världsomspännande företag som framställer digitalt kartdata. Användningsområdena är liksom för Navteq inom navigationssystem och de flesta områden där ett GIS i samband med transportnät används. Här följer en övergripande beskrivning av Tele Atlas MultiNet 2004.2 version 3.3.

4.2.1 Inledning Tele Atlas MultiNet benämns vägdatabas men produkten som sådan rymmer egentligen mer. Förutom vägnät med attribut finns även adressinformation och andra typer av geografiska datalager som exempelvis vattendrag, kommun-gränser osv (se tabell 2).

Tabell 2 Överblick av information som finns i Tele Atlas samt användningsområde.

Innehåll Exempel på användning

Väg- och svänginformation Ruttberäkningar, transportplanering

Adressinformation och ”Platser av särskilt intresse”

Geokodning

Markanvändningsinformation, vattendrag, regioner mm.

Presentation av kartor

Om inte annat anges är informationen om Tele Atlas MultiNet i detta avsnitt (4.2) hämtat från den dokumentation som medföljer databasen (Tele Atlas). En beskrivning av dessa dokument ges i tabell 3.

Tabell 3 Beskrivning av de dokument ur MultiNet:s dokumentation som information till detta arbete hämtats från.

Filnamn Beskrivning

MultiNet_UserGuide_Shapefile_v1.41.pdf Användarhandledning. Hänvisar ibland till övrig dokumentation.

MultiNet3.3_Data_Specs_v1.0.pdf Beskriver vilken information och vilka begrepp från den reella världen som samlas in och lagras i databasen samt relationer mellan dessa begrepp.

MultiNet_3.3_Data_Model-v1.0.pdf Objektmodell för informationen specificerad i MultiNet3.3_Data_Specs_v1.0.pdf.

Shapefile_4_2_1_Format_Specifications_v1-1.pdf

Beskriver tabellstrukturer för attributtabeller och övriga tabeller i shapeformatet.

Release_notes_sweden2004.2_v2.pdf Information specifikt för data täckande Sverige.

Tele Atlas MultiNet levereras i två olika format: Shapeformat och Oracle SDO-format. I detta arbete har en version i shapeformat använts. Shape-

40

formatet ger användaren enkel och optimerad access till lager och tabellformat för direkt användning i en applikation.

Det geodetiska referenssystem som används för Europa är WGS84 men kon-verterade leveranser går att få direkt från den svenska återförsäljaren, Swegis AB.

4.2.2 Abstraktionsnivåer Tele Atlas bygger sin databas på tre stycken abstraktionsnivåer där graden av abstraktion ökar för varje ny nivå. Databasen är objektorienterat där objekten på de högre abstraktionsnivåerna refererar objekten på de lägre nivåerna.

Nivå 0 På nivå 0 representeras objekt från verkligheten med hjälp av de tre primitiva grundelementen punkt, linje och yta (se avsnitt 2.2) som i detta sammanhang benämns:

noder – representeras av endast ett koordinatpar

kanter – representeras av en sekvens av minst två koordinatpar

ytor – representeras av en polygon.

Nivå 0 är en planär graf, verkligheten modelleras i två dimensioner vilket gör att inga korsande kanter existerar (se figur 19). Nivån innehåller enbart geometri och topologi. Inga andra egenskaper finns knutna till objekten.

NPO0neVo

Figur 19 a) Icke planär graf. Två vägar korsar en flod.

ivå 1 å nivå 1 skapas objekt och samlas bjektens geometriska parametrar r medan andra attributdata läggs tilloder från nivå 0 som formar ett fullement (eng: road element) respektägelementen ges attribut som hastbjekt på nivå 1 kan referera ett och

b) Planär graf på samma situation som i a).

i klasser som skapar ett samordnat system. efereras till de primitiva elementen på nivå på denna nivå. Så kan t.ex. kanter och lt topologiskt vägnät refereras av väg-ive korsningar (eng: junctions) på nivå 1. ighet, vägklass m.m. Observera att flera samma element på nivå 0.

41

Nivå 2 På nivå 2 sätts mer komplexa klasser samman som byggs upp av ett antal objekt från nivå 1. Så sätts t.ex. ett land samman av flera regioner.

Nivåerna 1 och 2 är icke-planära modeller av verkligheten som bygger på den planära modellen på nivå 0. I MultiNet:s shapeformat är inte nivå 0 direkt tillgänglig utan finns integrerad i strukturen. Hela modellen med abstraktions-nivåer visas i figur 20.

4TtNd

Esäu(f(

Figur 20 Tre abstraktionsnivåer i Tele Atlas databas.

.2.3 Konceptuell datamodell ele Atlas bygger sin databas med en konceptuell datamodell som följer de

idigare beskrivna abstraktionsnivåerna. Den beskrivs med hjälp av IAM-diagram (Nijssens Information Analyses Method). En snabbguide till enna modelleringsteknik finns i bilaga B.

Beskrivningen som ges nedan hänvisar till figur 21 som är en bild hämtad ur Tele Atlas dokumentation. Detta gör att engelska benämningar används i bilden medan motsvarande svenska används i texten. För att undvika tveksamheter skrivs även motsvarande engelska uttryck ut i den förklarande texten. Alla fackuttryck är inte direkt översättbara. I sådana fall har då val av översättning gjorts utifrån ordets praktiska betydelse.

n objektorienterad modell sätter geoobjektet (eng: feature) i centrum. I detta ammanhang ser vi ett objekt som en modell av en företeelse i vår värld som r knuten till en geografisk plats på jorden. Ett objekt är alltid kopplat till ett nikt objekttema (eng: feature theme) och är antingen ett komplext sammansatt) objekt (eng: complex feature) eller ett enkelt objekt (eng: simple eature). Komplexa objekt i sin tur kan antingen vara sammansatta aggregerade) av komplexa objekt eller enkla objekt.

42

Enkla objekt kan vara av typen punkt-, linje- eller areaobjekt som i sin tur är definierade med hjälp av de grundläggande geometriska elementen som här har benämningarna nod, kant respektive yta (eng: face). Dessa geometriska grundelement bär på den underliggande geometriska och topologiska informationen. Ur detta kan man se att linjer byggs upp med hjälp av en eller flera kanter liksom att en area byggs upp av en eller flera ytor.

Objekten har sina tillhörigheter i de tidigare angivna abstraktionsnivåerna. Komplexa objekt hör till nivå 2, enkla objekt hör till nivå 1 och de grund-läggande geometriska elementen hör till nivå 0. Observera att på nivå 0 representeras verkligheten i form av en planär graf i två dimensioner.

Figur 21 Konceptuell datamodell för Tele Atlas Multinet.

43

Nätverksgeometri Byggstenarna för att modellera vägnätverket är kanter och noder. Dessa objekt ligger på nivå 0 och refereras av vägelement respektive korsningar på nivå 1.

Observera att mellan objekten på nivå 0 respektive nivå 1 råder ett 1:n-förhållande. Detta betyder att objekt på nivå 0 kan refereras av 0, 1 eller flera objekt. Exempel på detta visas i figur 22.

4Si

D

Figur 22 Exempel på förhållandet mellan objekt på nivå 1 och nivå 0. Vägelement 1 refererar till kant 1 och 2 på nivå 0. Korsning 1 och 2 refererar till nod 1och 3. Nod 2 refereras inte alls av något objekt på nivå 1. Detta kan uppstå om en nod ligger mellan två kanter mellan vilka ingen förändring i attributdata sker.

.2.4 Shapeformatet hapeformatet strukturerar vägdatabasen i ett antal datalager som i sin tur är

ndelade i tretton tematiska enheter. Varje enhet innehåller:

minst ett geometriskt datalager innehållande geometriska objekt och deras viktigaste attribut

eventuellt ytterligare attributtabeller relaterade till de geometriska objekten

utökade attributtabeller med extrainformation och/eller information som tillkommit efter produktens publicering.

relationstabeller - för relationer mellan geografiska objekt

indexeringstabeller som nyttjas till aggregering av komplexa objekt.

e tematiska enheterna är:

vägar, färjelinjer och gränser för adressområde. (Roads, Ferries and Address Areas Boundaries)

gator (Streets)

järnvägar (Railways)

points of Interest, POI - någon bra svensk översättning har ej hittats

centrumpunkt för bosättning (Center of settlements)

vattenytor och vattenlinjer (Water Areas and Water Center Lines)

markanvändning (Land Use & Land Cover)

44

samhällen (Built-Up Areas)

administrativa områden (Administrative Areas)

administrativa platser (Administrative Places)

postnummerområden (Postal Districts)

övriga namngivna områden (Other named areas)

strukturer (broar, tunnlar mm) (Structures).

Den intressanta enheten i detta sammanhang är enheten vägar, färjelinjer och gränser för adressområden. Övriga enheter har i detta arbete använts mest i presentationssyfte.

4.2.5 Vägar, färjelinjer och gränser för adressområden Enheten vägar, färjelinjer och gränser för adressareor innehåller ett antal geometriska datalager och andra attributtabeller. I nätverksdatalagret (filnamn: *_nw) finns det som är relevant vid ruttplanering och fordonsnavigering. Datalagret ger en bild av vägnätverket i ett valt område. Förutom vägar finns här även färjelinjer samt även gränser för adressområden. Tele Atlas använder sig av benämningen transportelement (eng: transportation element) som ett samlingsnamn för väg- och färjelinjeelement.

En färjelinje finns upptagen i databasen om den är reguljär och kompletterar ett vägnätverk, dvs det finns inte en vägsträcka som uppfyller samma transportfunktion. Ett adressområde används som referensobjekt av adresser då adresseringen efter en väg inte görs med hjälp av vägnamn.

I nätverksdatalagret finns geometrin med fullständig topologi och ett antal attribut. En del attribut är mer betydelsefulla för ruttplaneringsändamål än andra. I tabell 4 ges en kort beskrivning av de mest relevanta attributen. För en mer fullständig lista på attribut i detta datalager se bilaga C.

45

Tabell 4 De mest betydelsefulla attributen i nätverksdatalagret.

Fältnamn Beskrivning Datatyp (max tecken)

Värden

NAME Officiellt gatunamn String (70)

NET2CLASS Se 4.2.6 Number(2) Se 4.2.6

ONEWAY Anger flödesriktning String (2) Blank: öppen i båda riktningar FT: Öppen i från-till-riktning N: Stängd i bägge riktningar TF: Öppen i till-från-riktning

PRIVATERD Anger om vägen är stängd för allmän trafik

String (1) 0: Inga restriktioner 2: Ej tillgänglig för allmänheten

F_BP Blockerad passage vid från-korsning

String (1) 0: Ej blockerad 1: Blockerad passage vid från-korsning

T_BP Blockerad passage vid till-korsning

String (1) 0: Ej blockerad 2: Blockerad passage vid till-korsning

KPH Beräknad medelhastighet (km/h)

Number (3)

MINUTES Restid (minuter) Number (7)*

*Lagras som heltal men representerar decimaltal med 4 decimaler.

4.2.6 Vägklasser Ett av de viktigare och mest signifikanta attributen för vägelement är indelning i vägklasser (klassificering). Denna indelning gäller även färjelinjer dvs för alla transportelement. I Tele Atlas används tre olika typer av vägklasser där en av klasserna i sig dessutom finns i tre olika former vilket ger sammanlagt fem stycken skilda klassificeringar. Utifrån dokumentationen kan det vara svårt att inse skillnaden i betydelse och användningsområde för respektive klass. Skillnader i klassificeringarna finns förutom i antal klasser framför allt i bedömningskriterierna för indelningen baserat på vägarnas betydelse.

FRC (Functional Road Class) Klassificering av transportelement som är baserad på dess funktionella betydelse inom transportnätverket. Anges med värden från 0 till 8 där 0 är motorväg med internationell anslutning och 8 ej vägar för motortrafik.

46

FOW (Form Of Way) Anger elementets fysiska utformning och/eller dess trafikegenskaper. Exempel på vad som kan framgå av detta attribut är om ett vägelement är en motorväg, en väg med flera eller endast en körbana, på- eller avfart till motorväg osv.

Network Class Klassificering av transportelement som grundar sig på att forma slutna fungerande nätverk i en hierarkisk struktur. Skillnaden kan tyckas vara hårfin från FRC men skillnaden ligger i att Network Class kan ge små till synes obetydliga vägar högre status för att få ett väl fungerande transportnätverk (se figur 23). Network Class är enligt Tele Atlas optimerad för fordonsnavigering.

Network Class finns i tre varianter med olika detaljrikedom:

NetClass: 4 klasser, från 1 (högsta) till 4 (lägsta) (Tidigare Net1Class).

NetBClass: 6 klasser, från 1 (högsta) till 6 (lägsta).

Net2Class: 7 klasser, från 0 (högsta) till 6 (lägsta).

4REpst

4Tg

Figur 23 Exempel på där Net Class – klassificering omprioriterar en vägs klassificering beroende på dess betydelse i ett transportnätverk. Vägen ”över bergen” ges låg status i FRC men högre i Net1Class eftersom man genom att använda denna väg vid förflyttning från A till B kommer att tjäna tid.

.2.7 Svängar estriktioner och andra egenskaper för svängar lagras i tabellen Maneuvers. n sväng är någon av typerna påbjuden (eng: mandatory), föredragen (eng: referred) eller förbjuden (eng: prohibited) följd av transportelement. En väng innehåller referenser till de ingående transportelementen och ypangivelse.

.2.8 Geokodning ele Atlas MultiNet innehåller information för geokodning. Datalagret för eokodning (filnamn: *_gc) är konstruerat speciellt för detta ändamål. Enligt

47

Tele Atlas ska detta lager innehålla alla geometrier och attributdata som krävs för geokodning.

Förutom geokodningslagret finns även en tabell för mellanliggande hus-nummer (eng: Intermediate House Numbers) som beskriver ordningen på husnummer efter vägelement där en ologisk ordning av numren förekommer. För detta projekt relevanta attribut i geokodningslagret samt fält i tabellen för mellanliggande husnummer finns specificerade i bilaga D.

48

5 Ruttberäkningar med ArcGIS 9 Network Analyst och Tele Atlas MultiNet

Kapitlet tar upp ett praktiskt exempel på användning av ruttberäknings-funktionerna i ArcGIS 9.1 Beta, Network Analyst. Inledningsvis beskrivs bakgrunden till det praktiska fallet, här kallat fallet Falköping. Därefter följer en beskrivning över arbetsgång med moment som användes då beräkningarna genomfördes. Ett visst mått av automatisering av handhavandet prövades vilket beskrivs i texten. Problem som uppstod under arbetets gång tas också upp.

Avslutningsvis beskrivs den kvalitetskontroll av ruttberäkningarna som gjordes i samband med fallet Falköping.

Begrepp och uttryck som beskrivs i kapitel 3 och 4 används i detta kapitel.

5.1 Bakgrund Falköping kommun vill undersöka om effektivisering av förnödenhets-transporter till och inom kommunen är möjligt att uppnå med hjälp av en sam-ordningscentral. I det här fallet menas effektivisering avseende:

fordonskilometer

tid

miljöutsläpp

trafiksäkerhet.

Förnödenhetstransporterna avser transporter av i huvudsak livsmedel, från leverantörer till kommunala enheter i Falköping kommun. Idag sker transporterna i form av direktleveranser från leverantör till kommunal enhet. De kommunala enheterna är 45 stycken till antalet. De består av skolor, förskolor, äldreboende m.m. uppdelade på produktionskök, mottagningskök och kafeterior. Leverantörerna är 17 stycken och finns placerade såväl inom som utanför kommunens gränser. Den geografiska placeringen av leverantörer i beräkningsmodellerna avser godsets ursprung vid utleverans till kommunal enhet. Detta kan vara produktionsplats eller lager.

I ett tänkt framtidsscenario kör leverantörerna varorna till en gemensam sam-ordningscentral. Från denna central körs sedan varorna ut till de kommunala enheterna i förutbestämda rutter. Schematiska bilder av godsflödet i de två fallen visas i figur 24. Observera att godsflödet inte är detsamma som de faktiska eller planerade rutterna. En modell som beskriver dagens geografiska transportlänkar liksom en modell som beskriver framtida möjliga geografiska transportlänkar är mycket mer komplex. För mer information om modelleringen av dessa hänvisas till Guy (2005).

49

GIS-verktyget användes i första hand till beräkningar av antal kilometer och tid för transporterna i respektive scenario. Följande allmänna modell av rutter i det geografiska transportnätverket användes vid konfigurering och användningen av GIS-verktyget:

Is

G

5Abddfaa

Figur 25 Schematisk bild över rutter i transportnätet. Observera att i före- och efterscenariot används samma beräkningsmodell med skillnaden av start- och slutpunktens betydelse i respektive fall.

Figur 24 Beskrivning av godsflödet i Falköping kommuns förnödenhetstransportsystem i ett före-respektive efterscenario av användning av samordningscentral.

förescenariot är start- och slutpunkt leverantören. I efterscenariot är start- och lutpunkt samordningscentralen.

IS-verktyget användes även till produktion av presentationsmaterial.

.2 Arbetsflöde rbetet med NA innefattade en mängd moment innan de faktiska rutt-eräkningarna kunde utföras. Arbetsflöde med moment är visat i figur 26 men en logiska följden av arbetsmomenten är förenklad. I många avseenden var et en itererande process. Arbetsmomenten kan delas in i två delar där den örsta delen bestod av konstruktion av plattform för nätverksanalys och den ndra det faktiska användandet av plattformen i form av ruttberäkningar och nalys.

50

Ddifs

5Vfsgnk

Tgr

GIeeptG(gupDlaaäb

Figur 26 Arbetsgången i det praktiska arbetet.

et ska redan nu nämnas att i en organisation som vill använda sig av NA för enna typ av applikation behöver inte all kunskap och allt detta arbete utföras nom organisationens egna väggar. Den plattform för nätverksanalys som de örsta momenten resulterar i kan mycket väl tänkas levereras av någon utom-tående konsult. Mer om detta i utvärderingen i kapitel 8.

.3 Partitionering och konfigurering av vägdatabas ägdatabasen, i vårt fall Tele Atlas, levereras vanligtvis i av kunden beställt

ormat, geografiskt område och referenssystem. Formatet var i det här fallet hapeformatet eftersom arbetet inte innefattade en Oracledatabas. Vad det äller den geografiska täckningen tillhandahölls ett större område än ödvändigt. Dessutom var referenssystemet givet till WGS84. En del förarbete rävdes därför.

re parametrar är värda att beakta vid val/konfigurering av vägdatabasen: det eografiska områdets storlek, detaljrikedomen i transportnätverket och eferenssystem.

eografiskt område detta projekt var valet av geografiskt område inte från början helt givet varför n del olika utsnitt testades. Från början byggdes nätverket på ett utsnitt av nbart Falköping kommun. När sedan en del leverantörer hade sin utgångs-unkt utanför kommunen utvidgades det geografiska området i två omgångar ill att till sist täcka ett område som i stort sett inramas av linjer dragna mellan öteborg – Vänersborg – Lidköping – Skövde – Jönköping – åter Göteborg

se bilaga I). Den av NA hanterade datamängden ökade markant med den eografiska utvidgningen. Antalet transportelement som ingick i respektive tsnitt ökade från 8 579 till 176 387. Denna ökning av datamängd gjorde sig åmind i form av längre svarstider vid utritning och datalagerhantering. äremot blev tiderna för utförande av ruttberäkningar i NA inte nämnvärt

ängre. Anledningen till detta är antagligen att eftersom heuristiska metoder nvänds i t.ex. TSP bidrar inte ett utökat geografiskt område nödvändigtvis till tt (så många) fler fall av vägval måste undersökas. Algoritmen begränsar sig ndå till det geografiska område som är intressant för rutten. Svarstider för eräkningar av rutter påverkas i större grad av antalet stopp och den

51

geografiska utbredningen av själva rutten. Det valda geografiska området kommer fortsättningsvis att benämnas ”vald region”.

Detaljrikedom Förutom val av geografiskt område bör val av detaljrikedom av transport-nätverk (vägnätverk) göras. Med detaljrikedom avses här hur många och hur små vägar som ska beaktas i ruttberäkningarna. Val av vägar baseras på någon vägklassindelning som speglar deras storlek och betydelse i ett transport-nätverk. Vid full detaljrikedom beskrivs de ”minsta” vägarna i NET2CLASS som ”alla vägelement och färjelinjer representerande lokala vägar tillgängliga för trafik men av mindre betydelse” (MultiNet3.3_Data_Specs_v1.0.pdf). Om inte någon hänsyn behöver tas till dessa vägar och/eller andra vägklasser bör man skala ner vägdatabasen genom att välja ut enbart de relevanta väg-klasserna. Som exempel kan nämnas att en selektion av vägar tillhörande klass 0, 1, 2 och 3 i NET2CLASS (europa-, riks-, länsvägar och viktigare lokala vägar) ger en minskning av antalet transportelement i storleksordningen 80–90 %. Detta ger ändå en detaljrikedom som mycket väl kan räcka att användas för ruttberäkningar över stora avstånd och där den absoluta nog-grannheten inte krävs. I gengäld kommer svarstider för verktygets beräknings-arbete att kortas liksom tider för kartuppritning i ArcMap.

I den vägdatabas som användes för Falköpingprojektet nyttjades Tele Atlas MultiNet med dess fulla detaljrikedom. Detta dels p.g.a. att en betydande andel av stoppen befinner sig på landsbygd och utefter små byvägar dels för att det var av intresse att verkligen testa databasens kapacitet vad gäller detalj-rikedom. Några större problem i prestanda märktes för den delen inte. Möjligtvis att uppritningen av kartan i ArcMap upplevdes ta för lång tid för att kännas användarvänlig.

Referenssystem I det här fallet fanns tillgång till vägdatabasen i referenssystemet WGS84 medan Falköping kommuns önskemål var att arbeta i RT 90 2,5 gon väst. Koordinattransformationen löstes med hjälp av verktyget ”Project” i ArcMap (eller ArcCatalog). För att rationalisera arbetet med koordinattransformeringen byggdes en modell med hjälp av Modelbuilder (se avsnitt 6.3) som underlättade indata- och utdatahantering av datalager samt val av geografisk transformation.

Följande shapefiler användes från vägdatabasen:

swesw2________nw.shp (transportnätverk)

swesw2________rr.shp (järnvägar)

swesw2________a8.shp (kommungränser)

swesw2________bu.shp (samhällen)

swesw2________lu.shp (markanvändning)

swesw2________wa.shp (vattendrag)

Den förstnämnda filen (transportnätverk) är den som innehåller det kompletta transportnätverket med alla i Tele Atlas Multinet ingående attribut. Övriga filer användes som bakgrundskartor i presentationssammanhang. Utsnitt av

52

geografiskt område och koordinattransformation resulterade i motsvarande antal anpassade shapefiler.

5.4 Skapande av geodatabas Det är möjligt att arbeta med nätverksanalys i NA i shapeformatet. Begränsningen ligger då i att antalet geoobjektkällor är begränsat till endast en linjeobjektkälla (= en shapefil) plus eventuell svängobjektkälla. Det visade sig att detta hade varit tillräckligt för Falköpingprojektet men i ett tidigt skede togs beslut om att istället arbeta i en geodatabas. Detta av tre anledningar:

1. Önskad flexibilitet att vid behov kunna utvidga nätverket med fler geoobjektkällor.

2. Intresse av att undersöka möjligheter, användarvänlighet mm i ESRI:s koncept med geodatabasen.

3. Förväntad smidighet i hanterande av endast en fil (mdb-fil) vid flytt av databasen mellan arbetsstationer.

Geodatabasen blev skapad på ett enanvändarsystem som använder sig av Microsofts JetEngine (Access) som DBMS. Geodatabasens struktur på detta system är direkt överförbar till ett DBMS som ArcSDE arbetar mot.

5.4.1 Design av geodatabas När vi här talar om design av geodatabas ska det nämnas att det inte behöver handla om databasdesign på tabellstrukturnivå i form av konceptuell, logisk och fysisk design. Huvuddelen av de indata som geodatabasen ska hantera levereras i för tillämpningen anpassat format i form av shapefiler och är redan strukturerat. Det designarbetet då handlar om är strukturering av geoobjekt-klasser.

För fallet Falköping byggdes en geodatabas bestående av två geodataset. Ett geodataset skapades med syftet att innehålla det nätverk som ruttbe-räkningarna skulle utföras på. Ett nätverksdataset måste ligga i ett geodataset i en geodatabas. Ett andra geodataset skapades med syftet att lagra geoobjekt-klasser för bakgrundskartor för presentation och igenkännande.

De geoobjektklasser som lagras i ett geodataset har alla samma referenssystem och samma syfte. Figur 27 visar den skapade geodatabasen för fallet Falköping. Med i bilden finns dessutom geoobjektklassen turns som beskrivs närmare i avsnitt 5.4.3.

53

Figur 27 Vy över geodatabasen som skapades för fallet Falköping. Skärmdump från ArcGIS 9.1 Network Analyst.

Geoobjektklasserna skapades genom import av shapefilerna genererade från konfigureringen av Tele Atlas Multinet. Shapefilernas motsvarighet till geo-objektklasserna framgår av figur 28.

5Vpbgh

Nm

YA

V1

Figur 28 De ingående shapefilerna från vägdatabasen och deras motsvarigheter som geoobjektklasser igeodatabasen.

.4.2 Att definiera den rumsliga domänen id skapandet av geodataseten uppstod ett problem som här tas upp specifikt .g.a. dess stora betydelse vid arbete med geodatabaser och dataset. Problemet estod i frågan ”hur och när bör man definiera den rumsliga domänen för en eodatabas eller ett geodataset?”. För beskrivning av begreppet rumslig domän änvisas till avsnitt 3.4.

är man skapar ett nytt geodataset eller ny geoobjektklass i en geodatabas åste den rumsliga domänen sättas. Följande två frågor bör då beaktas:

Kommer precisionen i data (koordinatangivelser) att bibehållas när det förs in i geodatabasen?

Kommer den rumsliga domänen att täcka hela det geografiska område som ska betraktas?

tterligare frågeställningar tillkommer om man arbetar mot en geodatabas via rcSDE men dessa tas inte upp i detta arbete.

ad det gäller precisionen i data är det bara att konstatera att med precisionen 00 som ger minsta lagringsenhet 1 cm för koordinater är det möjligt att täcka

54

ett område på nästan 21 500 x 21 500 km. Som jämförelse kan nämnas att för att täcka in hela Europa exklusive Island krävs ett geografiskt område i storleksordningen 4000 x 5000 km. Det är först vid projektion av hela vårt jordklot (omkrets 40 000 km) som minsta lagringsenhet på 1 cm inte kan bibehållas. Det finns med andra ord ett rejält tilltaget utrymme i lagrings-kapacitet för normalfallet av tillämpning.

I ArcMap och ArcCatalog är det möjligt att själv beräkna och sätta den rumsliga domänen. Detta förfaringssätt är däremot varken det vanligaste eller det av ESRI rekommenderade. Den förespråkade metoden är istället att vid skapandet av en geoobjektklass eller ett dataset importera referenssystem och rumsliga domän från en datakälla som geografiskt täcker hela det relevanta området samt innehåller rätt referenssystem. Precisionen sätts då automatiskt av ArcGIS-miljön till det maximala. Så gjordes till sist i fallet Falköping dock efter flera försök att i efterhand importera referenssystem och domän vilket inte är genomförbart.

5.4.3 Användning av svängar I och med att Tele Atlas vägdatabas har tabellen Maneuvers för att specificera svängar av olika slag i ett geografiskt område (se avsnitt 4.2.7) fanns en för-hoppning om att det skulle gå att använda sig av dessa på ett enkelt sätt i NA. Problemet är att olika datamodeller för svängar används av ESRI respektive Tele Atlas vilket gör att översättning av maneuvers-tabellen till ESRI:s turn-tabell krävs. I nuläget finns inte ett sådant verktyg tillgängligt men enligt ESRI Sweden kommer ett sådant att tas fram3.

I fallet Falköping valdes de svängar som ligger inom Falköping kommun ut. Antalet är 34 stycken. Svängarna är endast av typen ”förbjuden sväng” och de är alla hämtade från situationer likt den visad i figur 29.

SNät

3

Figur 29 Den typ av förbjudna svängar i Falköping kommun som förekommer i Tele Atlas MultiNet.Skärmdump från ArcGIS 9.1 Network Analyst.

vängarna överfördes till en turn-tabell, även kallad svängobjektklass, i etwork Analyst via redigeringsgränssnittet, dvs de ritades in en efter en. Det

r ett arbete som inte är att rekommendera på en större datamängd p.g.a. den id det tar att utföra. Resultatet från arbetet blev svängobjektklassen turns.

Muntlig källa: Håkan Nordlund, ESRI Sweden 2005-04-27

55

Svängarna i turns användes sedan som (sväng-) restriktioner i ruttbe-räkningarna.

5.5 Adressmatchning Stoppen i fallet Falköping kom att bestå av följande:

Kommunala enheter till vilka dagligvaror levereras, 44 stycken.

Leverantörer från vilka dagligvarorna körs. (Adressen är utgående adress.)

En framtida tänkt samordningscentral.

Möjliga stopp var därmed klart definierade från början och förändrades inte under projektets och analysens gång. Detta medförde att det var lämpligt att adressmatcha dessa punkter i ett tidigt skede och lägga in dem som geoobjekt i geoobjektklasser i geodatabasen. På detta sätt kan man betrakta adress-matchningen av dessa som en del av konstruktionen av plattform för nätverks-analys (se figur 26). Under analysarbetet matchas sedan indata direkt mot dessa redan adressmatchade geoobjekt.

Om analysarbete skulle ha utförts på material där de ingående stoppen hela tiden bytts ut hade en mer dynamisk lösning krävts där adressmatchning skett i direkt samband med analysarbetet.

De kommunala enheterna levererades koordinatsatta av Falköping kommun. Adressmatchningen var gjord på manuell väg av kommunens personal. Leverantörerna skulle däremot adressmatchas inom ramen för detta examens-arbete. Eftersom detta arbete avser att undersöka NA:s möjligheter som verktyg för nätverksanalys allmänt gjordes ändå tester med adressmatchning av både kommunala enheterna och leverantörer med hjälp av ArcGIS. För denna procedur krävdes förutom verktyget även en adressplacering (eng: address locator) och referensdata (se avsnitt 3.5).

Adressplaceringsstil (eng: adress locator style) som är anpassad för geodata-basens objekt- och datamodell fanns vid detta arbetes utförande ej tillgängligt eftersom det är en betaversion av programvaran som använts. Detta löstes då genom att adressmatchningen fick göras utanför geodatabasen i shapeformat. För shapeformatet finns en adressplaceringsstil för svenska gatuadresser att tillgå. Med denna byggdes en fungerande adressplacering.

Som referensdata användes i ett första försök Tele Atlas MultiNet och dess shapefil för geokodning (se avsnitt 4.2.8). Andelen rätt matchade adresser, av 45 enheter, blev ca 40 %. Möjlighet till interaktiv manuell matchning finns visserligen i NA men den låga andelen rätt matchade adresser innebar ett problem. Samma träffprocent nådde även för leverantörerna.

56

Två orsaker till den låga andelen träffar hittades.

1. Det sökta gatuadressnumret fanns ej registrerat för given väg i vägdatabasen. Exempel: Inadress: Ågatan 8, postnummer: 520 50 Funna poster i vägdatabasen med rätt gatunamn och postnummer:

NAME L_LAXON L_PC L_F_ADD L_T_ADD R_F_ADD R_T_ADD Ågatan Falköping 52050 -1 -1 -1 -1 Ågatan Falköping 52050 -1 -1 -1 -1

Om matchning skulle ha uppnåtts hade det krävts att intervallet L_F_ADD till L_T_ADD eller intervallet R_F_ADD till R_T_ADD innefattat gatunumret 8 i någon post.

2. Gatunamnet fanns ej över huvud taget. Exempel: Inadress: Åsle skolan, postnummer 521 91 Åsle skolan som gatuadress fanns inte i vägdatabasen.

Allmänt kan sägas att adressmatchning med vägdatabasen som underlag var i detta fall svårt när det handlade om landsortsadresser.

Försök gjordes även att genomföra automatisk adressmatchning mot Lantmäteriets fastighetsregister. Det består bl.a. av belägenhetsadresser som är insamlade av Sveriges kommuner. Insamling pågår fortfarande och i januari 2005 angavs 287 kommuner ha adresser i detta register (Lantmäteriet). Falköping kommun anges ha ca 99 % av sina belägenhetsadresser med i detta register. Adresserna lånades för detta projekt direkt av Falköping kommun för att testas med adressmatchning i NA.

Adressmatchningen med Lantmäteriets (kommunens) eget adressregister som referensdata resulterade som förväntat i hundraprocentig matchning. Adress-angivelserna i indataadresser och referensmaterial kommer från samma källa (Falköping kommun) vilket borde innebära att adressernas namnangivelser och numreringar är de samma.

Vad det gäller adressmatchning av leverantörers adresser ligger många av dessa utanför Falköpings kommun. Detta innebar att någon möjlighet att inom projektets ramar använda sig av Lantmäteriets fastighetsregister inte fanns. Några av leverantörerna var dessutom geografiskt placerade på landsbygd och hade därmed en s.k. landsortsadress vilket resulterade i dålig andel matchade adresser. Här användes till sist interaktiv geokodning.

Efter genomförd adressmatchning importerades de möjliga stoppen till geodatabasen och lagrades i form av tre geoobjektklasser, en för vardera typen av stopp (se figur 30).

57

Figur 30 Geodatabasen efter det att de kommunala enheterna (units), leverantörer (deliverycompanies) och samordnings-central (consol_terminal) lagts in i geoobjektklasser. Geoobjekten i dessa klasser representerar alla möjliga stopp. Skärmdump från ArcGIS 9.1 Network Analyst.

5.6 Konfigurering av nätverksdataset Att bygga och konfigurera ett nätverksdataset är något som man som användare av verktyget inte ska behöva göra så ofta. När väl ett nätverk är byggt ska inte detta behöva göras på nytt såvida inte förändring sker i nät-verkets geoobjektkällor eller konfigurationsparametrar. Nätverksdatasetet ligger i applikationen som en grund för analysarbete.

Här följer nu en framställning av de parametrar som sattes i samband med konfiguration och bygge av det nätverksdataset som användes i fallet Falköping. Framställningen bygger på beskrivningen av ett nätverksdataset och dess beståndsdelar som finns i avsnitt 3.7.

Geoobjektkällor De geoobjektkällor som användes till nätverksdatasetet var:

Geoobjektklassen roads innehållandes transportelement (vägar alt. länkar) för den valda regionen.

Svängobjektklassen turns med förbjudna svängar.

Anslutning Anslutning kunde genomföras på enklaste sätt. Geoobjektklassen, roads, som innehåller transportelementen (länkarna) importerades från Tele Atlas väg-databas och dess nätverksdatalager. Denna objektklass är därmed en icke-planär nätverksmodell och dess länkar ansluts därför endast i länkarnas start- och slutnoder. Geoobjektkällan turns används inte i detta sammanhang.

Nätverksattribut Nätverksattributen som skapades valdes utifrån vad som fanns att tillgå i Tele Atlas vägdatabas och då framförallt dess nätverksdatalager. Attributtabellen för nätverksdatalagret finns angiven i bilaga C. Följande nätverksattribut skapades:

58

Meters Ett nätverksattribut av typen kostnad för användning som impedans vid rutt-beräkningar. Hämtar värdet från fältet METERS i vägdatabasen och anger länkens längd i meter. Använder fältevaluerare.

Minutes Ett nätverksattribut av typen kostnad för användning som impedans vid rutt-beräkningar. Hämtar värdet från fältet MINUTES i vägdatabasen och anger enligt Tele Atlas en ”realistisk restid” (MultiNet_UserGuide_Shapefile_v1.41.pdf) att transportera sig över länken. Använder fältevaluerare.

Oneway Ett nätverksattribut av typen restriktion som används för att modellera enkel-riktade vägar. Attributet anger om förflyttning över en länk endast kan göras i en riktning. Attributets värde baseras på fältet ONEWAY i vägdatabasen och ges som ett booleskt värde som anger om förflyttning i given riktning är för-bjuden eller ej. Använder VB-scriptevaluerare.

Exempel: Om en länk ej får traverseras i riktningen startnod till slutnod ger en förfrågan på förflyttning i denna riktning värdet true. Används för att modellera enkelriktade vägar.

Private roads Nätverksattribut av typen restriktion som anger om en länk/väg är öppen för allmän trafik eller ej. Baseras på värdet i fältet PRIVATERD i vägdatabasen. Använder VB-scriptevaluerare.

Blocked passages Nätverksattribut av typen restriktion som anger om framkomlighet är möjlig vid en länks/vägs startnod och/eller slutnod. Attributets värde baseras på fälten F_BP och T_BP i vägdatabasen. Använder VB-scriptevaluerare.

Prohibited maneuvers Nätverksattribut av typen restriktion som anger svängar som är förbjudna att genomföra. Attributets värde baseras på fältet WEIGHT i svängobjektklassen turns. Om värdet är -1 betyder detta att svängen är förbjuden att genomföra. Använder VB-scriptevaluerare.

Roadhierarchy Nätverksattribut av typen hierarki. Bygger på fältet NET2CLASS i vägdata-basen. (Se bilaga C)

När väl alla ovanstående parametrar var satta skapades och byggdes nätverks-datasetet. På den arbetsstation arbetet utfördes (se bilaga E) och den data-mängd som fallet krävde tog detta mindre än en minut.

59

5.7 Beräkningar och analys Med nätverksdataset och geodatabas som grund var verktyget färdigt för att utföra beräkningar och analys. Plattformen för nätverksanalys var i och med detta konstruerad.

I fallet Falköping skulle ruttberäkningar genomföras på två fall: ett före och ett efter utplacering av samordningscentral. Det ska påpekas att i denna rapport redovisas en förenklad bild av transportmodell och beräkningar utförda i fallet Falköping. Den bild som ges här är avgränsad till det som krävdes för nät-verksanalysen i GIS-verktyget. För en mer utförlig bild av transportmodell och problematik kring detta hänvisas till examensarbetet Datorstödd transportresursplanering – En GIS-studie som utförts av Guy, 2005 inom ramen av huvudprojektet.

Eftersom de två fallen baseras på samma modell (se figur 25) var indata det enda som skiljde dem åt. I före-fallet bestod indata av:

ett urval av kommunala enheter som besöks i en rutt med attribut kopplade till dessa

en given leverantör som agerar start- och slutpunkt för rutten.

I efter-fallet byttes leverantör ut mot en tänkt samordningscentral (se figur 31).

U

5AFoUav 4

5

Figur 31 Plattformen för nätverksanalys med indata och resulterande utdata.

tdata bestod i bägge fallen av en rutt med att antal egenskaper.

.7.1 Arbetsmiljö ll bearbetning och analys av data utanför GIS-verktyget utfördes i fallet alköping i Microsoft Excel. Därför fanns ett behov av export och import till ch från excelfiler. Som läget är idag finns inte denna möjlighet i ArcGIS 9.1. ppkoppling går att ordna mot en befintlig excelfil via en OLE DB4-

nslutning och ODBC5. Denna uppkoppling ger dock endast läsrättigheter och ar i detta sammanhang inte att betrakta som ett alternativ. All export och

COM-baserade interface för nätverks- och Internetåtkomst av datakällor. Open Database Connectivity, drivrutiner för anslutning till databaser.

60

import gjordes därför via tabseparerad textfil, ett format som både ArcGIS och Excel hanterar.

Till ESRI:s ArcView 3.x finns script, skrivna av utvecklare och användare, som löser läsning och skrivning av excelfiler. Något enstaka script finns även för ArcGIS 9.0 men dessa fungerade inte på version 9.1. I en anpassad miljö för ruttberäkningar byggd på Network Analyst bör inte detta vara något större problem eftersom tid och kraft då kan läggas på implementering av sådana funktioner.

Inför analys- och beräkningsarbetet skapades en kartfil som fungerar som mall för ruttberäkningar i fallet Falköping. Denna mall innehåller referenser till geoobjekt och nätverksdataset som behövs för nätverksanalys. Även för-beredelser till presentation av resultat har gjorts i denna mall, genom att datalager för bakgrundskartor är inlagda och symbologi formaterad. Möjlig-heten att arbeta med en mall på det viset uppskattades stort.

5.7.2 Arbetsgång Varje ruttberäkning följde samma mönster och sekvens oberoende av vilket fall som betraktades. Arbetsgången kan beskrivas på följande sätt:

1. Inläsning av indatafil som innehåller ett antal kommunala enheter med attributdata. Dessa är ej geokodade.

2. Matchning av enheterna i indatafilen mot de geokodade enheterna i geoobjektklassen units.

3. Skapande av nytt analyslager för ruttberäkning med parametrar satta.

4. Inläsning av de matchade kommunala enheterna till analyslagret i form av stopp. Även inläsning av vald leverantör eller samordningscentral som start- och slutpunkt.

5. Ruttberäkning utförs enligt de satta parametrarna.

6. Export av den resulterande rutten.

Indatafilen Varje indatafil innehöll i före-fallet ett antal poster (rader) där varje post mot-svarade en kommunal enhet som ingick i en specifik leverantörs rutt (-er). Varje indatafil styrde därmed vilken leverantör som rutten (-erna) skulle gälla. I efter-fallet innehöll indatafilen alla kommunala enheter med leveranser från samlastningscentralen. De kommunala enheterna identifierades med ett användardefinierat id-nummer.

Matchning av enheter Matchningen av de kommunala enheterna i punkt 2 utgörs av en join av geo-objektklassen units och indatafilen. Joinen gjordes på id-nummer. Resultatet efter detta moment blev alltså att varje kommunal enhet i indatafilen matchats mot dess motsvarande geografiska objekt i databasen.

Parametrar för analyslager Analyslagrets parametrar i punkt 3 sattes till följande:

61

Val av impedans: Minuter. Ruttberäkningarna gjordes med optimering avseende tid. I transportsystemet ansågs tidsfaktorn vara den avgörande faktorn för ett effektivt nyttjande.

Tidsfönster: Hänsyn taget till tidsfönster eller ej varierade beroende på vilket målet var med beräkningarna.

Omordning: Omordning eller ej av stoppen varierade även det beroende på syftet med ruttberäkningen. Oftast användes omordning för att få fram den enligt verktyget effektivaste ordningen på stoppen.

Hierarki: Hierarki användes i beräkningarna. Rutterna påverkades i mycket liten grad av denna parameter.

Restriktioner: Alla befintliga restriktioner i nätverksdatasetet användes (se avsnitt 5.6).

Inläsning av stopp Inläsningen av stoppen i punkt 4 fungerade väl. Sökområdet sattes till 150 meter för att alla stopp skulle anslutas. I samband med anslutningen av stoppen upptäcktes en källa till fel. De koordinater som användes för de kommunala enheterna är en slags mittpunkt/tyngdpunkt av fastigheterna satta manuellt av personal på Falköping kommun. När anslutningspunkt för stoppet till nätverket ska beräknas görs det så att närmaste punkt belägen på en länk i nätverket blir anslutningspunkt. Självklart behöver inte detta vara den faktiska infarten till fastigheten men i vissa fall blir anslutningspunkten på fel sida om ett helt kvarter (se figur 32). I fallet Falköping har inte den här felkälla någon praktisk betydelse då en stor del av övriga indata ändå inte är i närheten av denna grad av noggrannhet. Däremot kan denna typ av fel påverka en applikation för fordonsnavigering negativt då anvisning till fastighet görs på fel sida om ett kvarter.

Figur 32 Vy som visar hur en beräknad anslutnings-punkt för en fastighet kan bli fel i förhållande till den verkliga anslutningspunkten (faktisk infart). Skärmdump från ArcGIS 9.1 Network Analyst.

Resultat och utdata Det som var intressant som utdata i samband med fallet Falköping var framför allt avverkad distans och restid för respektive rutt. Valet gjordes ändå att exportera större delen av attributtabellen för stoppen. Med i denna tabell fanns en mängd information som vid senare tillfälle kan användas för analys och ytterligare bearbetning. Ett exempel på utdatafil visas i bilaga J. Utdatafilen

62

från ruttberäkningen bearbetades sedan i Excel. Avverkad distans och restid hämtades från sista posten (raden) i fälten (kolumnerna) Cumul_Minutes respektive Cumul_Meters.

5.8 Kvalitetskontroll av resultat En kvalitetskontroll av resultat måste alltid förhålla sig till kvaliteten på in-data. Fel i indata ger än större fel i utdata. Även noggrannhet och detalj-rikedom i indata speglar sig i utdata. Den kvalitetskontroll som utfördes var dock av absolut enklaste art. Varken tid eller andra resurser till mer detaljerad kvalitetskontroll fanns inte inom ramen för detta arbete.

5.8.1 Tid, distans och vägnät Intresset fokuserades på att kvalitetsbedöma avstånds- och tidsangivelser för rutter framräknade av Network Analyst med vägdatabasen Tele Atlas MultiNet som indata. Fel i resultatet är därmed beroende av dels vägdata-basens korrekthet i informationen dels verktygets korrekthet i beräkningarna.

Två rutter beräknades med hjälp den plattform som användes under arbetets gång. Den ena rutten, kallad landsvägsrutten, inleddes inne i Falköping tätort men begav sig snart ut till kommunala enheter belägna i Odensberg, Kinnarp och Vartofta innan den avslutades med ytterligare några besök inne i Fal-köping tätort. Sammanlagt nio enheter inklusive start- och stoppunkt ingick i turen. Den andra rutten, kallad cityrutten, var en rutt begränsad till Falköping tätort med fjorton besökta enheter.

Rutterna kördes sedan och loggades med tider och distanser. Fordonet som användes vid detta tillfälle var en personbil. Tidpunkten var vald till kl. 12.00–16.00 en vardag (2005-04-21).

Vad det gäller distansen visades en relativ avvikelse på ca 1 % mellan uppmätt värde och beräknat värde för landsvägsrutten medan cityrutten uppvisade en betydligt större avvikelse på drygt 5 % där den uppmätta distansen var den kortare. Någon förklaring till den större avvikelsen i cityrutten är svår att finna.

Tiderna för rutterna visade motsatt avvikelsemönster. Relativ avvikelse på landsvägsturen var 20 % och för cityturen 5 %. Båda rutterna genomfördes snabbare än beräknat. Då ska framhållas att hastigheten som hölls låg strax under tillåten hastighet och att trafikmängden vid testtillfället var mycket låg.

Tiderna i beräkningarna bygger på de tidsangivelser som anges för varje länk i vägdatabasen, i vårt fall Tele Atlas. För varje länk i nätverksdatalagret anges den tid i minuter det tar att traversera länken samt en ”beräknad medelhastig-het”. På vilket sätt Tele Atlas tar fram den beräknade medelhastigheten har inte gått att få någon riktig klarhet i. Enligt Tele Atlas själva har de lokala datainsamlare som kontinuerligt åker runt på vägarna och samlar in information om vägnätet. Den svenske återförsäljaren menar att Tele Atlas har 4–5 datainsamlare i Sverige som kontinuerligt samlar in information om det svenska vägnätet. Vad den insamlade information består av mer exakt framgår inte. En tanke är att i man i samband med detta gör någon slags uppskattning av möjlig medelhastighet.

63

En kontroll av de angivna medelhastigheterna på länkar i vägdatabasen visar att sammanlagt tretton klasser av medelhastigheter används. Anmärkningsvärt är att den högsta medelhastigheten som finns angiven är 120 km/h! Någon koppling mellan medelhastighet och vägklass för respektive länk hittades inte.

Avslutningsvis ska nämnas att de rutter som plattformen räknade fram kändes som möjliga och logiska. Vägval som föreslogs stämde väl överens med verkligheten förutom vid ett tillfälle då en relativt nybyggd korsning/väg ej fanns med i den föreslagna rutten.

5.8.2 Fordonsspecifika restriktioner De fordonsspecifika restriktionerna på länkarna i vägdatabasen är bristfälliga. I det geografiska området för Falköping kommun gäller alla restriktioner alla typer av motorfordon. Några restriktioner avseende fordonsvikter och höjder finns inte. Detta kan få till följd att en del rutter konstrueras som inte är genomförbara med tyngre och större fordon.

5.9 Applikationsanpassning Viss anpassning av verktyget NA gjordes i samband med detta arbete. I ArcGIS Desktop finns möjligheten att arbeta med verktyg (eng: tools). Ett verktyg är en klart definierad bearbetning av data utförd i applikationen. Utöver dessa verktyg kan man som användare konstruera egna verktyg. Till detta används ModelBuilder (se avsnitt 6.3) som är en applikation där man på grafisk väg kombinerar redan existerande verktyg till nya sådana. Dessa av användaren konstruerade verktyg, kallas för modeller (se figur 33).

Figur 33 De i fallet Falköping konstruerade modellerna. Jämför med arbetsmomenten i avsnitt 5.7.2.

Arbetsgången som beskrevs i avsnitt 5.7 fick agera flödesschema inför bygget med ModelBuilder. Tanken var från början att sätta ihop två modeller som skulle förenkla hanteringen. En bugg i programvaran (som är en betaversion) fick dock till sin följd att antalet modeller som krävdes blev fler.

Verktyg och modeller kan i detta sammanhang ses som funktioner med funktionsparametrar och resulterande utdata. I det grafiska gränssnittet där man som användare arbetar med ModelBuilder betecknas funktioner med rektanglar och indata och utdata med ovaler. I figur 34 visas en av de modeller som konstruerades i samband med fallet Falköping. Värt att tänka på är att varje rektangel i denna modell är ett mer eller mindre invecklat arbetsmoment i ArcGIS Desktop:s standardgränssnitt. Med modellen utförs alla dessa moment automatiskt. Indata till vardera funktionen kan bestämmas av konstruktören till modellen men möjlighet finns även att sätta indata som parametrar att anges vid användning av modellen.

64

ÄehS

Figur 34 Den grafiska bilden av modell nr 3 – Läs in stopp – leverantör. Rektanglar betecknar funktioner, ovaler betecknar in- och utdata. Indata märkta med P ärparametrar att sätta vid användning av modellen.

ven om en del av modellerna löser enbart en uppgift (funktion) gjordes ändå n stor vinst i användandet av modeller. En modell förenklar framförallt anteringen av indata där sökningar efter rätt datalager m.m. annars tar sin tid. nabbare hantering och minskat antal användarbaserade fel blev följden.

65

6 Applikationsutveckling i ArcGIS 9 Desktop

Detta kapitel ger en kort översikt över möjligheterna till produktutveckling inom Desktop GIS och då med hjälp av ArcGIS Desktop Developer Kit. Informationen är i hämtad från ESRI (2004).

6.1 Översikt ArcGIS-plattformen använder sig av ett objektbibliotek kallat ArcObjects. Det betyder att alla programvarukomponenter som ingår i Desktop GIS, Server GIS och Embedded GIS bygger på dessa komponenter. Till plattformen finns därför också ett mjukvaruutvecklingspaket, ett s.k. SDK (Software Developer Kit). Ett SDK innehåller utförlig dokumentation, exempelkod och objekt-diagram.

ArcGIS Desktop Developer Kit levereras tillsammans med applikationerna ArcView, ArcEditor och ArcInfo. Med detta paket kan man som utvecklare lägga till ytterligare funktioner till desktop-applikationerna, anpassa gränssnitt och bygga egna tilläggsmoduler. Paketet stödjer COM och .NET.

ArcGIS Engine Developer Kit innehåller komponenter avsedda för att bygga fristående GIS-applikationer och inbäddade system. Paketet stödjer COM, .NET, Java och C++.

ArcGIS Server Developer Kit innehåller standardiserade komponenter för GIS Web Services samt stödjer utveckling av applikationslager baserat på ArcObjects.

Utveckling och anpassning av ArcGIS Desktop (dvs ArcMap och ArcCatalog) kan göras på olika nivåer beroende på vad som ska utföras och vilken kunskapsnivå den som arbetar med utvecklingen har. Lite förenklat kan man dela upp de olika nivåerna på följande sätt:

Skräddarsy gränssnitt och val av funktioner med hjälp av verktygsfältsanpassning och användning av mallar.

Automatisering av arbetsflöden med hjälp av Modelbuilder.

Skapa makron i VBA.

Skriva komponenter och tilläggsmoduler med hjälp av något programmeringsspråk som stöder COM.

6.2 Skräddarsy gränssnitt Den enklaste typen av utveckling handlar om att skräddarsy gränssnitt och val av funktioner för en organisations behov. ArcGIS Desktop är en komplex plattform med många funktioner. Som IT-samordnare på ett företag kan man konfigurera gränssnittet till att visa endast de funktioner och verktyg som behövs på företaget eller på en viss avdelning. På det viset förenklas gränssnitt och hantering med mindre risk för användarfel. Genom att använda sig av mallar finns också möjligheten att ordna så att alla på ett företag arbetar med

66

samma geografiska data som grund, dvs man skapar en kartmall med given geografiska täckning, datalager och kartografisk symbolik.

6.3 Modelbuilder Modelbuilder är en applikation som ingår i ArcView, ArcEditor och ArcInfo. Med Modelbuilder är det möjligt att på grafisk väg skapa egna verktyg s.k. modeller för automatiserade arbetsflöden. Som byggstenar använder man de fördefinierade verktyg för geobearbetning som levereras i plattformen. Antalet verktyg skiljer sig åt beroende på typ av desktop-produkt och vilka tilläggsmoduler man har tillgång till. Verktygen ligger sorterade i ArcToolbox i ett antal verktygslådor (se figur 35).

Figur 35 Exempelvy i ArcToolbox på verktyg som levereras med plattformen. Dessa används sedan som byggstenar i Modelbuilder och kombineras till s.k. modeller. En modell används för att förenkla och effektivisera ett flöde av processer.

Modelbuilders gränssnitt består av ett fönster till vilket man med dra-och-släpp-teknik inkluderar de verktyg som ska ingå i ett arbetsflöde. Därefter går man in och bestämmer varifrån indata till respektive verktyg ska tas och/eller om dessa indata ska sättas av användaren när modellen används. Möjlighet finns även att skriva in hjälptext och beskrivning över hur och till vad modellen ska användas. Ett exempel på en modell visas i figur 36.

67

Eavmop

Ems

6AiiAsbf

Sm

IfMsd

Figur 36 Ett exempel där de två verktygen Select och Summary Statistics kombinerats ihop till en modell kallad Väglängdssummering. Modellen tar en geodataklass vagar som indata och hämtar in ett uttryck (expression) från användaren. Resultatet av verktyget Select blir ett antalvalda geoobjekt från klassen vagar. Dessa skickas sedan till verktyget Summary Statistic där summering av de valda (linje-) objektens längder görs. Resultatet presenteras i en nyskapad dBASE-tabell kallad roads_sum_length.

n färdigdefinierad modell sparas i en verktygslåda precis som ett verktyg och nropas på samma sätt (dubbelklick). I och med att modellen sparas i en erktygslåda finns sedan möjligheten för andra användare att använda sig av odellen. På det viset kan man som IT-samordnare eller GIS-ansvarig för en

rganisation på ett enkelt sätt leverera redskap för fasta arbetsflöden till övrig ersonal

n liten men värdefull detalj i det hela är att möjligheten finns att exportera en odell i form av något av skriptspråken Python, JScript eller VBScript, något

om kan utnyttjas på nästa nivå av utveckling.

.4 Att skriva makron i VBA rcMap och ArcCatalog levereras med Visual Basic for Applications (VBA)

ntegrerad. VBA erhåller en programmeringsmiljö som är enkel att sätta sig in med debuggnings-verktyg. Med VBA kan en utvecklare konstruera makron i rcGIS-miljön som innehåller egendefinierade funktioner och med eget de-

ignade gränssnitt. Man har genom VBA tillgång till ESRI:s standardobjekt-ibliotek i ArcObjects och kan därigenom dra nytta av redan definierade unktioner och objekt.

krivna makron vidarebefordras till personal på ett företag exempelvis via allar.

miljön finns många kodexempel som man som utvecklare kan använda sig av ör att lära och konstruera nya makron. Ett annat sätt är att använda sig av

odelbuilder. En konstruerad modell kan exporteras till VBScript-kod som edan kan användas som grund i VBA. På det viset har man som utvecklare ärigenom ytterligare tillgång till exempelkod.

68

Möjligheten finns även att exportera VBA-kod till ActiveX DLL projekt som sedan kan vidarebefordras till andra användare.

6.5 Att skriva komponenter och tilläggsmoduler i något COM-kompatibelt språk

Om man som utvecklare inte vill skriva sin kod i VBA och/eller vill paketera sina funktioner i COM DLL:er eller EXE–filer finns möjligheten att arbeta i en annan utvecklingsmiljö och annat språk, så länge som språket är COM-kompatibelt (t.ex. C++ och Java). På det här viset är det möjligt att skapa komponenter och tilläggsmoduler med nya funktioner anpassade för en orga-nisations egna verksamheter. All utveckling sker med ESRI:s objektbibliotek ArcObjects som grund. Enligt ESRI:s dokumentation finns det en hel del funktionalitet att nå på det här viset som man inte når från VBA-miljön.

ESRI har s.k. add-ins till andra utvecklingsmiljöer som exempelvis Visual Basic 6 som underlättar utvecklingen med hjälp av ArcObjects. Dessa add-ins hjälper till med t.ex. debuggning och skapande av kod för felhantering.

69

7 Ruttplaneringsystem på marknaden Här följer en kort beskrivning av hur marknaden ser ut i övrigt avseende ruttplanering och IT-baserade system för transportplanering. Två transportörers användning av sådana system beskrivs sedan som exempel.

7.1 Typer av transportplaneringssystem ArcGIS 9 är i första hand en bred och multifunktionell GIS-plattform. Det innebär i huvudsak att den är ett verktyg för datainsamling, bearbetning, analys och presentation av geografisk information för en mängd olika tillämpningar. Inom plattformen finns möjligheter till alltifrån analyser av jordbeskaffenhet, befolkningstäthet, trafikmängder, dagvattenflöden till militära, polisiära och medicinska applikationer etc. Av den anledningen blir det gärna så att verktyget har en bredd istället för specialanpassade funktioner med gränssnitt anpassade för ett specifikt tillämpningsområde. Kontentan är att ArcGIS inte är ett färdigt ruttplaneringsverktyg utan en GIS-plattform för utveckling. Mer om detta i diskussionen, avsnitt 8.1.

För att ge en bild av hur marknaden ser ut och hur system avsedda för transportplanering är konstruerade ges här en kort beskrivning av sådana system och deras funktioner.

De företag som koncentrerar sig på mjukvara för transportlogistik och fordonsplanering utvecklar system som allmänt kan benämnas som plattformar för transportplanering och optimering. I dessa plattformar finns sedan möjlig-het till olika delsystem eller system med olika nivåer av funktioner. Ofta urskiljs följande delsystem:

ruttplanering

flottoptimering

tracking (spårning av fordon i realtid)

fordonsnavigering.

Ett system för ruttplanering innehåller funktioner som att hitta snabbaste vägen mellan två eller flera punkter samt TSP-problemet. Andra vanliga funktioner är:

färdplaner/körinstruktioner

tidsfönster

definiering av fordon/fordonstyper med kriterier som lastkapacitet mm

möjligheter att som användare själv sätta framkomlighetsparametrar på vägnätet

beräkna rutter med hänsyn till förares arbets- och rasttider

kostnadskalkyler baserade på rutter och valda fordon

olika impedanser på vägnätet med hänsyn till olika trafikflöden (hög- och lågtrafik)

rutter som spänner över flera dygn.

70

Med flottoptimering menas hanteringen av en fordonsflotta där man vill optimera fördelningen av kundordrar på hela flottan. Resultatet av optime-ringen ger ett antal rutter med ett antal bilar som utförs på ett så effektivt sätt som möjligt. Med dessa system följer gärna funktioner som:

orderprioritering

plocklistor.

Vanligtvis finns någon form av koppling mellan dessa system och ett företags affärssystem för att på så sätt få in kundordrar i flottoptimeringssystemet.

Tracking eller fordonsspårning ger transportföretaget möjlighet till upp-följning av kundtransporter samt navigeringsstöd till förarna, allt i realtid. Genom detta finns då också möjligheten till omläggningar och uppdateringar av rutter under dess genomförande.

De ovan nämnda funktionerna som en plattform för transportplanering kan innefatta är endast tänkt som en översikt. Något specifikt verktyg kommer inte att nämnas i detta sammanhang. Vad man kan se är annars att många system utvecklas av företag vars säte är i USA. Detta gör att systemen från början är anpassade till den amerikanska marknaden. Europeiska återförsäljare till dessa system finns ofta att få tag i. Även viss del av utveckling sker i Sverige och övriga Skandinavien. Denna utveckling sker ofta med någon GIS-plattform som grund men även egenutvecklade produkter hittas på marknaden.

Systemen marknadsförs ofta som redskap lämpliga för såväl strategisk och taktisk som operativ verksamhet.

Besparingsargument Det som ”säljer” en produkt (tjänst eller programvara) är den förväntade vinst man som transportföretag kan göra tack vare produktens lösning. I samband med ruttplaneringssystem och flottoptimeringssystem nämns ett antal möjliga vinstområden i de säljande företagens produktblad. Exempel på sådana vinster är:

lägre transportkostnader

snabbare och effektivare transporter

bättre utnyttjandegrad av transportflottan

snabbare och förenklad planeringsprocess

enklare administration

bättre service för kunderna.

7.2 Exempel hämtade från transportföretag Ambitionen var från början att göra ett besök vardera hos DHL, Posten och Schenker för att få tre talande exempel på hur företag inom transportnäringen använder sig av GIS. På grund av omständigheter blev antalet bara två, DHL och Posten. Vad dessa besök gav redovisas i följande avsnitt.

71

7.2.1 DHL Ett besök hos Åsa Tobiasson på DHL i Karlstad 2005-04-11 gav följande information:

DHL startade 2001 ett projekt som gick under namnet DC (Distribution Control). DC är inte ett ruttplaneringssystem i det avseendet som tidigare behandlats i denna rapport men tas ändå upp här som en referens eftersom verktyget bygger på ESRI:s GIS-plattform. Projektet startades efter en undersökning som visade att en allt för stor del av förarnas arbetstid på morgonen togs upp av arbetsuppgifter som sortering och lastning av gods. Slutsatsen blev att det fanns goda möjligheter till effektivisering av dessa arbetsuppgifter. Det ledde i sin tur till utveckling och implementering av ett lastplaneringssystem.

DC är utvecklat av WSP och bygger på ArcMap 8.3. Det hanterar in-kommande gods och sorterar det till rätt port och därmed rätt transportfordon för utgående transport. Varje gods tilldelas dessutom en placering på transport-fordonet som baseras på vilket sekvensnummer godsets destination (stopp) har i fordonets rutt. Vid varje port finns tre sektioner som representerar gods som placeras längst in på bilen, gods som placeras på mitten respektive gods som placeras längst bak (ytterst) på bilen. När en förare idag inleder sitt arbetspass på morgonen finns redan det gods som ska med förarens bil sorterat vid aktuell port.

Godssorteringen bygger på att varje bil redan har en rutt tilldelad. Varje enskild bils rutt ges i dagsläget utifrån förarnas erfarenheter, dvs det görs ingen ruttplanering med datalogisk/matematisk hjälp. Att införa nya rutter framräknade av ett datoriserat ruttplaneringssystem är något DHL vill vara försiktiga med bl.a. med tanke på befarat motstånd bland förare som erfaren-hetsmässigt tycker sig redan idag ha den optimala rutten. Utveckling pågår dock inom DHL av ett framtida ruttplaneringssystem.

I övrigt kan om DC nämnas att adressmatchning görs i ArcMap med Tele Atlas MultiNet geokodningsdata som referensdata (uppdaterad nov. 2003). De adresser som inte matchas av verktyget kodas manuellt. En del problem med adressmatchningen har inträffat och då framför allt i Göteborgsområdet.

7.2.2 Posten Ett besök hos Kristian Hultfeldt på posten i Kungsbacka 2005-04-12 gav följande information:

Posten har arbetat med ruttplanering med hjälp av olika typer av programvaror sedan -96–97. Dagens ruttplaneringsverktyg som heter Route Planner och används sedan 2004, är levererat av danska Transvision A/S som är ett konsultföretag med egen utveckling av programvaror specialiserade för transportplanering. Transvision har en egen plattform för ruttplanering och flottoptimering som anpassas för den enskilde kundens ändamål.

Posten använder sitt ruttplaneringssystem i första hand för planering av lant-brevbärarlinjer. Planer finns även att utöka användningen av verktyget till rutt-planering av transporter mellan godsterminaler.

72

Centralt (för landet) finns en server med befintliga stoppställeplatser lagrade. En stoppställeplats är en geografisk punkt vid vilken det finns en eller flera avlämningsställen. Ett avlämningsställe är vanligtvis en postlåda med given adress. Från den centrala servern hämtas de stoppställeplatser som är intresseranta vid planering av en rutt. Första gången ruttplanering utförs på dessa stoppställeplatser är de ej koordinatsatta. Detta görs då för hand med hjälp av koordinatsättningsverktyget POLO. En förklaring till varför koordinatsättning görs för hand är antagligen att stoppställeplatser på lantbrev-bärarlinjer ofta är platser där ett antal avlämningsställen (t.ex. postlådor) samlats. Detta ger att den geografiska koordinaten för avlämning av posten ofta avviker relativt mycket från fastighetsadressens eller gatuadressens geo-grafiska koordinat.

Route Planner De koordinatsatta stoppställeplatserna används sedan som indata till verktyget Route Planner. För varje stoppställeplats anges följande:

adress

tidsfönster

geografisk placering

antal avlämningsställen (t.ex. postlådor).

I verktyget arbetar man med ett antal definierade fordon med olika kapacitet avseende max last, ruttid och antal stopp. Transporttider baseras på hastighets-profiler som sätts för respektive vägklass. Optimering sker på tid.

Restriktioner finns till viss del angivna från början i vägdatabasen. Posten upp-daterar dock själv restriktionerna kontinuerligt. Dessa uppdateringar lagras i en xml-fil och behandlas som ett eget datalager. Några av de restriktioner man har att jobba med är:

enkelriktad väg

återvändsgata

avstängd väg

u-svängförbud.

Dessutom arbetar man med extra kostnader för återvändsgator.

73

8 Diskussion och slutsatser Rapporten avslutas med en diskussion och slutsatser. Kapitlet strukturerar sig så att först behandlas GIS som stöd för transportlogistisk analys i allmän mening. Därefter följer diskussion och slutsatser om den specifika plattformen som använts i detta projekt, dvs vägdatabasen Tele Atlas och GIS-plattformen ArcGIS 9 med tillägget Network Analyst.

Avslutningsvis förs ett kort resonemang kring de två exempel på transport-företags användning av GIS som tagits upp i rapporten.

8.1 GIS som teknologi för transportlogistisk analys Hur ser då möjligheterna ut att med hjälp av geografisk informationsteknik utföra analys av transportlogistiska frågor och då framförallt avseende rutt-beräkningar?

Först kan vi konstatera att i detta arbete har en specifik plattform använts som representant för teknologin GIS och metoden geografisk informations-vetenskap. Det är ESRI:s ArcGIS 9.1 med tillägget Network Analyst. Värt att notera är att ESRI har 35 % av världsmarknaden inom GIS och företaget har med nya Network Analyst något som ses som en stark produkt av branschfolk. Det sista påståendet är en personlig reflektion efter ett antal månaders bransch-mingel. Sammantaget gör detta att min uppfattning är att ESRI:s produkter är en bra referens för GIS som teknologi.

8.1.1 Vad ett GIS tillför GIS erbjuder den som vill ha ett system för transportlogistisk analys en bred plattform med många möjligheter. Det har i rapporten nämnts att tillgänglig-hetsanalyser, serviceytor och ruttberäkningar är några av de tillämpningar ett GIS kan vara behjälpligt med. Men många av de funktioner ett GIS erbjuder i samband med transportlogistik är funktioner som tidigare utförts på annat sätt med enklare verktyg och med andra metoder. Vad nytt tillför då ett GIS? Några självklara egenskaper är noggrannhet och effektivitet. Men lika viktigt är möjligheten till bra presentationsmaterial som är en väldig styrka i ett GIS. Det måste sägas att det är anmärkningsvärt vilket starkt intryck en snygg och välstrukturerad digital kartbild ger i samband med presentationer. Utan att ringakta informationsinnehållet kan man konstatera att med ett GIS i ryggen, som ger bra lättförstådda illustrationer underlättas den viktiga presentationen oerhört.

Den kanske viktigaste egenskapen som ett GIS tillför är ändå noggrannhet i beräkningar. Vissa saker måste dock i det avseendet beaktas. GIS-verktygen som sådana är gjorda så att de i många fall ger matematiskt korrekta lösningar på problem och i andra fall tillräckligt bra lösningar baserade på erfarenhets-mässiga (heuristiska) antaganden. Detta kan lätt inbjuda till falska för-hoppningar hos användarna. Det får inte glömmas bort att det ändå är kvaliteten på indata som i väldigt stor utsträckning påverkar resultatets till-förlitlighet. Risken finns för överskattning av resultat, i detta fall i form av rutter med avstånd och tider. De slutsatser man som användare drar utifrån verktygets resultat måste därför alltid relateras till noggrannheten på indata.

74

8.1.2 GIS som planeringsverktyg En annan aspekt på noggrannhet och detaljrikedom i resultat från GIS-verktyget är också till vilket ändamål verktyget ska användas. Om vi nu begränsar oss till ruttberäkningar så konstaterades det i inledningen av rapporten att denna typ av beräkningar kan användas på alla tre planerings-nivåer inom transportlogistik. Ruttberäkningar kan användas i samband med trafikområdesindelningar och tillgänglighetsanalyser som båda gärna före-kommer vid strategisk planering. Ruttberäkningar kan även användas vid distributionsplanering och linjeval något som används vid den taktiska planeringen. Till sist används ruttberäkningar vid den operativa planeringen i samband med ruttplanering på sikt såväl som i realtid.

Utan att för den skull göra någon vetenskaplig undersökning kan man anta att olika krav ställs på (absolut) noggrannhet, detaljrikedom, stabilitet och användargränssnitt på programvaror som ska användas vid de olika planeringstillfällena.

Vid strategisk planering arbetar man gärna med stora datamängder och letar efter mönster som kan ge vägledning till beslutsfattande. Den absoluta nog-grannheten i indata och därmed även i resultat är inte det primära utan att för den skull ge avkall på den relativa noggrannheten. En flexibel programvara i form av många funktioner kan däremot vara ett kriterium man lägger större vikt vid. För användaren är det möjligheten att kunna betrakta och analysera datamängder på olika sätt för att hitta strategier och lösningar som är viktig. Med flexibilitet följer gärna att användargränssnittet inte är av det enklare slaget.

Vid operativ planering ställs andra krav på noggrannhet, detaljrikedom, stabilitet och användargränssnitt. I dessa sammanhang är det viktigare med hög absolut noggrannhet och detaljrikedom i indata och resultat. Som exempel kan nämnas en väg med en viadukt med fri fordonshöjd 2,3 meter. Om en vägdatabas inte alls anger att denna väg begränsas av en viadukt skulle ett ruttplaneringsverktyg kunna ta med denna väg i en rutt även för fordon högre än 2,3 meter (dålig detaljrikedom på indata). Om en annan vägdatabas anger fordonshöjdsrestriktionen efter vägen avrundat till 2 meter skulle ett planeringsverktyg missa möjligheten att låta fordon med höjden 2,1 meter välja denna väg. Båda exemplen skulle kunna leda till fel i resultat som direkt påverkar en verksamhet.

Planering på operativ nivå är ofta också mer tidskritisk än på strategisk nivå. Större krav sätts därför på en stabil programvara. Här följer också större krav på enkelt användargränssnitt med snabb hantering och få källor till användarfel. Beräkningar sker ofta i realtid och då finns inte något utrymme för tveksamheter vid användningen av programvaran.

De plattformer som idag marknadsförs som transportplaneringssystem eller transportlogistiska plattformer kommer från två skilda håll. Dels har vi de etablerade GIS-tillverkarna som utifrån ett GIS-perspektiv försöker etablera sina produkter inom transportsektorn. Dessa företag har förmodligen en bred kunskapsgrund att stå på vad gäller geografisk informationsvetenskap och deras programvaror bygger oftast på en GIS – plattform. ESRI är ett exempel på ett sådant företag.

75

På andra sida finns utvecklingsföretag som direkt inriktat sig på spetsprogram-varor för transportsektorn som exempelvis fordonsplaneringssystem. Företagen har koncentrerat sig på logistik och transport och deras program-varor är från början inriktade på att lösa den typen av uppgifter. DPS International är exempel på ett sådant företag.

8.2 Vägdatabasen En bra vägdatabas är ett måste för att kunna arbeta med transportlogistik där godset går på landsväg. I detta arbete har den kommersiella vägdatabasen Tele Atlas MultiNet använts. Någon grundlig jämförelse mellan dess informations-innehåll gentemot andra vägdatabasers innehåll har inte gjorts. Däremot kan följande slutsatser dras angående databasens information för Falköping kommuns geografiska utsnitt:

Vägdatabasen har:

Uppvisat god detaljrikedom vad gäller befintliga vägar. De stickprovs-kontroller på rutter inom Falköping kommun som gjordes i samband med det praktiska fallet visade på god tillförlitlighet av vägnät.

Visat sig innehålla relativt tillförlitliga tidsangivelser vad gäller transporttider över länkar (vägar) som ej ligger inom en större tätort och därmed heller inte är så beroende av hög- respektive lågtrafik. Någon kontroll av hur relevanta restiderna är i större tätorter, t.ex. av Göteborgs storlek, har inte gjorts.

Vägdatabasen uppvisade inte så bra resultat avseende adressmatchning. Många gator saknade helt enkelt gatunummerinformation. Vad det gäller fallet Falköping förekom dessutom en hel del landsortsadresser vilket innebar att gata eller plats över huvud taget inte fanns med i vägdatabasen. För adressmatchning finns i stället andra möjligheter. Det som testades i detta arbete var att använda sig av Lantmäteriets fastighetsregister som innehåller belägenhetsadresser insamlade av kommunen själv. Mot detta register var det inga problem med adressmatchningen.

Databasens objekt- och datamodell erbjuder möjligheten att använda sig av fordonsspecifika restriktioner. För fallet Falköping fanns ingen sådan information insamlad vid testtillfället.

Vägdatabasen innehåller mycket information. Det kan vara svårt för en användare att hitta, förstå och använda sig av den på rätt sätt. Beskrivningarna som medföljer databasen i form av pdf-dokument är uttömmande men inte så lätta att hitta i. På en direkt förfrågan om detta problem till den svenska leverantören av Tele Atlas fås svaret att de är medvetna om problemet. Planer finns därför på att en implementation av databasen hos kund anpassas till GIS-plattform och tillämpning.

8.3 ArcGIS 9.1 med Network Analyst ArcGIS och Network Analyst ska ses som en plattform och inte en enskild applikation. I själva verket rymmer denna plattform ett antal applikationer (ArcMAP, ArcCatalog, ModelBuilder m.fl.). Alla i och för sig inte fristående

76

men ändå så komplexa och fulla med funktioner att de sett ur den synvinkeln kan betraktas som enskilda programpaket. Tittar man sedan på Network Analyst ser man att denna tilläggsmodul innehåller ett antal funktioner vars sammanlagda tillämpningsområde är väldigt brett. I modulen finns verktyg för närhetsanalys, serviceyta, ruttberäkningar, körinstruktioner m.m. allt baserat på beräkningar på ett underliggande nätverk. För att som organisation tillgodogöra sig dessa funktioner fullt ut krävs en hög kunskapsnivå av personal som arbetar med programvaran. Dessutom är det viktigt i detta sammanhang att poängtera att förutom kunskaperna om GIS och verktyget krävs oftast stora kunskaper om tillämpningsområdet för att kunna tillgodo-göra sig verktygets möjligheter. Inte minst blir detta aktuellt vid tolkning av resultat.

Med hög inlärningströskel följer också att frekvent användning av verktyget krävs för att bibehålla kunskaperna. Sporadiskt användande av verktyget leder till att man får lära på nytt.

Sammantaget ger detta att ArcGIS 9.1 med Network Analyst, i den form som den levereras från ESRI, är ett komplext verktyg med många möjligheter men som kanske inte lämpar sig för en organisation utan specialkompetens inom GIS. Det krävs tid och kunskap för att sätta sig in i verktyget. Detta speciellt också med tanke på att så många andra funktioner än kanske de man som köpare är ute efter följer med i köpet.

Till ArcGIS fördel hör att den är en GIS-plattform med bred förankring inom GIS-branschen. Det gör att många konsulter och utvecklare redan idag använder sig av den som underliggande plattform vid utveckling av applikationer som är direkt anpassade för en specifik verksamhet. I en sådan anpassad applikation finns då möjlighet till enkelt gränssnitt, lättare och snabbare hantering av programvaran samt en lägre inlärningströskel.

För en organisation med stor GIS-kompetens är Network Analyst ett bra verktyg med bra utvecklingsmöjligheter. Att på ett snabbt och enkelt sätt kunna anpassa applikationen till den egna verksamheten med hjälp av verktyg som mallar och Modelbuilder är bra. Med gott IT-stöd finns sedan, med hjälp av VBA och ArcObjects, ytterligare möjligheter till en verksamhetsanpassning av plattformen för olika nivåer inom organisationen.

ArcGIS visar alltså med tydlighet att dess bakgrund är som tidigare beskrevs GIS-världen och att den inte är en produkt av ett företag som nischat sig inom transportplanering. Den ska därför heller inte betraktas som en färdig produkt för ruttberäkningar och ruttplanering på operativ nivå inom transport-branschen. Det skulle däremot vara väldigt intressant att få se ESRI:s produkt ArcLogistics Route på den svenska marknaden. ArcLogistics Route är ESRI:s programvara ämnad för ruttplanering och flottoptimering. Tyvärr finns den idag inte tillgänglig för den svenska marknaden.

8.4 Plattformen – Network Analyst och Tele Atlas MultiNet

Med hjälp av Network Analyst och Tele Atlas MultiNet kan ruttberäkningar genomföras där hänsyn tas till:

77

Optimering avseende bl.a. längd och tid. Andra impedanser går att modellera.

Väghierarkier baserade på vägklasser.

En mängd restriktioner. Till exempel:

o enkelriktade vägar

o blockerade passager

o privata vägar

o förbjudna svängar

o ej tillåta U-svängar.

Möjlighet till användning av fordonsspecifika restriktioner finns i databas-struktur och applikation. Som tidigare nämnts fanns däremot ingen sådan insamlad data, för aktuellt geografiskt område, i databasen vid testtillfället.

Vad man måste komma ihåg är att all hantering av programvaran är starkt knuten till den underliggande vägdatabasen och dess struktur. Vilka hinder man som användare och/eller utvecklare stöter på när det gäller att hitta rätt funktionalitet och information beror dels på programvaran, dels på vägdata-basen.

Några av de problem som uppstod i samband med arbetet med fallet Falköping var:

Hanteringen av svängar är begränsad till vilken information som finns inlagd i vägdatabasen. Datamodellen för svängar i databasen kontra Network Analyst är inte kompatibla vilket kräver programvara för konvertering. ESRI menar att sådan är på gång för exempelvis Tele Atlas. Så länge konverteringen inte finns är enda möjligheten till hantering av impedanser och restriktioner på svängar att för hand rita in dessa i aktuellt geografiskt område vilket inte kan ses som praktiskt möjligt i de flesta tillämpningsfall. En annan möjlighet är annars att arbeta med svängar globalt. Detta användes inte inom detta projekt.

För att adressmatchning ska kunna genomföras krävs stilmallar som beskriver ett lands adressformat. Dessa s.k. adress locator styles fanns vid detta arbetes genomförande ännu inte att tillgå för version 9.1.

Import och export från och till excel-formatet finns inte att tillgå i grundutförande av ArcGIS 9. Gissningsvis är detta en funktion som många användare önskar vilket också ESRI Sweden bekräftar6. Det går att ansluta till en excelfil via en OLE DB7-anslutning vilket är för-hållandevis omständligt och ger endast läsrättigheter.

ArcGIS-plattformen ger med hjälp av ArcSDE möjligheten till centraliserade system för flera användare och datalagring i ett RDBMS som exempelvis Oracle, DB2 eller Informix. Detta bör beaktas vid planering av framtida satsningar för en organisation. Vägdatabasen Tele Atlas MultiNet levereras dessutom förutom i ESRI:s shapeformat även i Oracle SDE-format.

6 Muntlig källa: Håkan Nordlund, ESRI, 2005-04-27 7 COM-baserade användargränssnitt för nätverks- och Internetåtkomst av datakällor.

78

8.5 Transportföretags användande av GIS Några större slutsatser angående användning av GIS och ruttplaneringssystem hos de stora aktörerna på transportmarknaden kommer inte att dras utifrån detta arbete eftersom endast ett par exempel tagits upp. Ett planerat besök hos ytterligare ett transportföretag genomfördes aldrig p.g.a. ej påverkbara anledningar följda av tidsbrist för detta arbetes genomförande.

De två exempel som redovisats visar ändå på det faktum att systemen hämtats från båda lägren av företagskulturer (se avsnitt 8.1.2). Posten har valt att köpa in sin lösning från danska Transvision som är ett företag som specialiserat sig på transportsektorn. Verktyget är utvecklat av Transvision själva. Dess funktioner är inriktade på ruttplanering, inte GIS i allmän bemärkelse. DHL har valt att bygga sin lösning på ArcGIS. Systemet är byggt av WSP som anpassat ArcGIS till den tänkta tillämpningen. I grunden har man ändå en komplett GIS-plattform med dess breda GIS-kompetens.

Vad som också bör nämnas är att aktörer som Schenker och DHL idag inte använder sig av rena ruttplaneringssystem i så stor utsträckning. Enligt Thomas Rickne8 på DPS är inte dessa företag bra exempel den typiska användaren av deras ruttplaneringssystem eftersom de i huvudsak kör fasta linjer. Företag som Posten och Ica nämns istället som typanvändare av rutt-planeringssystem. Frågan om dessa företag arbetar mer med dynamiska rutter eller inte besvaras inte här men detta skulle i så fall vara förklaringen till varför den typen av företag idag använder sig mer av ruttplaneringssystem.

8 Muntlig källa: Thomas Rickne, DPS International, 2005-05-31

79

Referenser Eklundh Lars (red.) (1999) Geografisk informationsbehandling Stockholm: Byggforskningsrådet, ISBN 91-540-5841-4

ESRI (2004), ArcGIS Desktop Developer Guide, ArcGIS 9.0 USA: ESRI

ESRI (2001–2004), ArcGIS 9 – What is ArcGIS? USA: ESRI

ESRI (1998), ESRI Shapefile Technical Description, An ESRI White Paper – July 1998 USA: ESRI

ESRI, ArcGIS Desktop Help, ArcGIS Desktop 9.1

ESRI, Geodatabase, [Elektronisk] Tillgänglig: <http://www.esri.com/software/arcgis/geodatabase/about/personal.html> <http://www.esri.com/software/arcgis/geodatabase/about/tables.html> [2005-05-12]

ESRI Sweden AB, Företagets webbplats [Elektronisk] Tillgänglig: <http://www.esri-sweden.com/index.htm> [2005-06-04]

ESRI, The ArcGIS Network Model, Technical Documents [Elektronisk] Tillgänglig: <http://edndoc.esri.com/arcobjects/9.1/default.asp> Sökväg: Technical Documents/Networks/ArcGIS Network Model [2005-06-13]

Goodchild Michael F. (1997), Unit 002 – What is Geographic Information System, [Elektronisk] University of California Santa Barbara Tillgänglig: <http://www.ncgia.ucsb.edu/giscc/units/u002/> [2005-04-26]

Lantmäteriet, Byggnader, Adresser och Lägenheter med Kartstöd (BALK) – Adresser [Elektronisk] Tillgänglig: <http://www.lantmateriet.se/templates/LMV_Page.aspx?id=2002> [2005-06-20]

Lumsden Kenth (1995) Transportekonomi – Logistiska modeller för resursflöden Lund: Studentlitteratur ISBN: 91-44-61041-6

Jonsson Patrik, Mattsson Stig-Arne (2004) Logistik – Läran om effektiva materialflöden Göteborg: Chalmers tekniska högskola, Institutionen för logistik och transport

Navteq Allmän information om företaget och dess produkter. [Elektronisk] Tillgänglig: <http://www.navteq.com/> [2005-05-09]

RLK, Transportlogistik, Presentation av produkter och tjänster [Elektronisk] Tillgänglig: <http://www.transportlogistik.com> [2005-08-08]

SIS (2005), Adressättning i stad och på landsbygd, Rapport SIS/TK 466 N 070 SIS, Swedish Standards Institute

Tarkowski Jerzy, Ireståhl Bo, Lumsden Kenth (1995) Transportlogistik Lund: Studentlitteratur ISBN 91-44-60371-1

Tekis AB (2004), Väginformatik i nytt format, [Elektronisk] Tillgänglig: <http://www.tekis.se/PDF/produkter/teknisk_forvaltning/Lokal_Vagdatabas_okt_04.pdf> [2005-05-09]

80

Tele Atlas, Tele Atlas MultiNet 3.3 Dokumentation [Elektronisk] Shapefile_4_2_1_Format_Specifications_v1-1.pdf MultiNet3.3_Data_Specs_v1.0.pdf MultiNet_3.3_Data_Model-v1.0.pdf MultiNet_UserGuide_Shapefile_v1.41.pdf

Thomas H. Cormen m.fl. (1990) Introduction to algorithms Cambridge, Massachusetts: The Massachusetts Institute of Technology

Shashi Shekhar & Sanjay Chawla (2003) Spatial databases, a tour New Jersey, USA: Prentice Hall, Pearson Education Inc.

Stanli (2003), Nyheter från Stanli, nr 4, november 2003 [Elektronisk] Tillgänglig: <http://www.sis.se/upload/632331876150912500.pdf> [2005-05-09]

Wiik Christer (2003), Stockholm satsar på lokal vägdatabas, Nordisk Geomatik nr 6 2003

Vägverket, NVDB – Nationell vägdatabas [Elektronisk] Tillgänglig: <http://www.vv.se/nvdb/index.asp> sökväg 1: /Vad är NVDB? sökväg 2: /Vad är NVDB?/Verksamhet, sökväg 3: /Vad är NVDB?/Verksamhet/Veksamhetsmodell [2005-05-09]

Zeiler Michael (1999), Modeling Our World, The ESRI Guide to Geodatabase design USA, California: ESRI

Examensarbeten utförda inom projektet ”Samordning av logistiska resurser inom transportområdet” i Falköpings kommun: Andersson Maria, Thorén Maria (2005), Kriterier för en samordningscentral – En fallstudie på Falköpings kommun, Examensarbete på programmet Industriell ekonomi, C-nivå 20 poäng.

Aronsson Madelene, Häggmark Anna (2005), Samordning av livsmedelstransporter ur mottagarens perspektiv – En fallstudie på Falköpings kommun, Examensarbete på programmet Industriell ekonomi, C-nivå 20 poäng.

Guy Humberto (2005), Datorstödd transportresursplanering – En GIS-studie, Examensarbete på Chalmers, 20 poäng.

Litteraturförslag: Hofmann-Wellenhof B., Lichtenegger H., Collins J. (2001), Global positioning system : theory and practice, Wien: Springer, ISBN 3-211-83534-2

ESRI (2003), Geocoding Rule Base Developer Guide USA: ESRI

81

Bilaga A

A Matematiska och datalogiska teorier Detta arbete behandlar frågor och problem av typen ”hur tar man sig från Göteborg till Falköping?”, vilken är den kortaste vägen från Skövde till Vara?” eller ”vilken är den snabbaste vägen till Uddevalla från Jönköping?” För att på ett riktigt sätt kunna arbeta med den typen av problem krävs ett underliggande verktyg som ger entydighet i formulering, hantering och resultat. Detta grundverktyg är matematiken med grafteori och algoritmer. I denna bilaga kommer grunderna i grafteori och algoritmtekniker som är rele-vanta för denna rapport att tas upp. Bilagan ger läsaren en djupare förståelse i hur verktyg inom tillämpningsområdet arbetar.

A.1 Grafteori – grundläggande definitioner Vid frågor av typen ”vilken är den kortaste vägen från Skövde till Vara?” kan man särskilja två typer av objekt, platser och vägar. Inom grafteorin finns ett antal olika terminologier och den som här används är den som används av Grimaldi (1994).

Mängden av de platser man betraktar betecknas med V och mängden vägar betecknas med E. Vilka möjligheter till förflyttning mellan platserna som finns kan beskrivas som en matematisk relation.

Definition 1: Låt R vara en relation på V sådan att a R b betyder att vi kan förflytta oss från a till b genom att enbart använda oss av vägar som finns i E. Om vägarna i E som tar oss från a till b alla är dubbelriktade (dvs ej enkelriktade) så har vi även b R a. Om alla vägar i E är dubbelriktade så är relationen symmetrisk.

Relationer av denna typ åskådliggörs lättast med hjälp av bilderna i figur 37. Om förflyttning över en väg endast är tillåten åt ett håll visas detta med hjälp av pilar enligt figur 37b. Om inga pilar finns utritade förutsätts att förflyttning kan ske åt båda håll.

Figur 37 a) Relation på V = (a, b, c, d, e) där förflyttning på vägarna är tillåten i bägge riktningarna.

b) Relation på V = (a, b, c, d, e) där förflyttning på vägarna är tillåten i endast en riktning.

I grafteoretiska sammanhang översätts platser V till hörn och vägar E till kanter. Beteckningarna V och E kommer från engelskans vertices respektive edges. Med detta som grund kan man nu definiera begreppet graf.

I

Bilaga A

Definition 2 (Graf) En graf G består av två disjunkta mängder V och E. Mängden V är en ändlig, icke tom mängd. Mängden E är en två-delmängd till V dvs E ⊆ V×V. Elementen i V kallas för hörn och elementen i E kallas för kanter. Vi skriver vanligtvis G = (V, E).

Definition 3 (Riktade respektive oriktade grafer) Om en eller fler kanter i en graf G är riktade, dvs förflyttning efter kanten kan ske endast åt ett håll, är grafen en riktad graf. Annars är den en oriktad graf.

Grafen i figur 37a är en oriktad graf medan grafen i figur 37b är en riktad graf.

Om man låter V = {a, b, c, d, e} menas med E = (a, b) den kant som går från hörn a till hörn b. Hörn a kallas i detta fall för kantens källa och hörn b för kantens mål. Kanten (a, b) har i detta fall en riktning.

Om alla kanter i E saknar riktning i en graf G kan man istället skriva {a, b} vilket visar att kanten saknar riktning.

Grafen i figur 37a kan utifrån ovanstående betecknas som G = (V, E) med V = {a, b, c, d, e} och E = {{a,b}, {a,d}, {b,d}, {b,e}, {b,c}, {d,e}}.

Grafen i figur 37b betecknas som G = (V, E) med V = {a, b, c, d, e} och E = {(b,a), (d,a), (d,b), (b,e), (c,b), (e,d)}.

Definition 4 (Promenad, slinga, stig, cykel) Låt G = (V, E) vara en oriktad graf.

En ändlig följd av hörn och kanter v1,e1,v2,e2,…,vn-1,en-1,vn där vi∈V och ei∈E kallas för en promenad (eng: walk) i grafen G.

Observera att i en promenad kan distinkta hörn och kanter förekomma flera gånger.

Om ingen kant förekommer mer än en gång i en promenad kallas den för en slinga (eng: trail).

Om inget hörn förekommer mer än en gång i en slinga kallas den för en stig (eng: path).

Om en stig startar och slutar i samma hörn kallas den för en cykel.

Betrakta grafen i figur 37a. Om en person förflyttar sig från b till c via kanterna {b,d}, {d,e}, {e,b} och {b,c} har denne förflyttat sig längs med en promenad. Eftersom ingen kant använts mer än en gång kan denna promenad även betraktas som en slinga. Den är däremot ingen stig eftersom hörnet b förekommer två gånger. Den är heller ingen cykel eftersom promenaden inte avslutas i samma hörn som den startades.

Om man istället betraktar förflyttningen {a,d}, {d,e} och {e,b} ser man att denna förflyttning görs efter en stig. Om förflyttningen kompletteras med kanten {b,a} har man en cykel.

Definition 5 (Sammanhängande graf) Låt G = (V, E) vara en oriktad graf.

II

Bilaga A

G är en sammanhängande graf om det finns en stig mellan alla hörn a och b som finns i G.

Definition 5 (Planär graf) En graf G = (V, E) kallas planär om den kan ritas i planet på ett sådant sätt att inga kanter i G korsar varandra (se figur 38).

Figur 38 a) Planär graf b) Icke planär graf

Definition 6 (Kostnad, impedans, viktad graf) Låt G = (V, E) vara en riktad graf. Till varje kant (a, b) i G tilldelas ett reellt tal som här betecknas med wt(a, b). Talet wt(a, b) kallas för kantens vikt. Om a, b tillhör E men (a, b) inte tillhör V (dvs det finns ingen kant mellan a och b) så definieras wt(a, b) = ∞ .

En kants vikt wt(a, b) kan representera:

kantens längd

tiden det tar att förflytta sig från a till b

annan kostnad för att förflytta sig från a till b.

En graf där kanterna tilldelats en vikt kallas för en viktad graf.

Vikter kan även användas på oriktade grafer med.

Definition 7 (Täta och glesa grafer) Med en tät graf menas en graf där |E| är avsevärt mycket mindre än |V|2. En gles graf har däremot egenskapen att |E| är nära |V|2. (Thomas H. Cormen m.fl., 1990)

Ovanstående grundläggande definitioner inom grafteorin bidrar till det verktyg som behövs för att visualisera nätverk av olika slag.

A.2 Representation av grafer Det finns två vanliga sätt att numeriskt representera en graf på, som en samling grannlistor eller som en grannmatris.

III

Bilaga A

Grannlistor En samling grannlistor som ska representera en graf G = (V, E) lagras i en vektor A av längden |V|. För varje kant Vu∈ finns en grannlista A[u] som innehåller alla hörn som är grannar till u (se figur 39).

Figur 39 Exempel på grannlistor med tillhörande graf

Representation i form av grannlistor har den positiva egenskapen att minnesutrymmet som krävs är O(max(V,E)) = O(V + E), dvs minnesutrymmet har en asymtotisk övre gräns som är linjärt proportionell mot antalet kanter och hörn i grafen. (Se A.3)

Grannlistor kan på ett enkelt sätt representera viktade grafer. Den vikt som hör till kanten lagras då tillsammans med v i u:s grannlista. Evu ∈),(

Grannmatris En grannmatris byggs upp på följande vis. Numrera hörnen i grafen G = (V, E) med 1, 2,…, |V|. Grannmatrisen består av en |V| × |V| matris A = (ai,j) sådan att

⎩⎨⎧ ∈

=annars

Ejioma ji 0

),(1,

En grannmatris kräver ett minnesutrymme i storleksordningen Θ(V2).

Exempel på en grannmatris och dess graf visas i figur 40.

Figur 40 Exempel på en grannmatris och dess tillhörande graf

IV

Bilaga A

Allmänt kan sägas att grannlistor är den representationsmodell som är mest förekommande. Denna lagringsstruktur ger att lagringsutrymmets storlek kan hållas nere då graferna är stora och glesa jämförelsevis med motsvarande implementation med hjälp av en grannmatris. En annan fördel med grannlistor är möjligheten att snabbt finna ett givet hörns grannar.

Handlar det däremot om grafer som kan anses vara täta eller grafer som inte är så stora kan det vara idé att använda sig av grannmatriser. Dess fördel ligger i möjligheten att snabbt avgöra om det existerar en kant eller ej mellan två givna hörn.

A.3 Algoritmanalys och tidskomplexitet Vid problemlösning med hjälp av algoritmer är det av intresse att kunna uppskatta vilka resurser som krävs i form av minne, beräkningstid mm för att genomföra beräkningen på en dator. Algoritmanalys är därför något som bör utföras. Oftast är det tiden som är det intressanta när man analyserar algoritmer. (Cormen m.fl., 1998)

Vid analys av algoritmer används en modell där beräkningstiden för en algoritm anges i relation till storleken på indata. Detta ger en vägledning i hur snabbt tiden för att lösa en uppgift med hjälp av algoritmen växer i takt med storleken på indata. Vanligast är att titta på något som kallas för värsta fallet (eng. worst-case).

Vid värsta fallet-analys anges en övre gräns för beräkningstiden. För en del algoritmer och typer av användningsområden inträffar värsta fallet relativt ofta, i andra fall mer sällan. En algoritms beräkningstid i värsta fallet betecknas med O(g(n)) som representerar en asymptotisk9 övre gräns för beräkningstiden där n är mängden indata och g någon given funktion.

Exempel: Algoritm A har en övre gräns på O(n2) för att lösa ett givet problem. Med detta menas då att algoritmens värsta fall växer med kvadraten på mängden indata. Algoritm B anges ha en övre gräns på O(n) för att lösa samma problem. Denna algoritms värsta fall växer därmed linjärt med mängden indata vilket är betydligt långsammare än värsta fallet för algoritm A.

A.4 Beräkningsbarhet Problem delas in i klasser beroende på hur svåra de är att lösa. Ett problem till vilket man kan hitta en algoritm som löser problemet inom polynomisk tid hör till klassen P. Med polynomisk tid menas att algoritmens värsta fall är uppåt begränsad av O(nk) där k är någon konstant. Ett exempel på ett sådant problem är beräkning av kortaste vägen i en graf G = (V, E) som med hjälp av Dijkstras algoritm (se avsnitt A.7) kan lösas med tidskomplexiteten O(n2).

Det finns även problem som idag inte kan lösas med någon algoritm inom polynomisk tid men som heller inte är bevisat att de absolut kräver en algoritm som ger en lösning inom superpolynomisk tid. Dessa s.k. NP-fullständiga

9 ”Linje eller kurva som utgör en approximation till en funktion i någon del av definitionsmängden.” Källa: http://sv.wikipedia.org/wiki/Asymptot [2005-11-17].

V

Bilaga A

problem är av särskilt intresse inom datavetenskapen eftersom de har den karakteristiken att kan man lösa ett av problemen inom polynomisk tid kan man lösa alla problemen inom denna tid. För dessa problem finns idag enbart superpolynomiska algoritmer vilket gör att exakta lösningar för problemen då indatamängden växer inte är möjliga att nå tidseffektivt.

A.5 Dynamisk programmering och giriga algoritmer Optimeringsproblem där strukturen på lösningsmetoden är att stegvis göra val som till sist leder till en optimerad lösning använder sig av bl.a. två viktiga algoritmtekniker: dynamisk programmering och giriga algoritmer. Det är två tekniker där man vid en första anblick kan tycka att båda teknikerna borde fungera som lösningsmetod på ett och samma problem men som faktiskt visar sig vara två verktyg lämpade att använda vid olika sammanhang.

Ett exempel på arbetssätt vid dynamisk programmering är att dela upp ett problem i mindre delproblem. Delproblemens resultat sparas i en tabell för att på så sätt kunna återanvändas om samma delproblem dyker upp flera gånger. På det viset blir algoritmen ofta effektivare än om problemet angrips med traditionell rekursiv lösning.

I många sammanhang räcker det att använda sig av s.k. giriga algoritmer som är en enklare typ av algoritmkonstruktion. En girig algoritm gör alltid det val som för tillfället verkar vara den mest optimala. Den gör med andra ord lokalt optimala val med förhoppningen att de leder till en globalt optimal lösning. En girig algoritm leder inte alltid till en optimal lösning men där det går att bevisa att den leder till en sådan lösning är den oftast både en enkel och effektiv lösningsmetod (Cormen m.fl., 1998).

A.6 Heuristik Om ett problem är svårt att lösa tidseffektivt med kända algoritmer kan heuristik vara en metod för att hitta en lösning. Att lösa problem med heuristik handlar om att göra val som bygger på erfarenhetsmässiga antaganden av något slag. Lösningen som ges kanske inte är den optimala men den är tillräckligt bra för att kunna användas i sitt sammanhang. Det är till och med inte helt säkert att en heuristik alltid kommer fram till en lösning av ett problem (NIST). Giriga algoritmer används ofta i samband med heuristiska lösningar.

A.7 Grundläggande grafteoretiska algoritmer Inom grafteorin finns ett antal grundläggande algoritmer vars idéer dyker upp i mer komplexa algoritmer. Algoritmerna handlar allmänt om att på något sätt utforska grafer och deras tillstånd. De benämns allmänt för graftraverserande algoritmer. Det vanligaste sättet att representera en graf på vid algoritmkonstruktion är med hjälp av en grannlista men det finns även algoritmer som förutsätter lagring med hjälp av en grannmatris.

En vanlig algoritm som används för att utforska en graf och som dessutom ger den kortaste vägen avseende antalet traverserade kanter är bredden-först-sökning (BFS). Den använder sig av en grannlista för representation av en graf

VI

Bilaga A

och undersöker hörnen i grafen stegvis. Utifrån ett givet hörn utforskas grafen genom att först besöka alla hörn på en kants avstånd från starthörnet, därefter alla hörn på två kanters avstånd från starthörnet osv till dess alla hörn besökts. Därav namnet bredden-först-sökning.

BFS:s koncept används av många andra algoritmer, exempelvis Dijkstras algoritm som är en av de mer kända för att hitta kortaste vägen mellan två hörn i en graf. Med kortaste vägen menas här den mest optimerade avseende grafens vikter. En förenklad beskrivning av algoritmens är:

Problemet:

Låt G = (V, E) vara en riktad, sammanhängande graf med icke-negativa vikter, betecknade med wt(u, w), tilldelat alla kanter i E. Utifrån ett givet hörn v0 i V, hitta kortaste stigen till alla andra hörn i V.

Lösning:

1. Utgå från det angivna hörnet, v0. Detta hörn hör nu till mängden besökta hörn kallad S. Alla andra hörn hör till mängden obesökta hörn kallad S .

2. Om S är tom så är det klart och uppgiften är löst. Annars gå vidare till punkt 3.

3. Hitta den kant e = (u, w) med minst vikt där Su∈ och Sw∈ , dvs som

går från S till S .

4. Flytta w från S till S. Hörnet w finns nu med i mängden besökta hörn, S.

5. För protokoll över det funna hörnet w, vikten wt(u, w) och från-hörnet u.

6. Gå till punkt 2.

Ovan ges ingen beskrivning till på vilket sätt protokoll ska föras. I detta ligger informationen om dels den totala längden (vikten) av en stig från v0 till något av de andra hörnen, dels vägbeskrivningen, dvs vilka hörn och kanter som ska traverseras i stigen. För en mer detaljerad beskrivning av Dijkstras algoritm hänvisas till Grimaldi (1994).

Dijkstras algoritm är en girig algoritm vilket visar sig i punkt 3 där ett lokalt optimalt val görs. Detta val leder också till en matematiskt bevisad global optimal lösning.

Dijkstras algoritm har tidskomplexiteten O(V2) men den kan i glesa grafer och med modifiering av sökningen i punkt 3 minskas till O(E lg V) om alla hörn kan nås från v0. (Cormen m.fl., 1998.)

A.8 TSP och ruttplanering En handelsresande problem (Traveling salesman problem), kort kallat TSP-problemet, är ett problem som är NP-fullständigt. Det är nära relaterat till det

VII

Bilaga A

att hitta en hamiltoncykel, vilket innebär att i en oriktad graf hitta en cykel som besöker alla noder exakt en gång. Med TSP tillkommer svårigheten att hitta den mest optimerade vägen avseende grafens vikt.

Problemet finns beskrivet i ett antal olika formuleringar. I en klassisk beskrivning av problemet ska varje hörn besökas exakt en gång, ett kriterie som gärna ändras till minst en gång vid tillämpningar som exempelvis ruttplanering.

Eftersom TSP är NP-fullständigt krävs approximativa algoritmer eller heuristik vid en praktisk tillämpning av det. Ett exempel på en heuristik som används för att lösa TSP är Tabusökning. Tekniken nämns sedan slutet av 70-talet och har sedan dess varit föremål för en hel del forskning (CCIM, 1997). Det signifikanta för tekniken är att under sökning efter alternativa lösningar kan redan undersökta sökområden ignoreras. Detta kan i sin tur leda till alternativa lösningar med sämre resultat än tidigare nådda alternativ. Tanken är att algoritmen på det viset ska förmås att utforska nya sökområden (möjligheter till lösningar), en utforskning som förhoppningsvis ger information som leder till en optimal lösning. (Tabu search, 2004)

VIII

Bilaga A

Referenser CCIM, (1997) Computation, computers, information and mathematics, Tabu search [Elektronisk] Tillgänglig: <http://www.cs.sandia.gov/opt/survey/ts.html> [2005-09-15]

Cormen Thomas H. m.fl., (1998) Introduction to algorithms Cambridge, Massachusetts, England: The MIT Press Massachusetts Institute of Technology

Grimaldi Ralph P. (1994) Discrete and combinatorial mathematics USA: Addison Wesley ISBN 0-201-60044-7

NIST, National Institute of Standards and Technology [Elektronisk] Tillgänglig: <http://www.nist.gov/dads/HTML/heuristic.html> [2005-09-15]

Tabu search, 2004, Tabu search homesite [Elektronisk] Tillgänglig: <http://www.tabusearch.net/Tabu_Search/What_is_Tabu_search.ASP> [2005-09-15]

IX

Bilaga B

B Snabbguide till NIAM-diagram (Nijssens Information Analyses Method). Symbol: Representerar: Cirkel En informationskomponent Linje utan pil mellan cirklar Relation mellan informationskomponenter Linje med pil mellan cirklar Är-relation mellan informationskomponenter Rektangel Specifikation över relation mellan informationskomponenter

”A” har relationen x till ”B”

Unik relation

Exklusiv relation

Tvingande relation

A är en B. Med detta menas att mängden objekt av typen A är en delmängd av mängden objekt av typen B.

Källa: (Tele Atlas, MultiNet_3.3_Data_Model-v1.0.pdfsid 5)

I

Bilaga C

C Beskrivning av attribut till Tele Atlas nätverksdatalager

Tabell med beskrivning av ett urval attribut till Tele Atlas nätverksdatalager.

Urvalet av attribut har gjorts utifrån relevans för arbete med ruttberäkningar samt utifrån vilka fält som används i den för Sverige aktuella delen av databasen.

För en mer komplett beskrivning se Tele Atlas MultiNet Dokumentation, Shapefile_4_2_1_Format_Specifications_v1-1.pdf.

Fältnamn Beskrivning ID Elementidentifikation (Feature identification) FEATTYP Typ av element

4110: Vägelement 4130: Färjelinjeelement 4165: Adressareaelement (ytor med adressättning som inte knyts till vägelement)

F_JNCTID ID för frånkorsning T_JNCTID ID för tillkorsning METERS Längden på elementet (meter) FRC Functional Road Class

-1: Ej relevant. Anges för elementtyp 4165 0...8: Vägklasser För utförligare beskrivning se Utdrag_shapefile_format_specification_vagklasser.pdf

NETCLASS Calculated NetClass Innehåller det som tidigare benämndes Net 1 Class. 0: Ej relevant 1...4: Vägklasser För utförligare beskrivning se Utdrag_shapefile_format_specification_vagklasser.pdf

NETBCLASS Net B Class 0: Ej relevant 1...6: Vägklasser – Klass 1 högsta klassen För utförligare beskrivning se Utdrag_shapefile_format_specification_vagklasser.pdf

NET2CLASS Net 2 Class -1: Ej relevant 0...6: Vägklasser - Klass 0 högsta klassen För utförligare beskrivning se Utdrag_shapefile_format_specification_vagklasser.pdf

NAME Officiellt gatunamn NAMELC Landskod för det officiella gatunamnet CHARGE Vägavgift

Blank: none (default) B: Avgift i båda riktningarna FT: Avgift i från-till-riktning TF: Avgift i till-från-riktning

ROUTENUM Vägnummer

Tabellen fortsätter på nästa sida…

I

Bilaga C

Fältnamn Beskrivning RTETYP Typ av vägnummer

Blank: Ej relevant 0: Okänt 1: Länsväg 2: Riksväg 3: Europaväg Denna tolkning av klassindelningen är utifrån värden angivna i databasen.

PROCSTAT Status på attributsättningen 1: Komplett attributsatt (default) 2. Grundläggande attributsatt 3: Ej komplett attributsatt

FOW Typ av väg Tex del av motorväg, del av rondell osv. För fullständig beskrivning se Tele Atlas_nw_tabellen.pdf

FREEWAY Del av motorväg 0: Ej del av motorväg (default) 1: Del av motorväg

BACKRD Lastväg – godsleverans eller liknande Se Tele Atlas_nw_tabellen.pdf RDCOND Vägkondition

0: Ej relevant 1: Belagd väg 2: Ej belagd väg 3: Väg i dålig kondition

PRIVATERD Privat väg 0: Ingen restriktion 2: Ej tillgänglig för allmän trafik

CONSTATUS Konstruktionsstatus Blank: Ej under konstruktion (default) FT: Under konstruktion i från-till-riktning N: Under kontruktion i båda riktningarna TF: Under konstruktion i till-från-riktning

ONEWAY Trafikflödesriktning Blank: Trafik tillåten i båda riktningarna FT: Trafik tillåten i från-till-riktning N: Trafik ej tillåten i någon riktning TF: Trafik tillåten i till-från-riktning

F_BP Blockerad passage vid frånkorsningen 0: Ej blockerad (default) 1: Blockerad passage vid frånkorsningen

T_BP Blockerad passage vid tillkorsningen 0: Ej blockerad (default) 2: Blockerad passage vid tillkorsningen

F_ELEV Z-nivå vid frånkorsning 0: Grundnivå (default) -9...9 - Z-nivåer

T_ELEV Z-nivå vid tillkorsning 0: Grundnivå (default) -9...9 - Z-nivåer

KPH Beräknad medelhastighet (kilometer per timme) MINUTES Restid (minuter)

II

Bilaga D

D Beskrivning av attribut till Tele Atlas datalager för geokodning

Tabell med beskrivning av ett urval attribut till Tele Atlas datalager för geokodning.

För en mer komplett beskrivning se Tele Atlas MultiNet Dokumentation, Shapefile_4_2_1_Format_Specifications_v1-1.pdf.

Fältnamn Beskrivning ID Feature identification FEATTYP Feature type FULLNAME Street name NAMELC Street name language Code NAMETYP Street name type ON: Official name AN: Alternate name SOL Side of Line 0: Both sides 1: Left 2: Right NAME Street name body L_LAXORD Left lowest admin area order R_LAXORD Right lowest admin area order L_LAXON Left lowest admin area official name R_LAXON Right lowest admin area official name L_AXON Left lowest -1 admin area official name R_AXON Right lowest -1 admin area official name L_PC Left postal code R_PC Right postal code L_ADDRID Left address identification R_ADDRID Right address identification L_STRUCT Left house number structure L_F_ADD Left first/from base house number L_F_F_ADD Left first full house number L_F_I Interpolated left first house number 0: Not interpolated 1: Interpolated Same for L_T_ADD, L_T_F_ADD and L_T_I for last/to house number L_INTM Left intermediate house numbers flag

0: No intermediate house number 1: intermediate house number present

Same structure for right from R_STRUCT RECTYP Record type (address structure zip+4, zip+2)

Beskrivning av fält i tabellen för mellanliggande husnummer (filnamn: *_ih) ID Feature identification SEQNR Sequential number ADD Base house number F_ADD Full house number STRUCT House number structure Anges med 0 – 5 SOL Side of line

I

Bilaga E

E Programvaror – plattform

För detta examensarbetes genomförande användes följande plattform:

Programvaror:

ArcGIS 9.1 Desktop version: ArcInfo, med tilläggsmodulen Network Analyst.

ArcGIS 9.1 Desktop developer Kit.

Underliggande databaser:

Tele Atlas MultiNet Sweden 2004.2.

Falköping kommuns adressdatabas.

Systemkraven för ArcGIS Desktop ArcInfo anges av ESRI till följande (lägsta krav):

Processor: Pentium, 800 MHz minimum, 1GHz rekommenderad.

Ramminne: 256 MB minimum, 512 MB rekommenderad.

Ytterligare systemkrav för Network Analyst har ej hittats dokumenterad. Uppsättning av topologiskt nätverk och ruttberäkningar är dock resurskrävande och för att få en god arbetsmiljö har följande arbetsstation använts under arbetets gång:

Processor: Pentium 4, 3GHz

Ramminne: 1 GB

I

Bilaga F

F Objektmodeller – ESRI ArcGIS 9.0

Valda delar av objektmodellen för geodatabasen i ESRI ArcGIS 9.0

Objektmodellerna är angivna i UML.

Del av objektmodell för geometrin.

I

Bilaga F

Del av objektmodell för lagringsstrukturen.

Del av objektmodell för topologin.

II

Bilaga G

G Beskrivning av svängobjektklassen i ArcGIS geodatabas

.

.

. Fortsätter på samma sätt det antal kanter man som användare anger för en given klass. Tabellen hämtad från ArcGIS 9 Desktop Help.

I

Bilaga H

H Exempel på upptagningsområde (Service Area)

Vy som visar funktionen för beräkning av upptagningsområde i ArcGIS Network Analyst. Källa: <http://www.esri.com/software/arcgis/extensions/networkanalyst/graphics/service-area-lg.jpg>

I

Bilaga I

I Valt geografiskt område i fallet Falköping

Det geografiska område som användes för utsnitt av transportnätverk i samband med ruttberäkningar i Falköpings kommun.

I

Bilaga J

J Exempel på utdatafil från ruttberäkning

Exempel på utdatafil från en ruttberäkning i ArcGIS 9.1, Network Analyst. Observera att denna fil är exporterad till Excel och ett visst urval av fält (kolumner) har gjorts, dvs det finns ytterligare fält att tillgå i resultatet.

I