INOM TEKNIKOMRÅDETEXAMENSARBETE CIVIL ENGINEERING AND URBAN MANAGEMENTOCH HUVUDOMRÅDETTHE BUILT ENVIRONMENT,AVANCERAD NIVÅ, 30 HP

, STOCKHOLM SVERIGE 2019

Change And Version Management Of Transport Network Data Between Different Database Models

Case Study On The Swedish National Road Database

JOSEFINE JONSSON

KTHSCHOOL OF ARCHITECTURE AND THE BUILT ENVIRONMENT

Abstract

The Swedish Road Administration wants to compile all the national road database datafrom The Swedish Mapping, Cadastral and Land Registration Authority using aGeographical Information System compiler in order to increase the efficiency of data flowbetween their respective databases. The objective of this master’s thesis has been to build asoftware solution containing changed private road data input from The Swedish Mapping,Cadastral and Land Registration Authority and processing it into the OpenTNF standardformat. This would enable automatic processing and of private road data to the nationalroad database at the Swedish Road Administration.

The work is divided into four parts; 1. Researching standards for databases and versioncontrol. 2. Plan the methodology using different resources. 3. Development of a softwaresolution. 4. Analysis. The chosen software is FME by Safe Software. A number ofshortcomings such as lack of information on the practical input for the future ANDAsystem were discovered, therefor some assumptions and simplifications had to be made.Using the assumptions and examples, a functioning solution was created according to theOpenTNF and INSPIRE standards. The examples to fills that gap in knowledge andprovide a greater understanding of the usage of the INSPIRE and OpenTNF standards fortransport networks.

An analysis and a discussion about the existing solution, bottlenecks, faults with theexisting database and version management between the databases related to found researchis presented. Workflows on different examples for the software solution can be seen in theresults. The national road database suffers from low implementation rate and creates issuesfor making new applications and the ability to adapt to ever-changing nature of planning.Creating a software for automatic update on network data is crucial for the Swedish RoadAdministration for implementing technologies that are dependent on frequent updates, suchas self-driving vehicles.

Keywords: FME, DBMS, GIS, NVDB, Transport Network, Database Model, OpenTNF

Sammanfattning

Trafikverket vill hantera vägdata från Lantmäteriet som ska in i den nationellavägdatabasen med en Geografisk Informationssystems lösning. Det skulle förbättraeffektiviteten i datautbyte mellan de två vägdatabaserna. Uppgiften för master projektet äratt konstruera en mjukvara som automatiskt kan ta de förändrade privata vägarna somkommer från Lantmäteriet och skriva de enligt OpenTNF standardformat. Detta för attkunna skicka all förändringsdata till den nationella vägdatabasen hos Trafikverket föruppdatering.

Arbetet är fördelat I fyra delar; 1. Undersökningar om standarder för databaser ochversions kontroll. 2. Planera metodologin genom att använda olika resurser. 3. Utveckla enmjukvarulösning. 4. Utföra analys. Valet av mjukvara är FME av Safe Software, då det ärden utpekade produkten för Trafikverket. Flera brister upptäcktes under utvecklingen,bland annat osäkerheter kring hur det praktiskt skulle se ut med indatat som ska vara del avden nya ANDA systemet, vars standarder och struktur redan är spikat. Antaganden ochförenklingar behövdes göras för att kunna utveckla ett funktionerande exempel av en ny,förändrad och uppdaterad väg enligt OpenTNF och INSPIRE standard. De exempel sombeskrivs i resultaten hoppas kunna fylla den information som saknas och för att fåförståelse för den praktiska användningen av INSPIRE och OpenTNF standarder förtransportnätverk.

Analys och diskussion kring den existerande lösningen, flaskhalsar och fallgropar med deexisterande databaserna och deras informationsutbyte samt versionskontroll som har hittatsunder projektet är presenterat och jämförts med forskning. Arbetsflöde och exempel på dentekniska lösningen kan ses i resultatet. Nationella vägdatabasen har en lågimplementeringsgrad och skapar därmed problem när nya applikationer ska skapas ochmåste anpassas till den snabbt skiftande natur av urban planering. Att skapa en teknisklösning som automatiskt hanterar nätverksdata är nödvändigt när man ska implementeranya teknologier som kräver frekventa uppdateringar av data, så som tekniker försjälvkörande bilar.

AcknowledgmentsThis thesis has been taken place during 20 weeks during the spring of 2019. It is theconclusive project in the master’s programme Transport and Geoinformation Technology atthe department of Geoinformatics at the Royal Institute of Technology in Stockholm. Thework has been commissioned by the Swedish Road Administration in Stockholm.

I would like to thank the following people:

Thomas Norlin - Supervisor at Trafikverket, for support and help with NVDB.Anders Tillegård - Supervisor at Triona AB, for support and help with FME, TNE.Anders Magnusson - Colleague Trafikverket, for help with FME technical questions.Gyözö Gidofalvi - Supervisor at KTH, for commentating on my report.Yifang Ban - Examiner at KTH, for commenting on my report.

All others at Trafikverket, Lantmäteriet and Triona AB for help with various things and formaking my master’s thesis an interesting time.

Everyone else who somehow has given a helping hand.

i

Contents1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Rationale of the Research . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Scope And Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Related Work 52.1 Theories for Road Management Model . . . . . . . . . . . . . . . . . . . . 52.2 Theories for Version Management . . . . . . . . . . . . . . . . . . . . . . 202.3 Change Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Methodology 283.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 Research Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.1 Primary Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.2 Secondary Resources . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4 Choice of Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.5 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6 Overview Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.7 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Results 374.1 Requirements and Assumptions about Data Configuration for the Transport

Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 Creating New Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3 Modifying Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4 Deleting Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Discussion 46

6 Conclusions & Future Work 49

References 51

Appendix A 53

ii

List of Figures1 Bottlenecks that block transport models to be used to support integrated

strategy-making proceses (Brömmelstroet & Bertolini 2011) p.140. . . . . . 52 Some dimensions of knowledge input for transport policy implementation

(Gudmundsson 2011) p.153. . . . . . . . . . . . . . . . . . . . . . . . . . 73 The principle of road asset location using points, polylines and polygons

(Niestroj et al. 2018) p.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 A linear referencing approach of a sample road is indicates and shows the

horizontal alignment illustration of the same sample road (Niestroj et al.2018) p.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 UML class diagram: Overview of The Road Transport Networks (EuropeanCommission 2014). p.62. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Overview of the main Road Transport Network Objects (EuropeanCommission 2014). p.65. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7 Logical table describing relationship between the transport networkaccording to the OpenTNF standard (GitHub 2019) . . . . . . . . . . . . . 18

8 Logical table describing relationship between the transport network with thePort Connection add-on for Sweden (GitHub 2019) . . . . . . . . . . . . . 19

9 Flowchart of the replace file system call according to the present invention(Cary, R. W, and Guyon, R. D 1989) p.5 . . . . . . . . . . . . . . . . . . . 21

10 Comparision before and after connection of a new link, difference with orwithout the SIS port connection concept (Swedish Standards Institute 2009)p.14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

11 Topological levels example, (GitHub 2019) Page 66. . . . . . . . . . . . . 2712 Workflow data exchange between the different databases and models

between Trafikverket and Lantmäteriet . . . . . . . . . . . . . . . . . . . . 2913 Workflow data exchange between the different databases and models

between Trafikverket and Lantmäteriet . . . . . . . . . . . . . . . . . . . . 3014 Thesis procedure workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3115 Workflow describes the connected version and change transaction between

the DBMS. Lantmäteriet DBMS (green), Trafikverket DBMS (blue). . . . . 3516 Resulting workflow between readers and writers for creating a new link and

all required objects for writing into OpenTNF format. . . . . . . . . . . . . 4017 Test link (green) created in ArcMap intersecting existing transport network. 4018 The created link (orange), link sequence (green) and nodes (red) from the

test link. Note how OID for the end node matches the end_noid_oid andlink_sequence_oid in the link. . . . . . . . . . . . . . . . . . . . . . 42

19 Workflow describing the work process of changing the existing objectsinterfering with the new link. . . . . . . . . . . . . . . . . . . . . . . . . . 44

20 Result for the modified link sequence (thick green) and the two new createdlinks which was separate by the new node (red dot) . . . . . . . . . . . . . 45

iii

List of Tables1 UML-terms in an application scheme with explanations. . . . . . . . . . . 152 Data specification for OpenTNF change transaction (Triona AB 2018b). . . 253 Data specification for OpenTNF change (Triona AB 2018b). . . . . . . . . 264 Example version ID handling at modification, creation or deletion of spatial

objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Responsible parties/platforms for changes in NVDB . . . . . . . . . . . . . 36

iv

Table Of Abbreviations

DBMS Database manegement system, which aids in the storage, manipulation,querying, management, and control of data

DVCS Distributed Version Control System

ERS Electrical Road System, provides dynamic electric vehicle chargingthrough either conductive or inductive (wireless) means for varioustypes of vehicles on roads and highways.

FME Feature Manipulation Engine by Safe Software

GIS Geographic Information System, a system designed to capture, store,manipulate, analyze, manage, and present spatial or geographic data.

INSPIRE The Infrastructure for Spatial Information in Europe.

ISO The International Organization for Standardization, promotesworldwide proprietary, industrial and commercial standards.

ITS Intelligent Transportation System

Lantmäteriet The Swedish Mapping, Cadastral and Land Registration Authority

NVDB The National road database of Sweden, contains information about allnational, municipal and private roads.

OpenTNF The Open Transport Network Format

SIS The Swedish Standards Institute

TNE The Transport Network Engine by Triona AB

Trafikverket The Swedish Road Administration, is responsible for long-termplanning of the transport system for all types of traffic, as well as forbuilding, operating and maintaining public roads and railways.

UML Unified Modelling Language – object-oriented analysis and designlanguage created by the Object Management Group.

v

1 Introduction

1.1 Background

“Transport models belong to a wider family of problem structuring methods andknowledge technologies” (Gudmundsson 2011). A well-defined transport model is crucialfor digital representation which can be used for a variety of purposes, such as logistics andplanning of construction or navigation systems. Transport systems is often multi-modalwith related technologies and models that twine together (Rodrigue, J. P, and Comtois, Cand, Slack, B 2017). The transport data can span locally, nationally and internationallywith different logical views. The data model can be stored, processed, analysed anddisplayed, logically with a Geographical Information System (GIS). Four commonapplications of such model is topology, cartography, geocoding and routing. There issystems in place and standards for creating road DBMS, including a The InternationalOrganization for Standardization (ISO) standard for data quality, transport nodes andconceptual schema language among others to control how a road DBMS should beconstructed. Having a standard is important not only for exchanging information fromdifferent sources, but necessary for synchronization of data on a larger scale.

Version control is the theory of managing changes in documents and data (O’Sullivan2003). Each edit is a frame in time or revision, which is associated with a timestamp. Themanagement of different versions of a piece of information is sometimes defined asdistributed revision control. A model is rarely used by a single user on a single device butis edited and updated on a regular basis by different users and devices. Software solutionsfor version control started off with control over different versions of the same document,but modern revision tools must be able to handle large projects between parties withhundreds of thousands of files involved. If data is distributed between parties a revisioncontrol software makes it easier to handle update changes, conflicts and managementbetween different versions. Some of the frequently used revision control systems is GIT orCSV based.

The national road database of Sweden (NVDB) is maintained by the Swedish transportadministration (Trafikverket), and contains all the information about the national,municipal and private road data (Trafikverket 2018). NVDB is available for the communitywhere five thousand data deliveries is sent each year to various costumers and is the basefor other related GIS products. A delay in information exchange to and from the modelcreates a bottleneck in the system and all its connected products, not only today but

1

aggravate the possibility to introduce information that support future transport concepts.Such information and related applications include:

1. The rules of operations of vehicles speed, turn-restrictions, emission control etc. Indynamically changed geofences that may be defined in terms of road networkcomponents for intelligent flow and emission control.

2. The information about dynamically changing complex, beyond cross-sectional,transport flows i.e. common routes of different types for intelligent transportplanning and traffic management.

3. The information about communication infrastructure capabilities for InformationTechnology Solutions (ITS) and connected vehicle applications.

4. The information about Electric Road System (ERS) and electric power networkinfrastructure capacities and other attributes for electrified transportation.

Such ITS is dependent on a constant updated road database to function, also the forestindustry has information about private tractor roads in the forest, which is not included intoday’s dataset. In case of emergency such as widespread forest fires, it could be of interestto the emergency services to have access to that information. The model is connected to afamily of services and technology and needs careful planning for future expansion of thetransport model.

1.2 Rationale of the Research

A transport information model is used to create NVDB. It is maintained by the SwedishRoad Administration (Trafikverket), the Swedish Mapping, Cadastral and LandRegistration Authority (Lantmäteriet) and the forest industry. The municipalities havesynchronized system solutions between the two. Trafikverket is responsible for transportplanning and the related data is produced and transformed between several actors. The datais exchanged using several database management systems (DBMS) as well as exchangefiles of spatial entities with information about new, updated or removed road sections.Since; “Trafikverket is responsible for national roads, and Lantmäteriet only for privateroads that is outside the forest industry’s or municipalities field of responsibility”, (Norlin2019) Trafikverket relies on Lantmäteriet to create road entities from orthophotos totransmit and to connect the private roads in the correct context and same notation asNVDB. This information exchange is sent and manually reconfigured and verified to fit thetransport model for NVDB. This data exchange is slow, and a great number of manualwork is needed which creates a delay up to four months between the updates as well as

2

non-synchronous versions between the DBMS.

A new software solution will complement the existing software which is used to check inand verify the data, this is called the ANDA solution (Triona AB 2018a). ANDA is atechnical solution at Trafikverket which ACANDO in partnership with Triona AB isresponsible for. The solution has been created as a solution to handle traffic network. Thesolution has been developed with help of Transport Network Engine (TNE) and Trimble’sproduct Novapoint DCM which handles management of traffic networks. TNE is currentlyused however the new ANDA solution is not yet running.

“Today the update data is sent using the Extended Marking Language (XML)”, (Norlin2019) but the new solution that will be operational approximately autumn of 2019 will usethe Open Transport Network Format (OpenTNF ) for the update of data to NVDB. Themunicipalities will still use ISO XML for exchange of data. An investigation is underprocess at Lantmäteriet of how such a solution for the exchange process and automationshould look like. This thesis aims to improve of the NVDB model’s data exchange withOpenTNF. It allows for more effective data flow and takes advantage of relatedtechnologies, GIS solutions and experience to do so.

1.3 Aim

The purpose of this thesis is to research the standards and technology of a road DBMSrelevant to NVDB. More concretely, the thesis has three objectives. The first objective is toprovide research about the current standards and an in-depth analysis of versionmanagement software and data exchange with focus on transport networks. The secondobjective is to compare theories and research with NVDB and apply knowledge to thedevelopment of a software solution. Finally, if possible, the third objective is to provide asoftware solution which will dramatically decrease the time between updates of the roadnetwork and information in NVDB. The specific objectives are:

• Framing research questions to fill the gaps in the research area. Using the case studyto answer the research questions.

• Extracting factors from theories and standards of road network DBMS which can becompared to the national road database.

• Creating an automatic software solution using research theories to improve effectivedataflow between Trafikverket and Lantmäteriet.

3

1.4 Scope And Limitations

The standards of transport management systems as well as version control is the focus ofthis thesis. There are other technologies for versions between different kinds of data, butfocus will be held on GIS with special focus on transport network. To apply a softwaresolution for the update between Lantmäteriet and Trafikverket, a deeper understanding of thecurrent version management and change transaction of spatial data is crucial, and thereforthe research will have focus on those two main concepts. The transport network standardsand logical schemas will be those valid inside of the European union as well as the Swedishdata standards for such data networks.

1.5 Outline

These challenges will be approached in four main steps in this thesis. The first step is tofurther research the knowledge and technology for creating a transport managementsystem. This centres around literature research as well as standards already used in Swedenand European Union. The general theories about transport models and its fall pits. In thesecond step an investigation of version management between DBMS will be made, as wellas research of current solutions and theories to solve an overlap in spatial versions. A fewselected software or technical solutions will be compared with each other. In the third stepan effort will be made to use the researched technology for the case study at Trafikverket.The change transaction is as of today made automatically and uses XML, however updateswhich is sent with Shapefiles needs manual handling to be delivered from Lantmäteriet. Aneffort will be made to automate the change transaction between Lantmäteriet andTrafikverket using the Feature Manipulation Engine (FME) by Safe software, which is thestandard GIS processing software at Trafikverket. Using interviews, communicationbetween the involved parties and available information about the model, evaluation andanalysis will be made. The goal is not to provide a step-by-step guide or only presenttheories, but to connect a workflow and theories to pinpoint the problem that will occurwhen applying new modified or deleted roads from one system to another. The fourth stepand final step is to discuss the research and methodological challenges involved, using theprevious steps. The purpose of these steps is to offer terms and understanding to the gapbetween modelling technologies and planning needs. With general research knowledge thepredefined problem can extend beyond the practical application.

4

2 Related Work

2.1 Theories for Road Management Model

The need for a road network system has gone from predict and provide to provide andprevent (Brömmelstroet & Bertolini 2011). The research made by Brömmelstroet et.alpinpoints the role of transport models in urban planning and the oversights often madewhen planning for the future of a transport model. One of the many issues is described assuffering from low implementation rate. Several applications as of today created by bothacademia and consultants is not fit for the ever-changing nature of daily planning. As wellas applications cannot be made based on the construct of such models. This is of interestnot only to planners in general, but also especially to the case study where a model who isconstricted cannot easily support future application if the accessible knowledge is notusable. A immense survey was made among Dutch land use and transport planning wherethey believe the main issues is and why they could not support their planning processes, seeFigure 1 The top three answers in the transport category by the approached where that thetransport model was; not transparent enough, had low communication value and is not userfriendly. It is also stated that the synergy is not independent but is also affected by land usemodelling. Some highlights and findings where summarized in the article at a seminar heldafter the survey:

Figure 1: Bottlenecks that block transport models to be used to supportintegrated strategy-making proceses (Brömmelstroet & Bertolini 2011) p.140.

5

• Planning practitioners acknowledge the potential of transport models, but they need tobetter support the learning process of its users to better realize their applications andideas. That learning comes from making rather than using the model.

• If the model itself is not understood by many, it will not be used and trusted. Toengage people and improve of the low communication value the model needs to belinked to the language that they speak, especially when it’s not used by insiders in themodelling community.

• To find solutions we need to test interventions is experiences and compare them withdifferent groups, to increase transparency and flexibility in the system.

Another article by Gudmundsson, (Gudmundsson 2011), the knowledge and technology ofplanning is discussed, with focus on the gap between modelling efforts and planning needs.Knowledge as well as concepts and findings about the knowledge use is also presented. Tooutput results from a traffic model, the data must be validated, calibrated and verified. Themain technology is tools’ ability to deliver the facts, while the second hand is the factsitself. This does not mean that facts should be disregarded, but the application,transmission and utilization of facts should be open minded and socially constructed.Supporting tools and the role of the data should be defined in the platforms used. Theprimary use for a model is for problem solving, in the categories of instrumental(applying), conceptual (using) and symbolic (legitimate) usage.

The general typology for transport technology with regard to its dimensions is described inFigure 2. There any many types of transport models that have various performance andfunctionality, but a typical cause of inadequate results and failed connections is associatedwith a failed connection between the context and the content. The key to an effective modelis to minimize the gaps and match the procedure and application. What happens if thecontext change? The issue is the same as mentioned in the article by Brömmelstroet,(Brömmelstroet & Bertolini 2011), if a model is stable it leaves little room for newimplications and changes. New policies, issues and agendas can emerge and shift therequirements for a data model. This is of interest not only to all planners but also to thecase study where it has already been mentioned to integrate new tractor roads to the currenttransport model, as well as future ERS.

In the article the Stockholm Charging Trial is used as an example of a new implementedpolicy. The Stockholm congestion charging trial is a system that was implemented in 2006where the registration of the numbers of cars where scanned and sent to a database where

6

Figure 2: Some dimensions of knowledge input for transport policyimplementation (Gudmundsson 2011) p.153.

the registration number is matched to the car owner and a charging fee is added. The newpolicy needed storage, a new web portal, tax decision software, transaction score, detailedtransaction database among others to be implemented. In the example it is made clear thaturbanisation and growth in road usage, the economic trends, pressures the need for newpolicy trends. The project included over fourteen nationalities and four thousand people tomake the design and implementation possible (IBM corporation 2006).

The Stockholm Charging trial is a success and met with a positive response and became apermanent policy (Gudmundsson 2011). The example is compared with a less successfultrial to make the same policy in 1997, where the infrastructure fell apart. The simulationmodels and the content were well made, and the model chosen was a SAMPERS-4 stagemodel system from a consultant bureau, a forecasting model for personal transport. Thereason it fell apart is that the context did not match the content, the use of an independentnon-governmental organization is a political no-go and lead to an official termination of theproject. The 2006 example is believed to be a success because the model provided thesolution top-down but allowed the actors to operate at a bottom-up approach. The finalconclusions made in the article is that we can study, describe, categorize and analyse aknowledge, but the influence of collective needs, interactions and the planning context indifferent levels makes the model design more complex and profound. It grows frominteraction on an individual, interpersonal and collective level. It is maybe more importantto look at a model’s effect than its direct results. Connection between reality and model ispossibly the greatest challenge.

7

Figure 3: The principle of road asset location using points, polylines andpolygons (Niestroj et al. 2018) p.2

The issue of connecting models and reality, is described and tested in an Australia article,as well as comparing software solutions and data format standards (Niestroj et al. 2018).Transport network standards presented are; the European standard INSPIRE TransportNetwork, ISO, Inframodel (Finnish) and OKSTRA (German) among others, and mentionsthat none of them have one data specification standard. This makes communicationbetween these standards challenging as well as transition of legacy data within an update.Outcome of projects is described as standard specifications but has no implementation withworking examples to read data-sets. It is challenging to find a network model exchangeprocess that is available.

The paper summarizes more in detail available standards and software for road assetexchange. They also describe three different ways a location of a road can be described,which can be seen in Figure 3. It is the three standards used within national transportagencies in Australia to describe spatial objects such as roads, bridges, fences. The left onedescribes a point which has an offset that is relative to the centerline of the road. Themiddle uses the polyline approach where the location is relative to the start and end point ofthe line as well as the length between the points. Both left and middle contains informationabout which roadside the object is referred to. Right image uses polygon representation,which is described as being used for tunnel or bridge objects with and start and end point.A common approach is using linear referencing between start and end point, see Figure 4.It contains attributes such as reference link, start point, end point, lane number, pavementand condition among others. The kilometer points is the referencing points along thenetwork. It is described as easier to make lane changes using the linear reference model,

8

Figure 4: A linear referencing approach of a sample road is indicates andshows the horizontal alignment illustration of the same sample road (Niestrojet al. 2018) p.3

since adjusting the number of lanes depend of the available information in the dataset.NVDB and the ISO standard uses similar notation where attributes is described withreferencing schemas.

The article also makes an overview of the mentioned standard, such as The Infrastructurefor Spatial Information in Europe (INSPIRE) and OpenTNF, which is the key standardsmentioned as well as SIS standards. They use different software for a case study wherethey solve a given case using different data formats and using three different software tosolving the case; FME, Novapoint and TNE.

ISO – The International Standard Organization. There is no specific standard for roadnetworks, however the SIS standard is heavily influenced by the ISO standard, since theyfollow the ISO standard 19131 and related standard for metadata, conceptual schemas,quality principles and spatial schemas among others when creating a geographicaldatabase. It is outside the scope of this thesis to go inside detail about every single notationused, however it is of interest to look into the associative rules for understanding versionmanagement. In the 19131 standard the Unified Modeling Language code (UML) describeshow to interpret different rules and relational notations, (Swedish Standards Institute 2008).The UML-code is the same as the one used in the SIS standard, see Table 1.

INSPIRE – The infrastructure for spatial information in Europe. Focus on development fornetwork model in the European Union (European Commission 2014). Enables publicaccess to spatial information between public and private sectors. It contains spatialstandards for addresses, coordinate reference and transport networks among others. It

9

enables data exchange between road, rail, air and water transportation networks. Adirective states that all European countries shall follow the same standard informationmodel for transport databases. Common spatial elements share the same subthemes such asroad, rail, cable, water and air. Many of the common transport elements is represented inthe network as nodes, links, aggregated links, areas and points. Transport property classcan be applied to the whole network element or the associated linear features. The primaryaspects of the transport network elements are:

• Spatial – Geometric (line, point, area) – representation of elements in the network.The network is handled as connected elements such and links (line) and nodes (points)at the end of the links. Other points and areas with a function can be represented inthe dataset.

• Temporal – All elements can have temporal validity. Added information about whenthe data is added, modified, deleted or during which period it is valid.

• Thematic – Depending on subtheme, some nodes, links or areas can be classified withvarious attributes to common subthemes or special property types.

Inspire uses the linear network with a link and node structure, as seen and described inSection 2.2 and Figure 10. The full UML class diagram Overview of The Road TransportNetworks for INSPIRE specification document can be seen in Figure 5and described inTable 1. UML is used as the modeling language (OMG). UML is in itself very general andcan be used for many types of modeling. In this information model UML is used accordingto standard (ISO/TC211 - ISO/TS 19103). It describes properties and mechanisms forintermodal connections.

A class is a description of a number of objects which assigns attributes, relations,operations and restrictions. Attributes is the descriptive characteristics for an object, suchas name, type, length etc. The class diagram describes relations between classes. There isdifferent kinds of relations such as:

1. Inheritance which is described with an empty arrow. All attributes are inherited fromthe superclass which the subclass inherits from. The logical semantic description isan object of a subclass “is a” of the superclass.

2. Association which is described with a line. It is easy finding an object of a classgoing to an object of the other class. Example an employee is hired by a company, thecompany is the employer of one or many employees.

10

3. Aggregation which is described with a line and diamond shape. It is a stronger versionof association. It is not used the transport network schema.

Constrain complements to a model to state what is formally allowed or possible ways ofusing the model. A package contains classes for a basic network structure, independent oftraffic type. It includes topological, geometrical al temporal aspects.

In the case of transport network, the class diagram or application schema employs a linkand node structure to represent a road system used for transportation of vehicles on a linearnetwork. The schema inherits classes from the common transport schema and creates itsown classes to describes properties of the road network such as Ownership and trafficdirection that can apply to whole sections of the network element or subsections that can bedescribed using linear referencing. Network aspects described for the elements is spatial,temporal and thematic. Consistency between spatial datasets, identifiers management andmodelling of reference objects requirements, recommendations and feature catalogue islisted in the INSPIRE specification.

The consistency between spatial data objects is divided into three areas; the coherencebetween spatial objects of the same theme and detail level, objects within the same area,and the ones at state boundaries. For transport objects there is two alternate forms ofrepresentation; physical topographic object in an area which has high accuracy, andcenterline representation that is an approximation of the centreline, see Figure 3 forreference. One hard requirement is the theme specific requirement for consistency betweenspatial data sets:

11

"Transport network centerline representation and nodes shall always belocated within the extent of the area representation of the same object"- (European Commission 2014) (p 43).

General guideline is that objects within the network should be positional consistent withother spatial objects, such as the extent of forest and buildings. The consistency betweenstate borders is of interest to the municipalities, where some municipalities in Sweden isgenerating their own network data and delivering them to Trafikverket, while in some othercases Lantmäteriet handles them (Norlin 2019). Usually it is done by linking a networkelement at each side of the country border, and defining where and how each elementbegins. An overview to understand the schema can be seen in Figure 6. This is the standardused by Trafikverket, some attributes and schemas such as the metadata uses the ISOstandard notation for description of metadata (European Commission 2014). The NVDBgeodatabase follows this standard, and a full feature list is available in the document.

SIS - The Swedish standards institute has a described standard for how road and railwayshould be described (Swedish Standards Institute 2009), the standard was developed in1996 when only national standards was of interest and was developed by SIS. This is theused standard for NVDB and other network databases in Sweden. The guidelines for theapplication scheme can be seen in Table 1. A net element consists of nodes, referencenodes and edges. It is described in OpenTNF as well which follows the INSPIRE standardbut with a few modifications, the added element is the port connection, which can be seenin Figure 8. It is built upon the INSPIRE standard but is more extensive.

OpenTNF - The Open Transport Network Format. Specifies and describes classes that canbe implemented as data in a relational database (Niestroj et al. 2018). OpenTNF specifiesexchange for large transport networks. OpenTNF is based from INSPIRE’s dataspecification of transport networks, to and from national databases. It contains informationsuch as transport property types, linear referencing, geometry, attributes and metadataaccording to the ISO 19139 standard. OpenTNF is the chosen data standard with theANDA solution, and is well explained but there is no data examples available to implementor try the concept.

12

Figure 5: UML class diagram: Overview of The Road Transport Networks(European Commission 2014). p.62.

13

Figure 6: Overview of the main Road Transport Network Objects (EuropeanCommission 2014). p.65.

The objects have globally unique IDs as well as lifespan that is changed. Data is needed toinstantiate the two objects. The gid, globally unique ID for the object can be generatedcentrally, after check-in inside of NVDB, or directly at the source when an object is createdor changed externally (Trafikverket 2012). Central check-in means that it is generatedcentrally when it is delivered, the generated gids must therefore be sent back to thedeliverer with preliminary identities. The evaluation by Trafikverket is that this method is acostly and a vulnerable solution. Local generation, inside of the work database, isconsidered better, since the object can easily be checked in with its own unique identity, itis evaluated to be cheaper more effective and less vulnerable. Therefor in NVDB theprovider of new spatial entities must contain a unique ID at delivery. The gid follows theobject at all time, and the version ID is changed at modifications. This is to make sure thatmultiple versions of the same object can occur at the same time. In the case of severalproviders modifying and changing the same object, a new gid is created before check-inas well. At modification a new gid and vid is created to insure there will be no versioncontrol conflicts.

14

Table 1: UML-terms in an application scheme with explanations.

UML-term UML-symbol Explanation Swedish TermClass Diagram Schema with associations between

classesKlass

Class Approximate object-type. Same as Entityin the STEP model.

Klassdiagram

Superclass This class is a generalization that thesubclass inherits from.

Basclass

Subclass Specialization of a base-class. Inheritsattributes from the base-class.

Subclass

«Abstract» Sets that the class can’t have incidence. Abstakt

Package Group of associated model objects. Paket

Attribute Attributes for a class. If multiplicity isnot denoted it will be set to 1.

Attribut

Association Connection between classes. Association

Aggregation Association that mean "consisting of" Aggregering

Inheritance Specialization. The subclass inherits thegeneral class’ attributes.

Arv

Object Existence from one class. Objekt

Constrain Limitations of behavior of a class. Isexpressed using OCL

Restriktion

«Enumeration» Class that defined allowed discreteattribute values.

Uppräkningstyp

«DataType» Class that defines a structured datatype. Datatyp

15

The network data model needs a linear referencing method for which the lengthmeasurement of every link sequence is calculated from (GitHub 2019). This is based off anISO standard. Identifiers and attributes is according to the INSPIRE specifications. Theimportant elements is the mechanism that binds the transport elements together. Theseneeds to be properly described to work:

• The relationship between Nodes (Nod) Links (Referenslänkdel) and Link Sequences(Referenslänk) in the network model.

• Mechanism for cross border connections

• Collection of network elements in a transport network.

Measurements is made using linear referencing between nodes along the geometry of thelinks see Figures 10 and 4. The referend kilometre point starts where the start node isconnected to the link. The link can have attributes such as speed limit, condition or typeroad, rail or airway. The port connection is described in Figure 10. There they difference isdescribed for the linear referencing. Without the port connection new kilometre pointvalues has to be calculated since the measurement reference and link is no longer valid.When using a port connection, the original link is not split and measurements for referenceobject is not altered.

The whole network model for an OpenTNF file based on the INSPIRE UML schema canbe seen in Figure 7. A TNF_Link_Sequence is a linear spatial object composed of anordered collection of transport link that forms a continuous path in the transport networkwithout any branches. A link sequence has a defined beginning and end. The geographicalextent stays intact over time even if connected road sections is added or road section isterminated, this makes it very suitable as a target for linear referencing.

A TNF_Link represent a linear spatial object that describes geometry and connectivity ofa transport network between two points. It can function as a linear element fromTNF_LinearElementRef.

A TNF_Node represents a point spatial object which is used for connectivity. Nodes isfound at either end of a transport link.

The TNF_network represents a collection of network elements belonging to the sametype of transport. Separate type of transport included in the OpenTNF overview are: road,

16

rail, water, cable or air transport. Modes can be defined, such as public or private transport.A network element can belong to zero, one or many networks.

The TNF_network_connection represents a logical connection between two or morenetwork elements in different network (different class), example a tunnel between a roadunder a railway, or road to ferry connection. TheTNF_network_element_in_connection represents one connection between anetwork connection and a network element. The TNF_NetworkElementRef is similar,but represents exactly one reference to a link, link sequence or node. TheTNF_LinearElementRef is used to represent exactly one reference to a link or linksequence. Some elements is described as optional, but it is recommended that the use oftopology is consequent in a dataset. It closely resembles the UML schema for inspire inFigure 6, as well as some graphical representation of elements described in previousparagraph, but here the attributes and primary keys is included. Service area is alsorepresented with polygons which for example can represent a tunnel connection extentoverlapping one or many elements in the network. The links connect together via nodes,and creates a link sequence. The UML coding is made using XML to representcharacteristics of objects. The XML code for creating an OpenTNF file is open andavailable on their website. In the SIS standard an add-on is added to the network calledport, it determines the link between different segments of a road when they are on differentlevels, the difference can be seen in Figure 10. When e.g. a highway where there ismultiple levels of the same road sequence in large highway intersections and slip roads. Anew concept is made on the basic INSPIRE standard that is an addition to the Swedishstandard only, see Figure 8. This can be an issue especially when making intra-modelconnection to neighbouring countries which follows the INSPIRE model or havemodifications of their own. The link sequence is usually altered, and every node changedwhen a new road is added, instead the original connection is preserved, but a port is madealong the link sequence where a new node can be added. In the node and link sequence anattribute is added called “next free port number” which gives information of how manyports is connected to a node or link sequence. The port connection is a non geometry objectwhich defines where on a link sequence a node is situated.

From the SIS institute one can see a graphical representation of a port connection when anew road is added to the system (Swedish Standards Institute 2009). When a new node isadded it must be connected to an existing road, see Figure 10. The old node is removed anda new node is connected along the edge of the old node. If a reference link is used theoriginal reference link is not removed, only a new reference is added to the existing edge

17

Figure 7: Logical table describing relationship between the transport networkaccording to the OpenTNF standard (GitHub 2019)

18

Figure 8: Logical table describing relationship between the transport networkwith the Port Connection add-on for Sweden (GitHub 2019)

where the new node is connected. From left to right one can see the before after change tothe network using the two different principles for how to add a new link to the networkmodel. The bottom concept is called the port-concept, not included in the INSPIREstandard but in the SIS the port connection is added. In this way the original linkmeasurement does not have to be recalculated and will not be deleted. With a traditionalsystem one can build a new link sequence and the original seize to exist. New relations and

19

measurements for the links needs to be recalculated. Trafikverket uses reference linksequences, can contain one or several link sequences, where new nodes are added but doesnot change positions for original objects. The class feature type is a link (edge) and areference link (reflinkpart). All positions along the link must be interpolated between aspecific start and end value. By definitions the link will appear and disappear when newlinks is connected and therefor is described and more volatile and the conclusion is madethat the node/link method is a less suitable for connecting features to the network.

An example dataset is available at the GitHub OpenTNF website, with a Norwegian andSwedish road dataset (GitHub 2019). Note that NVDB is called the Swedish National RoadDatabase (NRDB) there and GeoPackage OpenTNF format data for a small area isavailable.

2.2 Theories for Version Management

There is more general research on how to solve the version management problem, amongothers there is a US patent by Richard W. Cary, Los Gatos; Richard D. Guyon (Cary, R. W,and Guyon, R. D 1989) describes the version management system between two versions offiles. Since there is no automated transfer in place today for OpenTNF only XML atTrafikverket, this patent includes methods and workflows on how to store and process firstand second versions of a given data set. In the patent the basics is described for twoversions of the same data. Write access in the sync progress relate to a version of the set.First both versions need to be controlled and cleared. Then the source version is stored in atemporary file. After a transfer is complete, the source version is tested and then set to thetemporary version. The temporary version is renamed, and the original is removed. Theflowchart for such a process is already defined and can be seen in Figure 9. This patent canbe of interest when programming the reconfiguration of the change transaction file,although the definition for the product is already specified, but not the reconfigurationprocess. The nature of data objects and developing requirements for version control in thelong term is described and generalized in an article by the Hewlett-Packard Laboratories inCalifornia (Beech & Mahbod 1988). Even thou the article is dated, the concepts is meant tobe described beyond the latest tools, as they describe themselves and gives context towhichever technical design is used as well as many generic references. The relationshipbetween versioned objects in different referencing types is explored as well as descriptionof implementation of some concepts. The examples in the paper uses Computer assistedSoftware Engineering (CASE) as well as Revision Control Systems (RCS). Some insight isgiven that the end product, for example is this case NVDB, is only one view of the

20

Figure 9: Flowchart of the replace file system callaccording to the present invention (Cary, R. W, and Guyon,R. D 1989) p.5

database. Commercial applications may suffer when the current data is only stored in oneway. In design environments many designs may be implemented simultaneously before afinal design arrive. Here comes the need for a well-designed RCS that will deal with thedesign in an effective way and with large variations in the dataset. Parts of the technicaldesign is how to handle creation, referencing, causation and environment of a RCS system.The requirements and verbatim is defines as:

Creation: the RCS must allow creation of an object version, as well as support the objectimplicitly and explicitly. The object must be identifiable and versioned even if it is not

21

specified when it is created.

Referencing: the versions of an object must be able to be referenced according to somepre-specified criteria. A software may reference it according to an algorithmic scheme, orbe loosely referenced to a generic sort model. Defining and saving criteria for suchrelationship should be easily accessible to the designer that work with the system.

Causation: creations and referencing may need to cause other actions. Creation of a newversion maybe needs to send a notification to the developer, so when he is using a previousversion it may cause invalidation of the objects if they are updated or overwritten.

Environment: The RCS is a cooperative system. Therefore, it needs well-definedmechanisms for transactions, accessibility and privileges to objects within the DBMS. TheDBMS needs to support querying so such objects can be found and information aboutaccessibility and privileges for that object.

Examples of usage is described theoretically and with OSQL examples in the article.Where they describe a generic model with compilers and types and subtypes for employeeobjects with name, department and id. Even thou it is only two version instances,conclusions is made marking how important it is to maintain a generic reference so thatbugs can be taking care of and a timeline of improvements can be tracked. Not only is thegeneric version of the model important but also the model structure. It is helpful to keeptrack of predecessor and successor between versions of the model itself as it evolves withtime. The creation in the case study is the created private roads at Lantmäteriet. Thereferencing and relationships is based upon the existing objects in NVDB and the onesdescribed in OpenTNF.Causation is when the objects is ready to be validated in the TNE check-in. Environmentcan be TNE but also the platform of which the data is transformed into OpenTNF.

The Transport Network Engine (TNE) is a platform that supports chains of transportmanagement and network management information and assets (Triona AB 2018b). TNEsupports database storage, data validation and offer interface with supported databases suchas Microsoft SQL server, Oracle and PostgreSQL. TNE is based on standards INSPIREand ISO19100, as well as the SIS standard for road and railway transport network. Datacan be stored and various standards with GIS applications for platforms such a Oracle,SQL Server, Postgre and used by QGIS, ESRI ArcGIS, Safe Software FME and TrimbleTransport Network Toolset. The XML format specification and job services for importing

22

Figure 10: Comparision before and after connection of a new link, difference withor without the SIS port connection concept (Swedish Standards Institute 2009)p.14.

and exporting data is the same as the NVDB format description specification in version 3.2.The TNE product allows data collecting and editing within an organization. It supportsdata sharing and is therefore useful in collaborative information exchange within anorganization, other benefits is security, data integrity and quality. TNE is the platform usedfor validation of new transport data at Trafikverket, which will be complemented with anew platform also by ACANDO called ANDA, which is not as of by the time of the paperyet in use. ANDA will use the OpenTNF format for check-in instead of the XML.

The Safe Software FME is much like the model builder in ESRI ArcMap (Safe Software2019). FME supports over 400 data formats and can import any GIS– data or Geodatabasefor advanced analysis and load, transform and extract operations. The great advantage withthis tool is that one need no previous coding requirements since the FME transformerlibrary is connected to each other to construct tasks. FME can also automate workflows andbe uploaded to FME Server and the tools can be run automatically at any chosen timeinterval. Some methods are asset management and planning, distribution network andmaintain of data. FME can also help to preserve data quality and saving time. By makingdata delivery seamless and supporting hundreds of data formats it is easy to reuseworkflows without changing source code. It makes sure that critical data sets and noinformation is lost while transferring data between formats. FME is the standard platformfor GIS processing at Trafikverket, other platforms such as ESRI and QGIS is also used.

23

2.3 Change Transaction

Software solutions for change transaction is commonly either GIT or CSV (ConcurrentVersions System) based. Three software solutions, or Distributed Version Control System(DVCS) that is described and examined further below is GeoGig and Mericural. Thesethree seem to be popular and not only targeted at a small audience but works for all kindsof spatial data as well as the support of large projects. ArcGIS also have theories aboutversion control and support the creation of change transaction but requires more manualwork and is not a RCS itself.

GeoGig is as previously mentioned inspired by GeoGig, but uses core concepts to handledistribution control of geospatial data (GeoGig 2019). Geogig supports Shapefiles,PostGIS and SpatialLite. Changes made in these files is tracked and can be viewedhistorically, reverted back and put in hierarchy order. GeoGig is a Java package and usesthe terminal to create repositories as well creating web API to communicate between users.GeoGig has no interactive part but is only based on java commands. One can sync versionsas well as handling merge conflicts.

Mercurial cannot host related projects together in one repository like GeoGig can. It is notpossible to check out only one directory of a repository. (O’Sullivan 2003). The focus ofMericural is more peer to peer project, one can easily copy and make changes to see theproject history. They compare themselves to another popular RCS that is called subversionthat was created to replace CVS. Mercurial has similar commands as CVS, but mercurialhas focused on performance advantages as well as tools for spatial merges. Mercurial alsosupport client editing history, which subversion does not.

In Sweden there is standards which describes how a change transaction should beconstructed, which is relevant for understanding the data requirement for such an exchange.The Swedish standards institute (SIS) have a standard SS637007 which describes how achange transaction should be made (Swedish Standards Institute 2006). In Table 2 theattributes for a change transaction is described as well as data types. Each update containsone change transaction which has many updated objects or changes. The timestamp is thesame as the one for each change. The ID of the change transfer is kept as a foreign key toassign as the change transaction ID attribute. In Table 3 describes the change of one spatialobject. Data for change type among other attributes must be included in the importinformation. The version ID is taken from NVDB as an read only, but the information ischanged in the work database before it can be written into the OpenTNF format that will

24

Table 2: Data specification for OpenTNF change transaction (Triona AB 2018b).

Column Data Type PurposeOID (pk) varchar (38) Internal unique identifier of this change

transaction, used for database references.NAME varchar (100) Descriptive name of the transaction.

CREATION_TIME DateTime A timestamp when the transaction iscreated in the database.

CREATOR varchar (32) Name of the user who created the transaction.

REMARK varchar (2000) An optional remark for transaction

contain information about all changes onto the network and then sent for check-in in TNE.

Trafikverket in cooperation with Lantmäteriet has already done an investigation on the needfor a new process for automated file exchange. It does not contain the information aboutthe theories for a change transfer, but the conceptual workflow for their model have beenevaluated as well as which filetype should be used as well as information that needs to becontained within the update (Norlin 2019). The new information is created in aphotometric system, they are delivered as Shapefiles to Trafikverket who manually fitsthem into NVDB. Not only is it manually reconfigured, but since the information isupdated using slightly different methods, some spatial entities may not align between thesystems. Because of the manual processing, an exchange cycle between Lantmäteriet andTrafikverket can take up to four months. Since Trafikverket updates the national roads, andLantmäteriet the private roads, there is a delay between the versions of the road network. Ithas been concluded to overcome this gap between versions a more frequent update must bemade, and the only way is to automate the insertion of new spatial entities using some sortof programming tool to create the updated OpenTNF file.When a new road is created, a new link is made and connected to the link sequence, it canbe connected to an existing node or a new one is created, a new node is therefor optional.OpenTNF defines the generic model and its attributes and features. The same set of classesis used for information such as speed limits and traffic signs. Every object is uniquelyidentified to enable updates, so when e.g. the speed limit is changed it may be updatedindependently of the underlying transport network. An example is given for when a speedlimit changes from 70 to 80 on the date 2011-01-01. The TNF property object contains twoinstances of the same object; (“STA”,”aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”)(“STA”,”bbbbbbbb-bbbb-bbbb- bbbb-bbbbbbbbbbbb” representing the two different states.Two carriageways are each represented by a link OID “c”, and “d”. The road level is

25

Table 3: Data specification for OpenTNF change (Triona AB 2018b).

Column Data Type PurposeOID (pk) varchar (38) ID of the changed object

CLASS_ID varchar (38) String Identifies the class object that hasbeen changed ex LINK

CHANGE_TRANSACTION_OID (fk)

varchar (38) Identifies (FK) fromTNF_CHANGE_TRANSACTION

ORDER_NUMBER Integer The sequence number for the change inthe contxt of the transaction

CHANGE_TYPE Integer 0=Comment, 1= Insert, 2=Update,3=Delete

CHANGE_REASON varchar(38) Correction = update of infoReal world = a update when real worldhas changedUnknown

TIMESTAMP DateTime The same time as its parentTNF_CHANGE_TRANSACTION’sCREATION_TIME.

OLD_VID varchar 38) (optional) previous version id of thechanged object. Rececing dataset.modification or deletion 2,3.

NEW_VID varchar(38) (optional) Next verion of the id,recivingupdate version id creation or mod 1,2

CREATOR_ID varchar(38) Name of the user who created thetransaction.

REMARK varchar(2000) An optional remark for transaction

26

represented by the link sequence “a” consisting of a link “b”. The relationship is specifiedand some attributes can be seen in Figure 11. The versions of a spatial object is definedusing a version id, at a modification there is an old (at check in) version ID and a new(check out) version ID (Swedish Standards Institute 2006). The check-out version IDbecomes the vid of the spatial object in NVDB. If the change is the creation of an object,the in version ID will be set to 0 to mark null, and if it is a delete the out version ID will beset to 0 to mark null. An quick example in Table 4. If it is a creation or modification of anobject it must generate a new version ID to be sent for check-in, and if it is a modificationor deletion the old version is does not have to be included since it is presumed to alreadyexist at the receiving end.

An article about the overview of standards for road information exchange describes the gapand solutions between the road agencies and information exchange in Australia (Niestrojet al. 2018). The exchange process is described as a lifecycle between planning,acquisition, operations and disposal. Private and government agencies is described togreatly benefit from sharing data in a more efficient way suing synchronized dataspecification and standards. The approximate cost savings is predicted to be between $65-$130 million yearly.

Figure 11: Topological levels example, (GitHub 2019) Page 66.

27

Table 4: Example version ID handling at modification, creationor deletion of spatial objects

Creation Modification Delete

object_ID 100:1 77:12 78:14old_vid 0:0 88:12 78:15new_vid 100:2 100:3 0:0

The current data standards is criticized and reviewed to deal with the challenge of dataexchange on a road network. A common data standard aids in all the stages of a roadconstruction project. The road exchange between the two parties, Australia and NewZeeland had different DBMS standards and design which slows down the continuousexchange of information between the different asset management cycles. Sharing ofinformation between systems therefore becomes difficult to process, same as for thetransition of legacy data within updates in a software environment. The versionmanagement at Trafikverket is mostly manual and the newest version of the private roads issent via an XML file. The future solution will use a OpenTNF file, which is based on GIT,there is another tool called GeoGig (GeoGig 2019). GeoGig is based from GIT but has thecore concept of managing versions of geospatial objects. Using geospatial data such asShapefiles and platforms such as PostGIS among others, the change data is tracked and canbe viewed historically. Instead of sending an OpenTNF file back and forth to make thechange transaction, this software solution can integrate changes from separate branches andresolve conflicting edits as well as synchronization along the network. This is another wayof handling version management and is relevant for understanding version handling optionsfor all sorts of DBMS. To handle an internal database from external sources is notpreferable for keeping high security protocol.

The information is included in the spatial entity, and the updated features is node, link andlink sequence. Some information is handled directly while some is reconfigured in TNEafter check in verification.

3 Methodology

3.1 Problem Definition

The suggested workflow between Lantmäteriet and Trafikverket with the new ANDAsolution is that Lantmäteriet sends a Shapefile with new private roads according to the SIS

28

standard. This is manually added to the old copy of NVDB and a change transfer via anOpenTNF file is sent to NVDB with a flag for each new road. The Shapefile is checked into the existing network and needs to be handled manually.

The problem is that the exchange cycle takes up to four months, and new road changes andupdates occur every day on both private and national roads. The changes is connectedmanually, but using the codes for nodes and links they could be programmed toautomatically connect to the network along with the information and flags that says thesection has been updated. The interface is specified and implemented for the check in ofthe OpenTNF file. When transferring the information the problem is; how shall FME writeOpenTNF when it is not directly implemented, only Geopackage. Which informationneeds to be included for the check in verification according to the defined standard? Somelevel of and integrity needs to be secured as well. The exported format is Geopackagewhich follows the OpenTNF standardization. The input can be a shapefile or a geodatabasewith new objects with description of change type, feature type among others. How willthese changes apply when writing the OpenTNF file?

Figure 12: Workflow data exchange between the different databases andmodels between Trafikverket and Lantmäteriet

29

Figure 13: Workflow data exchange between the different databases andmodels between Trafikverket and Lantmäteriet

These questions is divide into three parts, the creation, modification and deletion of anobject. Example on how this represents on a road network can be seen in Figure 13. Thework process and requirements for different kinds of changes and answers to the questionswill be covered in the results.

Link A – Deleted road (orange). A road that is no longer used. How is this deletetransaction described? Will the node and connection reference node be changed as well?What about other connected objects such as the link sequence? A road is commonly notdeleted in a database, only if it is wrongfully added. An archive had all historical spatialentities in the road network, and is defined by their valid from and to attribute. This meansthat a delete is not a removal of an object but the valid to attribute should be changed to thetransaction date (Norlin 2019). A delete in this standard is more a temporal deletion withtime validity modification information in the change transaction. The question of if allnodes and link sequence that is connected to the link that shall be removed as well is notanswered.

Link B – New road (red) that is created. How is this change transaction described? As anew link sequence or a link sequence with connected link? The new node is included in thechange transaction but how is the connected road affected? Should the reference linksequence be the same or should it be altered? The port connection states that the referenceslink, link 2, is the same but what about the attribute “next free port” should be altered in thechange transaction or is this information added at the TNE check in stage and should onlythe geometry be added?

30

Link C – Modified (black) node, where in this case a node is altered. How is thisdescribed? As a link or link sequence with a connected link? What if the road now starts ata new coordinate along the network then the node, node 3, needs to be modified as well.Ex. A road had been shortened and is now 100 m shorter than before, should the linksequence (blue) be redefined as well to the new end node of the link?

3.2 Research Strategy

In general, the strategy is a methodical approach to categorize the basis for network DBMS,version control and change transaction in the related research section. Which standardsthat is used to spatially represent a network model, and with a data gatherings strategy inorder to develop a change transaction and to link it to the final section where theory and thepractical solution meet. All the three theories, the DBMS, DVCS and change transactionis all dependable on each other. It is not typically the users’ choice since urban developersis bound to their standards and set of rules for how spatial entities should be represented.Research found in others countries where other standards is used for representing a networkmay not work for another users’ DVCS. The purpose is to compare processes of differentcontent, software and related data standards for basic assessment to be available for anyoneas well as develop a solution with example data for this case study. The goal is to developan approach according of the data quality requirements, defined standards and availablesoftware solutions to define a change of spatial data and how to write it into a OpenTNF filethat will pass the new ANDA system requirements for an update. Every part of the processis summarized in Figure 14. A bottom up approach is required at the project planning stage.

Figure 14: Thesis procedure workflow

31

Through personal communication and investigation of active platforms, the requirementsfor understanding related technologies and creating a software solution can be mapped. Theresearch is made of the standards for database management, version control and variousrelated standards. During project development the compilation uses the research made tocorrectly using notations and special definitions. In the analysis the pros and cons can becompared with various research and the information retrieved during the project planning.To provide a software solution the process of obtaining data and demands of procedures ismethodically planes with regards to the selected software and the implementation of data.

3.3 Data Collection

3.3.1 Primary Resources

The collection of data is divided into two categories. Data is collected using primary orsecondary resources. Primary sources is provided from (Norlin 2019) containing a filegeodatabase named “Josefine.gdb” containing a sample from NVDB. Another resource is ageopackage export from TNE containing data according to the OpenTNF standard that isalready checked in, used for reference for understanding how the output should look like.

3.3.2 Secondary Resources

Secondary data is all documentation officially on non-officially available informationcontaining information about UML Schemas, INSPIRE standards, ISO, SIS, TNE, FMEand OpenTNF documentation. Information about geographical databases and FME andNVDB has been achieved by personal communication with supervisors and studyingdifferent materials, example data, manuals, examples and the system itself.

3.4 Choice of Methods

The implementation of the solution of an automatic change transfer will be according to thecontext content theory by Gudmunsson (Gudmundsson 2011). The policy in this case is thestandards in place for a European network, the INSPIRE standard and the SIS standard inSweden with the added port functionality. Exactly how the FME connection should bemade will be worked out during the process, but the guideline for creating a copy andflagging the data is described in the OpenTNF and the SIS standard provided byTrafikverket, which will be the goal of recreating in the FME software. The contents are themodel assessment made by an investigation between Lantmäteriet and Trafikverket wherethe model has been assessed and the bottleneck discussed and concluded that an automatic

32

OpenTNF transfer would be an ideal way to improve the exchange time between their twoDBMS. The SIS model is assessed in detail before the actual implementation stage. Modelassessment and guidance during the ex ante implementation is provided also by supervisorThomas Norlin who has great insight into the model itself and will also provide exampledata with a base NVDB and a copy with the new private roads who needs to be updated.Anders Tillegård who is assistant supervisor is a GIS developer at Triona AB and alsoconsultant at Trafikverket is a FME specialist that will provide guidance during theimplementation stage, especially for understanding the tools and the Geopackage in FME.The ex post implementation will be assessed with Thomas Norlin as well as supervisor fornew tool implementation at Trafikverket, if the model where to be added to the flowchart ofthe DBMS exchange. The satisfaction of the model will be evaluated even if it does notpass the check-in at Trafikverket, to evaluate if the research itself or the results can be usedfor further investigation and development. The interpretations of tool results will be mainlythrough personal communication and evaluated in the results.

Since the transfer file as of today is made with an OpenTNF file transfer, and the receivingpart already has a submission control system, is the choice of change transaction type.However, as of the research in Section 2.3 that implies that it may not be the ideal choice ifmore flexibility and built in tools is preferred, OpenTNF is fitting for many Europeanstudies since it is based on the European INSPIRE standard when it comes to datadescription. It lacks functionality such as commands for automatic error control. TheOpenTNF must be rearranged in a specific way and will be inflexible since it is put into ablack control box and will pass or not in the verification step. This will be taken intoconsideration when evaluating the results. Using FME is also optional, since the modify,insert and deletion of spatial objects between databases can be made with Python, SQL orother similar programming tools as well.

To start off a few simple tests is made as checking in the removal of a single road andexport it as an OpenTNF file change transaction. Then moving further into development todetect all road changes and transferring them into a single change transaction file. Toanswer the following question: which requirements does need to be included and how willthey be handled to be written into an OpenTNF file?

When creating and editing the OpenTNF file there is some options. It can be made usingany of the three tools mentioned in the research, FME; Novapoint and TNE. To write theOpenTNF file Geopackage is used, it is an open standard that can be used by both QGISand ArcGIS. The tool must detect which changes have been made a flag them accordingly

33

for connection to the road network in NVDB. As the research mentioned in (Niestroj et al.2018), many tools and software are available but often lack real example data andapplication, which is hoped to be achieved by this thesis. It will not be a step-by-stepguide, but a clear description of the data and workflows on how to transform and connectthe data will be represented. The models and figures for how a road is represented,especially in Figure 4, it is easy to understand the different attributes and values that a roadcan have, as well as how its’ real form in reality can be described using predefined criteria.It fills the gap where the users do not like a model since it is hard to understand or nottransparent enough. The data model at Trafikverket, that has an added spatialrepresentation that is the port connection, could be graphically represented in a similarmanner to improve of the learning curve for understanding and using the model in a moreeffective way. The document which describes the SIS standard with the logical schemasand description (Swedish Standards Institute 2009) takes time to understand and has manyspatial classes and references to take into consideration which makes it more difficult tocomprehend within a short time span. This is not only for the developers but for the usersas well that makes orders in the NDVB web.

3.5 Implementation

The current version of NVDB is used as a background database for which the changesis based upon. Called “Josefine.gdb” in data collection. If information about the currentversion of a spatial object is not included at the import, using the unique OID for the object(if it already exists) can be used for finding information. If not, it will be generated locally forthe spatial object, which in the related research is believed to be the most cost effective wayinstead of generating the ID after check-in or at the risk of finding conflict errors. In the workspace created with FME the background NVDB is used for read only (“Josefine.gdb”), aswell as the new information for changed objects. The changes is written to an OpenTNF fileto be sent for ANDA verification check in, which is made by the software TNE xml solution.In this case it is assumed that the information is not complete when sent from Lantmäteriet.The final solution when ANDA is in place may look very different or be implemented atLantmäteriet instead. See Figure 15, provided by (Norlin 2019) that describes the anticipateddata exchange process. Road type is a non-editable layer. It can be snapped against and fromthe TopoDB with road type (1). This is a NVDB copy (1) which is not changed but is usedas a background database, read-only, for which the changes is connected to. The changes isnot made here but is taken from the database of which NVDB is stored. Changes in NVDB(2) can be a single database or feature class in TopoDB (1). Changes NVDB is a layer thatis edited and all changes is sent to NVDB. This part (2) is the working database where new

34

Figure 15: Workflow describes the connected version andchange transaction between the DBMS. Lantmäteriet DBMS(green), Trafikverket DBMS (blue).

and changed private roads is saved. Changes are made with different storing formats, suchas ArcMap where new roads are added and geometry are changed. All changes outside themunicipalities’ responsibility is sent to NVDB (3). Changes within the responsibility of themunicipalities’ are sent to NVDB web (4). Changes in NVDB needs to be snap-able to roadtype and other roads. All edits will be stored and kept tracked of if historical data wantsto be seen in the same area. Changes to national and municipal road occur over time andeventually NVDB will be updated as well and sent to TopoDB for updated reference forthe next update cycle. The reason why this is the chosen way is that no written features ischanged directly in NVDB, and will not follow the TNE structure there. The work databaseand the change transaction are required for having control of what is written in the databaseand for quality reasons. Also, Trafikverket does not allow external editing of the databasethat is outside of the firewall for security reasons. What set of changes which is connectedto each database can be seen in Table 5. Which changes that is required to be handled bywhom is not static, but is changed when new platforms and ITS is developed.

35

Table 5: Responsible parties/platforms for changes in NVDB

Changes via theinterface in NVDB

Changes via the webinterface in NVDB

Changes that needs to besorted out in Trafikverket

New turn possibility Changed national roads Geometrical changes in turnpossibility

New private roads Changed municipal roads New road barriers

Changing roads withoutsurrounding forest

Finished national roads New Municipal Roads

Road entrance/ exit Finished municipal roads Changes in roads in forest

Geometrical turnpossibility changes(rule is moved when roadis moved)

Finished turn possibility Changes in road type (exceptsmall roads)

New road barrier Changed in road type Changes of small road type

New Municipal roads Exit/Entrance

Changes in small roads roadtype

36

3.6 Overview Databases

The “Josefine.gdb” or “Read-only” database is used for whenever trying to find alreadyexisting objects, their oid, geometry or for other intersecting or overlapping purposes. Thegeopackage export from TNE is used to create all writer/export schemas according to theOpenTNF standard. Instead of creating the writers in FME manually, the can be createdautomatically using the TNE geopackage as import for all schemas in the database. Theschemas used in the examples is the tne_node, tne_link_sequnce, tne_link,tne_change and tne_change_ transaction.

3.7 Compilation

The compilation will be made using the data from resarch and any requirements for theoutput data and format will be according to the existing documentation. If the documentationdoes not cover the conversion of tools, requirements will be defined. A test link will becreated using ArcMap intersecting the existing network. The link will be added, connectedobjects modified to cover all types of changes that can occur in the change transaction asexamples, using the software FME. The challenge is to configure the input for new, modifiedor deleted objects with the challenges defined in example cases in Section 3.1 and includeall requirements for OpenTNF export, as well as defining which those requirements are. Noinput data example is available so test links with geometry only is created with the draw andeditor tool in ArcMap to process the requirements for a new, updated and deleted links andrelated changes in the reference geodatabase. The results can be seen in Section 4.

4 Results

4.1 Requirements and Assumptions about Data Configuration for theTransport Network

After thorough research and connection between standards and meetings with differentparties at Trafikverket and Lantmäteriet some results can be listed. Note that a delete inNVDB does not mean the element is removed from the database, it still exists however it ismarked as no longer valid. At both the delivery and verification the assumptions madebased on the current XML solution for check in at NVDB are:

1. The delivery must contain the complete information about all changes relevant to achange transaction. The update needs to contain all information valid from delivery

37

and forward in time. No changes is made or altered after check in. At check-in onlythe data quality and verifications is made according to the INSPIRE data requirements.

2. One spatial occurrence is handled at check in, overlapping old reference linksequences. If a road is for example bulldozed at the last ten meters and no longerexists, a new reference link sequence should be made up to the new end-point, andthe remaining part ended in time. The original link sequence does not have to bealtered.

3. No single stand-alone node will be included as a change, only as a follow up of othercreated elements. The initial change is a polyline with information about changereason.

4. If a link is created/deleted, endpoint nodes needs to be created/deleted as well.Including related attributes, port-connections, references among other in the workdatabase.

5. When a link is added or modified, the reference link needs to be modified as well. Alink must be a part of a link sequence according to the INSPIRE data qualityrequirement.

6. If a new link is added, an overlapping link sequence needs to be created as well.

Data quality according to the OpenTNF standard (GitHub 2019), the requirements for alink sequence are:

Requirement 1. The direction of the transport link shall agree with the direction of the linksequence.Requirement 2. Every position on the transport link shall be identifiable with one singleparameter such as length.Requirement 3. The measures for a transport link belonging to a link sequence shall notoverlap the measures in any on the other transport link in the same sequence.Requirement 4. The ordered collection of links in a link sequence is defined by sortingMEASURE_FROM values in ascending order.

INSPIRE Requirement 1. Transport network centerline representation and nodes shall belocated within the extent of the area representation of the same object.

Processing Requirement 1. To insure the new links follow the same direction along thelink sequence, the start node along the link sequence must be the start node of theintersecting new link. Same applies for the end node of the reference link sequence. Wherethe intersecting new link needs to have the same end node OID as the reference link end

38

node OID.Processing Requirement 2. To insure to find overlapping nodes, links and link sequences,as a result of communication and research of the TNE data quality management, thetolerance for intersecting/overlapping objects can be set to 0.4 m. The same tolerance isused at Lantmäteriet.

4.2 Creating New Link

The resulting work flow process steps for creating a new link can be seen in Figure 16Important note is the optional fields is set to a default value of null. The vid, new vid andnetwork_id has a default value of 1, and valid_to default is 9999 if not defined. Thisis part of the optional requirements defined by OpenTNF format and comparing with theexample export data. The read-only database is used more frequently in the modification ofspatial network elements, here it is mostly included to demonstrate the need if theport_connection also is created. The read only database is important to check howmany other nodes already exist along the link _sequence for the next _free

_port attribute, but is not relevant for creation of new links. It is important to note thatnot every single case for where the new link is positioned is included in this workspace, asfor example if the link is an extension of an existing link_sequence or branches outfrom an existing node. Small modifications can be made to handle the latter case. A testinput link is created in ArcMap intersecting the existing transport network(“Josefine.gdb”). The test new link is used as input in the created FME program and can beseen in Figure 17. Firstly, a change _transaction is created, only once in a separateworkspace when a change transaction of changed objects is initiated (step 1). Parameterscontaining information about remarks and creator name is assumed to be included in theimport. The fields is set according to Table 2. A datetime stamper sets thecreation_time and a GUID generator gives the change transaction an unique ID, andis now ready to be written as OpenTNF. In accordance to Table 3 a change must include theID of which the change is a part of, as well have the same DateTime as thechange_transaction, and is therefore exported as a parameter. A new node is createdat Lantmäteriet. All information about the speed etc. is not included in this example, butonly the geometry and focus on the relationship between links, nodes and link sequences.For simplicity and time constraint the port connection is not included in this part.

In an attempt to add a road section, the geometry of the object is added into the workflow.The necessary attribute fields is created according to the OpenTNF standard (step 2) asdescribed in Figure 8. Since this is creation of an object and it belongs to the transport

39

Figure 16: Resulting workflow between readers and writers for creating a newlink and all required objects for writing into OpenTNF format.

Figure 17: Test link (green) created in ArcMap intersectingexisting transport network.

40

network, the version_id and network_oid is set to default value 1. To receive theunique OID for the link_sequence object a GUID generator is used and set to the OIDof the new link_sequence. The next_free_port_number is the same as theamount of intersecting other links crossing the object. Using the read _only database,if a port is added, in this case called the “Josefine.gdb” is used for counting the number ofintersecting objects and value can be set. Now the link_sequence is done according tothe OpenTNF standard and can be sent to the writer (step 3).

To be able to handle multiple features in (step 2) the links is given a temporary ID number(not visible in the figure) so when the assembly is done it can be grouped by that IDnumber so nodes is not by accident merged for multiple features. For every link everythingis handled for individual feature but to insure multiple features when they are assembledtogether all link sequences and nodes is temporary tagged with the ID of which originallink they belonged to. This means as an input we do not need a single feature input but canhave a Shapefile full with new links to be processed by this workspace. Since a linksequence overlaps the link completely in accordance with the INSPIRE Requirement 1, acopy is made of the link_sequence and new fields is created according to the standardtable for a link. None defined fields is set to null in accordance to the example export datafrom the TNE database. Now when the link_sequence is created thelink_sequence OID can also be set for the link as a foreign key. The valid_fromparameter is set to the same as the one for the change_transaction date. Valid_todefault value is 99991231 if not defined. Since it is a new link and link_sequence thatis created in this example, the link stretched along the full distance of the link sequence andis set to measured 0 to 1. A simple transformer is used to calculate the length of the link.Important to note is for some objects there is difference between the length, and Shapelength of about a tenth of a meter in difference. This information can be included in theimport of the object but it is set to the Shape length of the length measurement in meters inFME. For convenience the link_sequence is created first for easier handling of addingthe foreign keys. Now attributes from the link_sequence can be sent forward to theLink Assembly.

In the Link Assembly all information which is taken from the link, link_sequence andthe start and end node is available. Attributes can now be put together and values be set.The change transaction ID and time is also set from the change_transaction

parameters foreign keys. The foreign key of which link_sequence this link belongs toand the ID of the start and end node is included as well. The attributes is mostly mergedwith a transformer named “Aggregator”, then a “Feature Merger” to set the fields to the

41

Figure 18: The created link (orange), link sequence (green) and nodes(red) from the test link. Note how OID for the end node matches theend_noid_oid and link_sequence_oid in the link.

right attribute of the spatial object. Now the link is complete and can be written intoOpenTNF format, seen in Figure 16 (step 5).

The flags in the figure signals a change. If a spatial object is created information needs tobe written according to the OpenTNF format (flags). Information containing the name ofthe feature that is written needs to be sent, as well as change type, in this case four changes:the link, two new nodes and the new link sequence. The creation time and transaction ID isthe parameters from the change transaction workspace. Every feature sent for change, acounter need to between the input and output so for every new, modified or deleted featureneeds to be counted in order to set the order number attribute of the change. This can be setwith the FME translator “counter” before setting all field values to write the changeaccording to the OpenTNF standard.

42

The result from the translation in FME can be seen in Figure 18, using FME Inspector asimple geographical representation can be seen of the written features as well as the values.From the spatial object that has been drawn from orthophotos in Lantmäteriet, in this casea test link is now completely translated into an OpenTNF link, link sequence and two newnodes with correct annotation to be connected to NVDB. The change and port features isnot written into OpenTNF in this example.

4.3 Modifying Link

To continue on with the example of the added test node, assume a new link has been added,as in the create link example. A modification can be of many types, but in this case themodification on the connected link will be used as an example to demonstrate a modificationin the software. The new end node interacts and will change information about the referencelink of which it is connected to. The workflow for the software can be seen in Figure 19. Thenew link which is created and intersects with the intersecting network triggers a modificationchange, see Figure 20. The new node that is created will bring change. The existing linkneeds to be deleted, and two new links with new values needs to be created where thelink intersects the network, as can be seen in the workflow in Figure 19 step (1). The linksequence however, will stay intact, but two new links will overlap instead of one (2). Usingtransformer point on line overlay the link sequence will be split into new features where anobject intersects the line (step 3). To find the link, link sequence and the nodes at the endof the existing link sequence the read only database needs to be used as reference. The twonew links that is created along the link sequence will need new length measurement, andnew start end node OID values. According to the requirement 1, the start node must be thestart node of the new link (purple) on the left side as well to follow the same direction asthe original link, see Figure 20. The leftside link start node is the same as the original linkstart node, and the end node is the new nodes OID. The rightside start node is the new nodeOID and the original links end node OID. The measure from and to 0 and 1 is no longervalid, since the link sequence is no longer covered by only one link but two links. To followthe same direction, the leftside link is assigned start measure form value of 0, and the leftside is the end of the link sequence (thick green) and is assigned value 1. Using regularexpression the percentage of the measurement along the link sequence is calculated (step 4)in in Figure 19. This can be made for two or more two overlapping links on the same linksequence using FME following these steps:

1. For the line features, add measure with the MeasureGenerator and calculateentire length with the LengthCalculator.

43

Figure 19: Workflow describing the work process of changing the existingobjects interfering with the new link.

2. Then, send the points and lines to the PointOnLineOvelayer. Here, the entireline length (attribute) will be merged to points, and measure will be added to thepoints.

3. Use the MeasureExtractor to extract measure value for each output point.

4. Finally, calculate percentage based on the measure value and the entire line length.

This method is general but is valid update for any amount of links that already intersectsthe link sequence on the network. This results in every point or line alongside the totallength gets an attribute with its percentage of the total length of the link sequence as pointmeasurement. This way the measure from and to attributes can be assigned (5). Then thestart/end node OID can be assigned.

44

Figure 20: Result for the modified link sequence (thick green) and the twonew created links which was separate by the new node (red dot)

In this example as seen in Figure 20 where the new node (red dot) split the link sequenceinto two new links, the left side new link (purple) covers the link sequence (thick green)from 0 to 43 % of the total length of the link sequence. The link sequence is not modified inany way only the original overlapping.

4.4 Deleting Link

In this example from modifying link, the only element that needs to be changed is theoriginal link that covered the link sequence needs to be removed. In other words, the dateof which the modification is made the original link needs to be found, which it is in theworkflow named ref _link and the valid_to date changed to the date of themodification. After check-in information that the valid_to date is expired will removethe road from the current valid network. It will be moved to the TNE_archive.

All of the changes that occurs, the new created links, nodes, modified nodes among otherneeds to be sent to the change log workspace, so every change, modification or delete isdocumented accordingly so the information in the change transfer which objects has beenchanged and the nature of the change is all included. In this example a total of sevenchanges in order are: the new link sequence, two new nodes, new link, delete existing linkand create/modify two new links.

45

The new, modified and deleted links in this is only examples, many cases have not beencovered such as if the length of an existing link has been changed and nodes needs to bemoved or replaces. The original link in the delete example is replaced by two new, but it isanother case when an existing link is removed as well. Then the link sequence and nodesneeds to be removed as well but in these three application examples it is not covered. Theexample is used to understand what is necessary to include, as well as how to insure dataquality requirements, and to insure the output is within the INSPIRE requirements.

5 Discussion

Understanding the full technology and multi modal nature of a transport database is noeasy task, as researcher (Rodrigue, J. P, and Comtois, C and, Slack, B 2017) Jean stated atransport model is layers of related technology. NVDB is all but a small part whichcontains the information. The logical schemas, change transaction, standards and ruleswhich dictates every step of the process all comes from different standards which evolvedfrom a time where advanced processing was not available and the scope of usage was onlynational. Different requirements of collaboration with other parties and countries hasgrown over time, such as changed geofences and road network components for intelligentflow and emission control. The dynamical and complex ever-changing nature of transportflows and routes puts pressure on the capabilities of ITS. As well as ITS capability tosupport ERS and electric power network infrastructure on a European scale.

The idea of having an ISO, SIS, INSPIRE standard is of useful intentions, however thereality and practically of software solutions and DBMS is not that simplified with systemsgrowing apart and countries adding their own specialities makes it harder for collaborativeprojects. The question still remaining is it ideal to strictly follow a standard as it is, or is itbetter to save the work of starting from scratch and define a standard of one’s own based onan existing standard? Sweden and Norway have this specialisation, Sweden with theINSPIRE standard and port connections. For large collaborative projects the basics of thetransport networks is the same, but if every country where to make something of their ownit would probably lead to complications in the future, with new challenges and newrequirements that does not yet exist or are hard to predict.

Gudmundsson, Brömmelstroet et.al and Australian articles provided some great inside forfuture recommendations for software development that can be applied to the new softwaresolution. Even when the results here and only examples, the recommendations for future

46

and further development can be extracted. The main technology is the defined guidelinesfrom Lantmäteriet and Trafikverket and their ability to exchange data, while the secondhand are the facts and standards itself. This does not mean that facts should be disregarded,but the application, transmission and utilization of facts should be open minded andsocially constructed. High communication value is key not only internally but also betweenTrafikverket, Lantmäteriet and those who provide systems and solutions such as ANDA tomake the system work smoothly and be understood.

As mention in Section 2.1 NVDB also suffers from low implementation rate and createsissues for making new applications and the ability to adapt to ever-changing nature ofplanning. The model itself is transparent in the sense of the standards document for whichNVDB is based are open and accessible to the public. As well as the understanding of howlinks, link sequences and nodes are connected. It is not however transparent when it comesto real examples and data flows. The practical solutions are not reflected when using theprogram and the sample data, the reality is quite different from the generic concepts ofwhich the model is based on. The model is described at the receiving end but the versionmanagement is not. This is part to the solution today is handled manually by few peoplewho decide how a link is created from orthophotos, which decrease the transparency. Rulesand guidelines at both Trafikverket and Lantmäteriet dictate and limits the alternativesolutions which is presented in Section 3. It was at the end still unclear how the dataactually looks like when it comes for modification at the resulting FME workspace andaltered for OpenTNF writing. Which parameters are sent to the work database or if onlythe geometry is sent is unclear, and can in the future be compared with the finishedsolution. The software solution is open for adding those as parameters which can beintegrated in the system but assumption had to be made which is not general to generateresults. The handling of those geometries and requirements are however general, and canwork as a general guideline to fill the gap where many researchers say they are no realexamples. If the OpenTNF model is understood as well as the SIS standard, the resultingworkflow can be a general guideline of what to take into consideration when writing andconnecting it to an existing transport network.

Using FME in this case in completely optional and similar results could be achieved by anysoftware who can read and write database files such as Geodatabase, Shape andGeopackage. When writing such a program the data quality and definitions are defined andneeds to be taken into account. At check-in in this case the data would not pass since therequirements and maximum error is already defined in this case in TNE.

47

The program written is made with a bottom-up approach. It is required to learn theattributes and connections and standard, UML schemas etc. to understand how everythingworked came together. To meet the project time constrains, it was necessary, maybe itwould have been better to start writing a program first according to the standards at atop-down approach to provide more examples and even a fully flexed software that wouldgenerate all new, modified and deleted roads automatically into the TNE verification.However many key issues and questions were answered as well as how the links and nodesmust be altered for each change type. That was why a bottom-up approach seemednecessary for a first time developer of NVDB.

FME is a great software for easy workflow and understanding to connect data. FME couldbe one option to do the software solution at a work database at Trafikverket. Other optionsare to add functionality to the ANDA check in, so if features are missing when a link isadded, they are created and added accordingly to the existing network. The issue there ismainly data security since Trafikverket does not allow direct modification inside of thedatabase. The data comes externally according to the standards and verified for data qualityand other issues so it can be added into the network. FME is an optional tool and solutionssuch as Mericural or GeoGIG is also possible for version control, or using programminglanguages to set up scrips somewhere in the data exchange pipeline.

The software and model followed the context and content theory. Expert advice is given bysupervisors at Trafikverket who work with NVDB as well as FME. A study visit atLantmäteriet provided insight at the ex-ante implementation where the model could beassessed as well as real examples seen of how the private road data is created andimplemented before it is sent to Trafikverket. Meetings with experts on TNE software aswell as usage of NVDB at both Trafikverket and Triona AB gave insight of the receivingend. During implementation it is difficult to evaluate how well the solution works since it isonly pass or fail at data check in. Trafikverket and Lantmäteriet work together but alsohave their own systems, agendas and policies. Communication is key if a software solutionshould be integrated between the parties. The OpenTNF transfer which is described inSection 1, is not completely set in stone. Data modification can instead be made beforedata is sent from Lantmäteriet, or in another step at check-in. Lantmäteriet makes thisinformation by hand, but even if the examples are simplifies, if only a part of the problemcan be automated it would still increase efficiency. The new ANDA system is not as oftoday in use but it will use the OpenTNF standard and these examples can help with insteadof just having “this is how it should look” to “this is what needs to be done to look thisway”.

48

Drawing test links in ArcMap and trying to add, modify or delete all connected objectsaccording to the OpenTNF schema is a challenge but great way to understand how thepractical parts come together and connect of each other. Only adding the link is notenough, but the nodes that needs to be connected and understanding how it interact with theexisting network and other connected objects. Even when the examples are simplified anddoes not include the port connection, the nodes, links and link sequences are the crucialobjects to understand in either the ISO or INSPIRE standard and how they interact. Theresult workflows give a general understanding of how these interact independently ofwhich software to use to make these changes.

6 Conclusions & Future Work

Conclusions is that NVDB is based on the INSPIRE standard, but suffers from a generalimplementation when adding special definitions such as the port connection. This createsissues when creating new applications and future concepts of international collaborationbetween data networks. The model is transparent and follows the basics of the ISOstandard. A suggestion would be to redefine the whole model to follow the INSPIREstandard more strictly, however it was stated by the Swedish Road Administration since themodel is already in use in all municipalities and countless products and applications, thewhole data infrastructure would need to be demolished and built up again, which is notlikely to happen. A hybrid solution would probably be developing new definitions forapplying new concepts to NVDB.

The ISO, SIS and INSPIRE standards are useful for creating a common ground forplanners in Europe, however reality does not always reflect the usage of those standards,such as in the case of NVDB. Systems in countries such as Germany and Norway havegrown apart and using their own definitions to easier fit their indivudal agendas andsystems. The consequences from those changes were probably minimal at first, but grewlarger as the technical advancement developed. The scope of usage was national at first,and the technical advancements increased the requirements and capacity of internationalITS. The case on NVDB and the Norwegian database, add-ons and specialisation is createdpost implementation to meet those requirements. If the European Union would makedefinitions in standard for how to handle intermodal connections and plan for ERS,individual countries would not need to create their own definitions. Countries also develop

49

at a different rate, and the ones already testing ERS and geofencing is not going to wait forstandard definitions from the EU.

Creating a software solution is a working progress. Future work includes ongoingcommunication between Trafikverket, Lantmäteriet, municipalities, the forest industriesand other involved software developers to create an optimal workflow for the exchange ofnetwork data. There is as of today no plan of how to solve or apply NVDB to future ERSand include private roads. A strategy both formal and informal needs to be created to meetrequirements set for usage.

The INSPIRE standard is widely used, and there is no existing solution for automatichandling update data from a shapefile. Software developers and researchers could makemore practical examples and present alternative solutions similar to the one presented inthis thesis to improve understanding of the practical aspect of a data standard.

50

References

Beech, D. & Mahbod, B. (1988), ‘Generalized version control in an object-orienteddatabase’, Proceedings Fourth International Conference on Data Engineering 1(Feb 01-05), 14–22. DOI: 10.1109/ICDE.1988.105441.

Brömmelstroet, M. T. & Bertolini, L. (2011), ‘The Role of Transport-RelatedModels in Urban Planning Practice’, Transport Reviews 31(2), 139–143. DOI:10.1080/01441647.2010.541295.

Cary, R. W, and Guyon, R. D (1989), ‘United States Patent No. US4875159A’.Retrieved from: https://patents.google.com/patent/US4875159A/en?q=~patent%2fUS4875159A.

European Commission (2014), ‘INSPIRE Data Specification on Transport Networks ñTechnical Guidelines’, [online] Available at: https://inspire.ec.europa.eu/id/document/tg/tn. Accessed: 2019-03-27.

GeoGig (2019), ‘A tool for geospatial data management’, [online] Available at: http://geogig.org/#install. Accessed: 2019-03-13.

GitHub (2019), ‘OpenTNF - An open and efficient solution for exchange ofTransport Network Data’, [online] Available at: https://github.com/OpenTNF/opentnf/blob/master/OpenTNF%20-%20white%20paper.pdf. Accessed:2019-03-27.

Gudmundsson, H. (2011), ‘Analysing Models as a Knowledge Technology in TransportPlanning’, Transport Reviews 31(2), 145–159. DOI: 10.1080/01441647.2010.532884.

IBM corporation (2006), ‘The Stockholm Congestion Charging Trial’, [online] Available at:http://www.stockholmsforsoket.se/upload/Infomaterial%20MAK/

IMPACTS_IBM_v2.pdf/. Accessed: 2019-03-15.

Niestroj, M. G., McMeekin, D. A. & Helmholz, P. (2018), ‘OVERVIEW OF STANDARDSTOWARDS ROAD ASSET INFORMATION EXCHANGE’, The International Archives ofthe Photogrammetry, Remote Sensing and Spatial Information Sciences XLII-4(ISPRSTC IV Mid-term Symposium), 443–450. DOI: 10.5194/isprs-archives-XLII-4-443-2018,.

Norlin, T. (2019), ‘Interviewed by Josefine Jonsson 2019-02-08’, [interview].

O’Sullivan, B. (2003), ‘Mercurial: The Definitive Guide’. USA, VIC: O’Reilly Media, Inc.

Rodrigue, J. P, and Comtois, C and, Slack, B (2017), ‘The Geography of Transport Systems’,(1st ed.). USA and Canada, VIC: Routledge.

51

Safe Software (2019), ‘Solutions for application ESRI ArcGIS’, [online] Availableat: https://www.safe.com/solutions/for-applications/

esri-arcgis/. Accessed: 2019-03-27.

Swedish Standards Institute (2006), ‘Geographic information - Representation of changesin datasets’, " "(SS 637007:2006). Retrieved from: https://www.sis.se/en/

produkter/information-technology-office-machines/general/

ss63700720062/.

Swedish Standards Institute (2008), ‘Geographic information - Data product specifications’,(SS-EN ISO 19131:2008). Retrieved from: https://www.sis.se/produkter/informationsteknik-kontorsutrustning/ittillampningar/

allmant/sseniso191312008/.

Swedish Standards Institute (2009), ‘Geographic information - Roadand railway networks - Conceptual and application schema’,(SS 637004:2009). Retrieved from: https://www.sis.se/

produkter/naturvetenskap-och-tillampad-vetenskap/

astronomi-geodesi-geografi/ss6370042009/.

Trafikverket (2012), ‘Specification NVDB technical solution - ID handling andtransactions’. Accessed: 2019-04-23.

Trafikverket (2018), ‘About NVDB’, [online] Available at: http://nvdb.se/en/

om-nvdb/. Accessed: 2018-12-14.

Triona AB (2018a), ‘Milestone reached at Trafikverket’, [online]Available at: https://www.triona.se/nyheter/2018/

milstolpe-nadd-hos-trafikverket/. Accessed: 2019-05-23.

Triona AB (2018b), ‘Transport Network Engine - Product Documentation’. Accessed:2019-03-27.

52

Appendix A

Workflow Creating New Link

53

Workflow Modifying Link

54

TRITA TRITA-ABE-MBT-19537

www.kth.se