Automating 3D graphics generation using GIS data - Terrain and Road reproduction

(1)

Automating 3D graphics generation using GIS data - Terrain and Road reproduction

Orvar Segerstr¨ om

May 26, 2015

Master’s Thesis in Computing Science, 30 credits Supervisors:

Jan Erik Mostr¨ om, Fredrik Sandstr¨ om, Daniel Wiberg Examiner:

Fredrik Georgsson

Ume˚ a University

Department of Computing Science

(2)

(3)

Abstract

In this thesis we evaluate different types of GIS data as well as their use cases in the context of the generation of 3D environments. We explore what kinds of GIS data are suited towards 3D graphics generation, how each type is typically represented and different use cases for each.

Subsequently, a software prototype is implemented inside an existing codebase, in the form of a tool for a 3D editor that uses GIS data files to produce textured terrain as well as synthetically reproduced roads. A novel technique for detecting and extracting roads from LiDAR data is introduced, and used to generate roads in the form of 3D meshes. The road extraction technique is based on shape analysis of LiDAR-backed road cross-sections.

The program creates satisfactory terrain, but the texturing is observably flawed as a consequence of the choice of source data. The road extraction typically works well, allowing for a visually pleasing and correct reproduction of roads. However, the technique is weak in handling edge cases due to the opimization problem of minimizing both false negatives and false positives.

The prototype clearly demonstrates the merits of using GIS data for the purpose of generating 3D environments, and the lessons learned are valuable to similar endeavors.

(4)

(5)

List of Figures

4.1 A schematic of the general design of the prototype. . . 18

4.2 Quick Terrain Reader screenshot . . . 21

4.3 ArcGIS Online screenshot . . . 21

5.1 Naive and smart triangulation of quadrilaterals . . . 24

5.2 Naive and smart triangulation of quadrilaterals . . . 25

5.3 Coarse road geometry of original terrain mesh . . . 26

5.4 Comparison of detail between processed DEM and raw LAS - the top portion shows the DEM data of a road, the bottom the LiDAR data. . . 28

5.5 Road scan-line . . . 29

5.6 Projecting LiDAR point onto the scan line . . . 29

5.7 LiDAR data of a road projected onto a cross-section plane . . 30

5.8 LiDAR data of a road projected onto a cross-section plane . . 30

5.9 Resampled LiDAR points on a cross-section plane . . . 30

5.10 Roadway cross-section shape highlighted by excessive slope . . 31

5.11 Highlighted roadway cross-section annotated with roadway guess 32 5.12 Road mesh produced by the road generator . . . 34

6.1 Result: Forest terrain . . . 36

6.2 Result: Forest terrain at another angle . . . 37

6.3 Result: Farm land terrain with roads . . . 37

6.4 Result: Mining site terrain . . . 38 v

(8)

vi LIST OF FIGURES

6.5 Result: Baked shadows and stretching . . . 38

6.6 Result: Flatly projected buildings . . . 39

6.7 Result: Road centerline detection visualized . . . 39

6.8 Result: Birds-eye visualization of detected road . . . 40

6.9 Result: Road detection at junction . . . 40

6.10 Result: Road detection at junction close to fields . . . 41

6.11 Result: Generated road stretch . . . 41

6.12 Result: Generated non-linear road . . . 42

6.13 Result: Generated road at junction . . . 42

(9)

Chapter 1 Introduction

This chapter introduces the thesis and its context. First the topic is related to the surrounding environment of the computer architecture industry. We describe what has been done and what is the reason for this thesis. After that the problem formulation of this thesis is presented. Lastly the goal and expected results of the thesis are discussed in more detail.

1.1 Motivation

GIS, short for Geographic Information System, is a system for mapping spatial and temporal positions to data of different kinds. GIS in itself does not specify which kinds of data can be mapped to, and common examples include elevation, soils, agriculture, recreation, wildlife, waterfowl, forestry and land use.

Oryx Simulations in Ume˚a, Sweden builds the software and hardware for machine simulators that use virtual 3D environments to provide training for machine drivers–including training for forestry machines. The demand for these solutions stem from the cost of driving the real machines, and the risks of putting control of a machine worth millions into the hands of a novice student. Currently, 3D environments are manually created using 3D graphics modelling software, which is repetitive and time-consuming, as each and every detail is manually crafted or positioned. Many of Oryx’s customers want the simulator scenarios to take place in accurately modelled reproduction of areas where the drivers will eventually drive.

A possible solution is to utilize GIS data to automatically generate parts 1

(10)

2 Chapter 1. Introduction

of this 3D environment. Such a generator would increase profits by allowing reinvestment of resources hitherto allocated to manual 3D modeling. Such a solution would not have to be total - a partial solution would still be useful.

There is also a possibility of the computer doing a better job at it than a human could, which would increase the quality of the final product.

1.2 Problem formulation

This thesis dataintends to explore the to what extent a 3D environment can be automatically generated using GIS data in the context of Oryx’s simulation platform. To facilitate this, the following questions will be discussed:

– What kinds of GIS data are suited to this, and to what extent?

– What is the possible use cases of each kind of data?

– How can these use cases be implemented in a real application?

The focus lies on the last question, which is answered by the construction of a prototype program that makes use of GIS data anddata generates terrain and road geometry.

1.3 Related work

Procedural generation of terrain and landscapes is a well-trodden field.

The exist several software products, both commercial and free, with the capability of producing realistic terrains. Popular examples include Artifex Terra¹ and Terragen 3².

There exists software for automatically constructing 3D representations of areas from normal photography [20], using image analysis of photos shot from different angles to infer depth, and so build up a 3D representation.

This method has the advantage of being able to build up 3D scenes with acceptable accuracy which are textured from the get go, without expensive equipment - companies claim accepable results are possible with consumer

1http://www.artifexterra.com/

2http://terragen3.com/

(11)

1.3. Related work 3

cameras. However, areas without complete photographic coverage will leave holes in the model.

Parberry writes in his 2013 report Designer Worlds: Procedural Generation of Infinite Terrain from USGS Elevation Data[19]

of using perlin noise to generate visually pleasing terrain, and introduces a method where the perlin noise generation is based on GIS elevation data.

This method yields terrain that share characteristics with the extracted location described by the GIS data, but is of no aid in terrain reconstruction.

Wanga et al [23] use road data to generate roads geometry on an implicitly flat terrain. They use two-dimensional GIS data of road centerlines, combined with a selected set of civil engineering rules for road design to produce high-fidelity 3D road network models. This approach works very well, and can even handle cases where roads pass over each other. It produces visually appealing and structurally sound roads. However, this approach assumes that the road data is accurate, and that the terrain is flat - no fitting to an existing model is explored.

In their 2010 paper, Smadja et al [21] present a vehicle dedicated to road surveying, equipped with LiDAR and high-definition cameras, as well as the computation and interpretation of the collected data into 3D environments.

They include an original algorithm for road extraction, using the RanSaC algorithm to estimate road sides and then again to eliminate unlikely candidates.

In their 2013 paper, Kumar et al [13] present an algorithm for extracting left and right road edges from LiDAR data collected from a specialized vehicle. The algorithm combines two modified versions of the parametric active contour model, a technique often used for image segmentation. The results are promising, yet relyon a high-resolution data source.

Holgado-Barcoa et al [9] present another algorithm in their 2014 paper that combines Principal Component Analysis with geometric parameters like slope and superelevation in a hierarchical strategy to automatically extract geometrical road parameters from LiDAR data collected from a specialized vehicle.

(12)

4 Chapter 1. Introduction

(13)

Chapter 2 Theory

In this chapter, topics needed to fully understand the remainder of the thesis is briefly introduced.

2.1 Coordinate systems

Coordinates with latitude and longitude components (spherical coordinates) are defined in a coordinate system context. The standard coordinate system, used on most map software and by the Global Positioning System (GPS), is the World Geodetic System 1984, or WGS84. The WGS84 datum defines scales and context for the latitudal and longitudal components, and heights computed by GPS receivers are defined in relation to the WGS84 ellipsoid, which approximates the shape of the earth. The zero line of longitude passes through Greenwich, United Kingdoms, while the latitudinal zero line lies on the equator. [14]

SWEREF 99 is a similar coordinate system with a slightly different reference ellipsoid and a different degree scale. SWEREF 99 and WGS84 can be used approximately interchangeably, as they differ only by a few decimetres; SWEREF 99 changes over time as the european plates move, while WGS84 is static. [16]

2.2 GIS data

GIS data is a general system for digitally describing any data tied to a specific position in space and time. Examples include:

5

(14)

6 Chapter 2. Theory

Geology: Lakes, rivers, elevation, satellite imagery

Boundaries: Property lines, buildings, country/city/school district borders Meteorology: Rainfall, temperature, winds, storms

Statistics: Population density, age, income

Any digital representation of such data is classified as GIS data, and there is no single official format;

There are two main classifications of GIS. Raster data splits a geographic area into a grid and describes some property for each square in the grid, such as elevation or terrain type. The absolute position of each cell is then implied by it’s position in the grid, and the explicitly given positions of the four corners of the grid. To do this, we must assume that the area is more or less flat. Thus, the real position of the grid cells are approximation.

The second method is called the vector or polygon-based model. It allows us to specify the exact spatial locations explicitly. Space is assumed to be continuous rather than a discrete set of areas. [6]

GIS data can be obtained from numerous sources. There are countless of different types of data, proprietary and free, offered. Most providers offer tools to select an area to download data for.

OpenStreetMaps allows the exporting of free, open road data from their website. The data is licensed under the Open Data Commons Open Database License (ODbL), making it free to copy, distribute, transmit and adapt as long as credit is given.

The Swedish university SLU¹ provides the tool GET² for choosing and downloading GIS data for a Swedish geographical region. GET offers map data from Lantm¨ateriet (National Land Survey), statistical data from SCB (Statistics Sweden), geological data from SGU (Geological Survey of Sweden) and sea-related data from Sj¨ofartsverket (Swedish Maritime Administration).

Access to the tool is granted for research, education and cultural activity pur- poses, for users at educational institutions affiliated with SWAMID (Swedish Academic Identity). Other institutions and companies can use Geodata Ex- plorer³ to explore the same data, but a contract is required and data orders are handled through communication with a contact person. Alternatively,

1https://www.slu.se

2https://maps.slu.se/get/

3https://www.geodata.se/GeodataExplorer

(15)

2.3. Computer graphics 7

data from Lantm¨ateriet can be ordered through any of their resellers⁴

2.3 Computer graphics

The book Interactive Computer Graphics[2] by Edward Angel gives us a good introduction to the mathematical underpinnings of computer graphics.

In computer graphics, there are three basic types: scalars, points and vectors. A scalar is a real number, listed not for any geometrical properties but by its extensive use in measurement of geometrically meaningful objects.

The fundamental object is a point. A point is a location in space; two- dimensional, three-dimensional or otherwise. It has neither direction nor size, and is only positionally meaningful when considered in the context of coordinate systems and reference frames.

A vector, on the other hand, lacks any notion of position, but describes a direction and a magnitude in space. A vector can be used to move a point - the vector is scaled and then added to the point, resulting in a new point that has moved in the direction of the vector. Vectors are often visualized as lines or arrows, unlike points.

GPUs function by rendering graphical primitives in a rendering pipeline. The CPU sends polygons into this rendering pipeline. A three- dimensional polygon consists of a number of points in space, forming a shape.

Such a point is referred to as a vertex. When collections of polygons are sent to the GPU, they are processed into fragments based on their position. The pipeline then processes the fragments into a two-dimensional image representation suitable for display on the screen. To simplify graphic card design, polygons sent to the GPU are typically triangular, meaning they consist of three points.

The lines between the constituent points in a polygon are referred to as edges; a triangular polygon has 3 edges. A polygon has something called a normal vector, which is the directional vector that describes in which direction the polygon’s surface points at - which side points up.

A Quadrilateral or just Quad is a polygon with 4 edges, such as a square, rectangle or parallelogram. It must be triangulated to obtain

4https://www.lantmateriet.se/sv/Om-Lantmateriet/Aterforsaljare/Vara- aterforsaljare---inom-olika-produktomraden/

(16)

8 Chapter 2. Theory

triangular polygons. This process is very straightforward, as any rectangle can trivially be split diagonally to obtain two triangles.

A Mesh is a collection of interconnected polygons constituting a shape.

Whereas a polygon is locally flat, a mesh can form complex surfaces such as human faces or bodies, trees, houses, giraffes and terrains.

2.4 Texturing

For a primer on texturing, we can turn to the book Texturing & Modelig - A Procedural Approach. The original technique of texturing uses parametric patches. A patch is a rectangle inhabiting (0, 0) to (1, 1) in parameter space. By placing the patch across a shape in 3D space, we can trivially convert each 3D coordinate of the shape to a 2D coordinate on the patch. By simple transformations, images can be mapped to patches, which finally allows the conversion from 3D coordinate to image pixel value.

This technique is called texture mapping. Modern applications of texture mapping typically employ some form of texture filtering to reduce so-called aliasing artifacts.

(17)

Chapter 3 GIS data

This chapter introduces different types of GIS data with potential relevance to 3D environment generation, theory surrounding them, file formats used as well as potential and well-established use-cases.

3.1 LiDAR data

The word LiDAR is commonly used as an abbreviation of Light Detection and Ranging [22]. It is a remote sensing, or surveying, technology that uses laser pulses in a radar-like fashion to measure distance to as well as refractory properties of the object hit. It is commonly used from aeroplanes to generate information about the shape of the earth surface. The position information of the aeroplane, determined by GPS, is combined with the velocity of the aeroplane as well as the angle and recorded distance of the laser, resulting in accurate, absolutely positioned 3D point measurements.

These points, as well as their associated laser reflection intensity, are gen- erally stored digitally using the LAS file format [3]. The LAS format is a binary, open format, intended specifically for storing data from LiDAR and similar technologies. A LAS file begins with a header block specifying point coordinate system used, GPS details, point offsets, axis scale factors and more. It also specifies an offset to point data value used to determine where the actual data starts. The actual data can use any one of ten formats, as specified in the header. All the formats have in common the X, Y and Z components of the point, intensity of the measurement, direction of measurement, classification and more. The classification of a point is a number mapping to

9

(18)

10 Chapter 3. GIS data

a classification category as defined in the specification, which, among others, includes the categories unclassified, ground, vegetation, building and water.

Eagle Mapping, a company that specializes in LiDAR mapping and sells surveying services, write in their paper titled LiDAR Mapping: High Ac- curacy, High Speed[5] that LiDAR is superior to other surveying methods with regards to surveying speed and costs of large areas. The data is very detailed, can be automatically classified and have countless of uses. It does not require ground access to the surveyed areas, and the laser pulses can pen- etrate vegetation by measuring multiple reflections of the laser, which allows surveying things like tree height. However, they do admit to a few disadvantages of the technique. The method has a significant up-front cost, which means LiDAR surveying is unlikely to be cost-effective for smaller projects.

Also, even though the data is detailed and accurate, it will not accurately describe real-world details like sharp edges and slopes, since the points are spread uniformly and no technique is used to take extra measurements on detected edges.

A point that is not mentioned is that LAS data takes up a very large amount of memory and disk space due to being such an exact representation with allocated space for storing extra data for each measurement - in our measurements, 20 square kilometers of LAS data takes up in excess of 2 gigabytes of disk space when not compressed.

LAS data is not strictly laid out in a grid, explicitly or implicitly. This means some processing of the data must take place to use it for graphical terrain construction. First, vegetation and other partial reflections should be filtered out from the data, leaving only ground measurement points. The data can be triangulated using a triangulation algorithm, such as Delaunay[1], which would give a very detailed mesh where each LiDAR measurement is a vertex, and with optimal triangles connecting each vertex to its neighbors.

There are very fast Delaunay algorithms, with O(n log n) time complexity, but the triangulation of a millions points can still take several seconds[1].

The number of LiDAR points grows quadratically with increasing area size, which puts a hard limit on area size when triangulating laser data in real-time applications.

Extensive research has been poured into classifying land cover into categories such as barren land, shrubland, wetland, grassland, different types forests and water [24]. Performing these classifications give rise to the possibility of realistic texturing that match the real-life land cover type, as well as generating trees or whole forests of the correct type and size.

(19)

3.2. Digital Elevation Models 11

LiDAR data is often used for automatic extraction of road geometry [21][13][9], using sophisticated techniques for roadway extraction with good results. The techniques are often tied to high-resolution data associated with a specialized vehicle gathering the data. Applying any of these techniques, vectorized road GIS data can be extracted, and any technique using road data, even those requiring high-resolution data, can be further applied.

LiDAR is also used for automatic extraction of building geometry [12][18]

in a similar fashion, yet more often applied to aerial LiDAR data. Once classified, the data could be used for procedural generation of buildings.

3.2 Digital Elevation Models

According to Florinsky’s chapter in Digital Terrain Analysis in Soil Science and Geology[8], Digital Elevation Models are digital models of topographic surfaces - e.g. the surface of the earth, or sections of it. They can be generated by various field, remote and laboratory techniques, including:

– Conventional topographic surveys using tacheometers and leveling in- struments,

– Photogrammetry, using stereo images taken by aeroplane or satellite, – Radar: polarimetry, stereo radargrammetry or inferometry,

– Laser surveys - typically LiDAR surveying by aeroplane

Conventional DEMs are described as two-dimensional discrete functions, mapping discrete grid coordinates to a topographically significant attribute.

Typically, DEMs depict relatively small areas of a topographic surface, where the curvature of the planet can be ignored. The grids can be irregular, such as sparse grids with randomly selected points or points selected to describe certain features. Or they can be regular, based on triangles, squares, rectan- gles, hexagons, and so on. Regular, square grids are the most popular, due to their simplicity and their ability to be represented as a raster.

There are several raster file formats used to encode DEMs. USGS DEM[17] is a standard for a binary geospatial file format, consisting of a header section describing the projection and size of the raster, followed by the raster data itself.

(20)

Another way to encode DEMs is the GeoTIFF[15] file format, which is a specification using the TIFF raster image format. The native header section of the TIFF is exploited to attach additional information such as geospatial projection and raster semantics, and the image raster is filled with a topographical attribute, e.g. a discrete altitude matrix.

Depending on the resolution, DEMs can often be used much in the same way as LiDAR data - it can be thought of a lossily compressed representation of the same thing.

Using a DEM for 3D terrain construction is more straightforward than achieving the same with raw LiDAR data. DEMs are laid out in rasters, which have an explicit geometric arrangement. This fact can be exploited to trivially construct height maps or 3D meshes. The raster is virtually the same as a height map already, if metadata is discarded. As for producing a mesh, square raster DEMs have square grids of height values, forming implicit squares. Each square can be trivially split into two triangles by adding a diagonal edge between two corners.

3.3 Orthophotographs

According to Fundamentals of Geographic Information Systems[6], an Orthophotograph is a special type of aerial photograph that do not contain distortions that are normally found in aerial photographs such as topographic relief, lens distortion and camera tilt. The orthogonal projection results in a photograph that can be used to measure true distances, like a map, as it is an accurate representation of reality. Orthophotographs are created in a process called differential rectification, where scale and relief-displacements are corrected point by point by correlating the points to geographic reference points.

The paper Digital ortho-images — a powerful tool for the extraction of spatial- and geo-information[4] lists 10 applications for orthophoto imagery in GIS, including:

1. Data quality control - Overlaying other GIS data on top of the orthophotography aids in determining the accuracy of such data. As an example, vector data can have local or global positional inaccuracies, which are easily visible to a human. This allows some degree of manual quality control of input data. This is often used for visualizations and simulators.

(21)

3.4. Vector data 13

2. Improvement of classification techniques - Using orthophotograph data in conjunction with DEMs, vector and other data in a multi-spectral classifier adds a valuable source of truth, or can otherwise be used to determine the accuracy of the classifier.

3. Draping of ortho-images on DEMs - A common application where the orthophotograph is projected onto a graphical representation of the DEM, creating a textured 3D view.

The last application has a few drawbacks. The resolution of orthophotographs are usually too low to be sufficient at all viewing distances and will appear coarse at close distances, where a pixel of the photograph might be stretched across a square meter or more. Cars and houses are included in the images, and will break the illusion of realism as they are flatly projected onto the terrain. The image also contains shadows, which restricts what kind of lightning can be added in the rendering phase - adding shadows from another angle results in two sets of daylight shadows, which will also, presumably, look distinctly different from one another.

The paper Automatic high-fidelity 3D road network modeling based on 2D GIS data[23] by Wanga et al details the use of Perlin Noise to procedurally generate textures. Concievably, this could be used in conjunction with Orthophoto data, where the image data could be classified into different kinds of terrain, which would then allow using the classified data to automatically generate and project areas of procedural textures.

3.4 Vector data

Vector GIS data are intuitive in that they are reminiscent of analog map features - areas, roads and buildings are distinctly specified in position and shape. Digitally, they are represented as vectors describing position and geometrical shape. The shape can be any of the following kinds:

Point A single coordinate specifying the location of something.

Line or Polyline Two or more coordinates in sequence describing a line or sequence of lines.

Polygon Three or more coordinates describing a complex shape, often an area.

(22)

Vector data can be encoded in numerous formats. ESRI Shapefile[7] is a popular format for encoding GIS vector data. The format specifies three files: a main file storing the shapes, an index file for faster random access of the main file and a database file for attaching arbitrary attributes to the shapes. The main file uses a binary format with a header section, followed by pairs of records consisting of record header and record content. Each record is a shape.

Another popular alternative is the GeoJSON[10] format. GeoJSON is simply a flavor of the plain-text JSON format. As such, it is very easy for humans to read and to create parsers for. Shapes are defined as single coordinates or a collection of them, and the shape kind is denoted explicitly with a shape attribute.

We’re interested in vector data that is useful for graphical reconstructions.

This includes road data, terrain vector data and forest area data.

In road GIS data, roads are typically represented as polylines describing the coarse curvature of the road, each point aiming to lie on the middle of the road. Additional information may often be attached, like road classification, road number or road name. Road width could possibly be inferred from classification information, but is seldom explicitly specified. Terrain and forest area data consist of annotated polygons describing or classifying areas.

As an example, forest data might specify a polygon and attach data to it describing the type of trees and the tree density and height.

The paper Automatic high-fidelity 3D road network modeling based on 2D GIS data[23] by Wanga et al describes the use of 2d road data to procedurally generate a road network using a selected set of civil engineering rules and an automated approach to making assumptions of overpasses and tunnels.

The paper A Survey of Procedural Techniques for City Gen- eration[11] reviews a slew of techiques for procedurally generating a city, including building. These techniques could be employed and fed with GIS data of roads and buildings. Depending on the detail of the source data, this could give passable results, and save a lot of manual labor.

The same paper also describes the use of Lindermayer systems, where a concise set of rules produce fractal geometries. Some L-systems can be used to generate trees. SpeedTree¹ is a software using this technique and some clever texturing to generate realistic trees with good performance. Forest

1http://www.speedtree.com/

(23)

3.4. Vector data 15

area data could be used to automatically generate tree positions, sizes and types, which could then be fed into such a tree generator.

The paper further describes the use of Perlin noise to procedurally generate textures. Terrain classification data could be used to control the cha- rasteristics of the generated texture, which could then be applied onto a matching terrain.

(24)

(25)

Chapter 4 Prototype

In this chapter a prototype utilizing GIS data outlined in the previous chapter is described. The context of the prototype is established, and some back- ground is given as to what different kinds of software it ties to.

4.1 General Design and Architecture

The prototype produces a textured, three dimensional terrain with refined road geometry. The use case is for the scenario designer to utilize the prototype during the creation process, and to base the scenarios on the results of the generator. The prototype takes contextually meaningful GIS data as input and generates graphical and physical primitives that are both immediately visible to the user and significant to the physics simulation.

The prototype is thus implemented as a module in the existing Oryx codebase, which is written primarily in C++. The 3D rendering is fulfilled by OpenGL using the Ogre3D¹ 3D graphics engine. An external library is used to simulate the rigorous physics required for the interactions between the simulated vehicle and its environment.

The program has multiple front-ends, including the editor and the simulator program. The editor is where scenarios and scenes are built by ma- nipulating the scene tree, adding things like terrains, trees, machines and properties. The simulator then starts scenarios and runs through them, rendering different cameras to separate screens of the simulator hardware. The prototype provides a tool in the editor front-end, allowing the generation of

1http://www.ogre3d.org/

17

(26)

18 Chapter 4. Prototype

terrain and roads in the creation phase, but does not have any effect on the simulator front-end.

Figure 4.1: A schematic of the general design of the prototype.

The architecture is visualized in figure 4.1. An editor component can be added to the scene by the user, which allows specifying GIS input data files and generation configuration. It also provides a button that initiates a generation cycle using the data and configuration. The editor component also defines an execution thread that administers the processing. During processing, it updates the user interface to give visual feedback of the progress of the processing. It begins by reading the specified GIS data into a unified format using a matching reader class. When all relevant data has been loaded, it is sent to the Generator class, which is the most interesting piece of the prototype. It uses the data and produces graphically meaningful representations, utilizing methods that will be outlined in chapter 5. When the Generator has finished processing, the component thread checks out and exports the finished graphical primitives and adds them to the Scene Tree.

The prototype has been developed in an exploratory fashion, testing out different methods and tools separately, discarding or keeping the changes depending on the results. Several mini-prototypes were also built to quickly it-

(27)

4.2. Libraries and tools 19

erate on solutions in an isolated environment; for example, the road detection was initially developed by extracting input data from the main prototype, and implementing a mini-prototype visualizing the intermediate data in an easily parseable format.

4.2 Libraries and tools

Several libraries and tools were used in the development of the prototype.

They were of great help; either increasing productivity, or reducing complexity, or both. The libraries were linked with the application code, while the tools were used for source data manipulation and visualization.

4.2.1 Library: GDAL

The Geospatial Data Abstraction Library² is the Swiss Army Knife of GIS data. It is open source and is written in C and C++. GDAL operates at an abstraction level where it allows the programmer to treat any vector data or any raster data equally - the same operations for raster or vector data operate on any file format matching the type of data. As an example, code using GDAL to read vector data from SHP files will also, without modification, operate on GeoJSON files.

GDAL also includes some tools for data information and manipulation.

– gdalinfo outputs any metadata for a given GIS file, including projection and extent.

– gdal translate converts raster data between different formats, with fine- grained control of the conversion.

– gdaltransform reprojects the explicit or implicit coordinates of gis data into another, supported, projection.

– gdalwarp reprojects or warps raster data.

– gdal grid creates a regular grid from scattered data.

– gdal rasterize lossily transforms vector data into raster data.

2http://www.gdal.org/

(28)

4.2.2 Library: libLAS

The ASPRS LiDAR data translation toolset³ is an open source C/C++ library for reading and writing data of the LAS format. As LAS is a complex binary format, this library is nearly a requirement when work- ing with LAS data.

libLAS bundles LASTools, which includes the following tools:

– lasinfo outputs metadata and data quantity of a LAS file.

– las2las allows for advanced transformations of LAS data. It allows point filtering and extraction, as well as format upgrades.

– las2txt, las2ogr and txt2las provide data conversion to and from other formats, such as flat text files and GIS vector formats.

– lasdiff allows the comparison of LAS files to determine whether they are identical or, if not, what differs.

– lasmerge merges several LAS files into a single LAS file, which aids situations where a single file is needed.

4.2.3 Tool: Quick Terrain Reader

Quick Terrain Reader⁴ is a free of charge utility for exploring LiDAR data in the LAS format. It visualizes the points in 3d space, and allows point customization and coloring depending on the height and intensity of the reflection. Figure 4.2 shows LiDAR data being explored in the program.

4.2.4 Tool: ArcGIS Online

ArcGIS Online⁵ is a proprietary service for exploring GIS data. It allows the import, export and sharing of vector data, enabling easy visualization and exploration of the data. The software is not geared towards consumers, hence no pricing is published on the website - pricing must be negotiated.

Figure 4.3 shows a screenshot of some road vector data imported into the ArcGIS software.

3http://www.liblas.org/

4http://appliedimagery.com/download

5http://www.arcgis.com/features/

(29)

4.2. Libraries and tools 21

Figure 4.2: Quick Terrain Reader screenshot

Figure 4.3: ArcGIS Online screenshot

(30)

(31)

Chapter 5 Implementation

This chapter details the implementation of the prototype, including important decisions made along the way, implementation-specific or otherwise.

5.1 Terrain

The first step is to create a terrain from GIS data. Either a mesh or a height map can be produced from this. Both options have their advantages and disadvantages, and in this case a mesh was chosen To build a mesh of the terrain, we need coordinates describing the surface of the terrain. DEMs are particularly suited to this, and a source of DEMs of 2 meter resolution was available at the time of development, which seems more than good enough.

The tool thus accepts a GeoTIFF file describing a DEM height raster, which is processed into a vector of three-dimensional positions, or vertexes, in the SWEREF99+TM projection. The vector created by adding each row of the DEM sequentially, and the grid information (rows and columns) of the DEM is kept. Each point is inferred by creating the x and y components of the vertex from the row and column numbers, and the z component represents height above sea level.

This method assumes that the coordinates are Cartesian, while really being polar. It also assumes, as we render distances in x at the same scale as distances in y, that the latitudinal and longitudinal SWEREF99+TM components are of the same scale. While being a false assumption, it can still be used in this case, because

1. We do not need to get complete accuracy of proportions, it just has to 23

(32)

24 Chapter 5. Implementation

look all right to a human observer, and

2. If the resulting model has disproportionately scaled axes, we can trivially modify the scale of the graphical primitives in the editor after the fact.

To get a triangle mesh, the raster grid must be triangulated. This can be done by adding a diagonal edge between two of the four corners of each quadrilateral, turning each square of 4 points in the raster into two triangles.

It can also be done by adding a vertex in the middle of the quadrilateral and adding edges between the vertex and each corner vertex. For this prototype, the first method was chosen - adding an extra vertex introduces no extra detail, but has the cost of almost doubling the number of vertexes and polygons in the mesh relative to the first method

Choosing which direction to add the diagonal edge turns out to be more important than it might seem. If the edge is always added in the same way, e.g. south-west to north-east, there will be graphical anomalies in meshes containing diagonal walls and valleys. If instead triangles are chosen such that the shared edge between the two triangles is as flat as possible, the anomalies do not arise - see figures 5.1 and 5.2. The method preserves detail by favoring acute differences in height over more gradual, but jagged, slopes.

Figure 5.1: Naive and smart triangulation of quadrilaterals

(33)

5.1. Terrain 25

Figure 5.2: Naive and smart triangulation of quadrilaterals

The polygon faces are represented as a triplet of pointers to the vertexes constituting the corners of the triangle. A common alternate approach is to store indexes to the vertexes, but that approach introduces overhead if vertexes are removed, which would require updating all faces containing vertex indexes equal to or greater than the one removed, as all the vertexes after the one removed will have new indexes.

An Orthophoto image matching the topological mesh is projected onto the mesh as a texture. This is achieved simply by adding UV coordinatets to the mesh vertexes that stretches the texture uniformly across the mesh.

As the vertexes can still be related to row and column numbers, the x and y components of the UV data assume values between 0.0 and 1.0 depending on their row and column numbers. The method give rise to a stretching effect to mesh polygons with a steep incline, where the actual length of the polygon is much longer than is accounted for by the UV coordinates.

We’d like to be able to drive a simulator on the generated terrain and its roads, but this becomes heavy for the physics engine due to the size of the mesh. The road geometry is also noticeably coarse with regards to road edges and overall smoothness - see figure 5.3. We’d ideally like to construct visually pleasing, smooth and computationally lightweight graphical and physical road meshes from GIS data, and have them interlock neatly with the terrain

(34)

mesh.

Figure 5.3: Coarse road geometry of original terrain mesh

5.2 Roads

GIS Road data describe the center line of roads as lines of positions. If this data was accurate enough, and included the road width as well, it could be used to immediately generate road geometry. As it is, the data has a coarse resolution and is, plainly, inaccurate, sometimes diverging from reality by ten meters or more. Thus, we must assume that all the data will diverge from reality, and use a method for road extraction that incorporates this assumtion. The most accurate data found for this prototype, having an average accuracy of a few meters at most, is from OpenStreetMaps, which is represented in XML using their own OSM XML schema. To allow for flexibility down the line, support for both formats are implemented.

(35)

5.2. Roads 27

The road data import classes read the data to a unified format, then filter it to only keep significant roads. By significant, we mean roads that, by being wide and flat enough, are possible to recognize algorithmically by their three- dimensional shape. This limits us to paved roads, and forces us to discard bicycle- and pedestrian paths. If the points are not yet in SWEREF99+TM format, as is the case with OSM data, they are also reprojected from WGS84 to SWEREF99+TM.

Having these general hints of road locations, we need some way to determine the geometry of nearby roadways. The terrain mesh detailed in the previous section could theoretically be used for this, but it’s coarseness is the very reason we are trying to extract roads in the first place. A more exact source of terrain curvature could be LAS data. Using Quick Terrain Reader, sample LAS data of a chosen road could be visualized, which, combined with our terrain mesh, yields a meaningful comparison between the geometrical detail - see figure 5.4. The LAS import class reads LAS points, throwing away any points that do not match a filter. In this case, we only keep points representing a ground reflection. The points are then stored as 3D points and further used by the road detection algorithm.

As the goal is to replace or overlay the roads in the terrain mesh with syn- thesized road meshes, the shape and location of each generated road should match reality, and thus the terrain mesh, neatly. Thus, we want to find the left and right edges of each road segment.

To find the side edges of each road, we can look at the shape of its cross- section. Roads are approximately flat, and the sides often decline into ditches to provide drainage of rain water. This can be exploited by incorporating it as an assumption in the road detection method.

To analyse cross-sections, each road is split into equidistant points. A two-dimensional line, perpendicular to the road section, is extended in both directions at each such point. The scan line extends through a cloud of LiDAR points, and LiDAR points close to it are considered for the next step.

The scan line is visualized in figure 5.5.

Nearby points are projected onto a plane by projecting the x and y components of the points onto the two-dimensional scan line, and keeping the z component of the original point - see figure 5.6. Having the P_{lef t} and P_right points of the scan line, as well as the P_laser2d laser point, we can determine

(36)

Figure 5.4: Comparison of detail between processed DEM and raw LAS - the top portion shows the DEM data of a road, the bottom the LiDAR data.

where on the line the laser point lies using:

t = (P_laser2d− P_{lef t})˙(P_right− P_{lef t}) kP_right− P_{lef t}k² ,

where t ∈ [0, 1] indicates that the projected point falls on the line. Using t, we can construct the projection using:

P_proj = P_{lef t}+ t ∗ (P_right− P_{lef t}).

If a point is projected outside of the line limits, or if it’s too far away from the line on the XY plane, it’s discarded. The resulting plane is visualized in figure 5.7.

The points have some noise; small inaccuracies in the data combined with inaccuracies introduced by the assumptions inherent in projecting the original points onto the plane. The main assumption being that the road is not angled forward or backward. Even if the line as a whole has flat areas, lines drawn between close points may be heavily sloped - see figure 5.8.

(37)

5.2. Roads 29

Figure 5.5: Road scan-line

Figure 5.6: Projecting LiDAR point onto the scan line

A solution to removing noise is to resample the points on the plane.

The plane is divided into n sections, the first and last sections having half the width of the others. n is chosen to maximize noise-reduction yet preserve detail - here chosen so that most sections cover several points. A new point is created at the horizontal center of each section, having the height component

(38)

Figure 5.7: LiDAR data of a road projected onto a cross-section plane

Figure 5.8: LiDAR data of a road projected onto a cross-section plane

calculated as the mean height of all points inside the section. Resampling the points removes the noise, while sacrificing some detail - see figure 5.9.

This trade-off is deemed justifiable, as it allows us to algorithmically analyze the road cross-section as a series of equally wide lines.

Figure 5.9: Resampled LiDAR points on a cross-section plane

We can now draw lines between the points, describing the shape of the cross-section. Using our assumption that the roadway should be approximately flat, significant elevation changes should separate the roadway from outside terrain, often exaggerated by ditching. We can find the absolute slope of each line to find the possible ditches. To determine if a sloping line slopes too much to still describe part of the roadway, we need to compare it to a reference slope. Instead of trying to find a magic number for this, the average absolute slope is calculated across the cross-section:

slope average = Pn

k=2|_k(P^P^k^z^−P^k−1^z

k,Pk−1)kxy|

n .

(39)

5.2. Roads 31

Figure 5.10 visualizes the cross-section again, with lines drawn between each point. In this visualization, the lines are colored red when their slope exceeds the average slope.

Figure 5.10: Roadway cross-section shape highlighted by excessive slope

Extracting roadway information from the cross-section is achieved by walking across the cross-section, building up a roadway candidate by storing the left point of the first flat line, and traversing lines to the right until an ex- ceedingly sloping line is encountered. The left point of the sloping line is used as the right side of the roadway. If the roadway candidate is wide enough, it is kept for the next step. The algorithm is further described in listing 5.1

(40)

Listing 5.1: Finding semi-flat line sequences

1 i n l i n e d o u b l e s l o p e (c o n s t V e c t o r 3 d& a , c o n s t V e c t o r 3 d& b ) {

2 r e t u r n ( b . z − a . z )

3 /

4 ( V e c t o r 2 d ( b . x , b . y ) − V e c t o r 2 d ( a . x , a . y ) ) . l e n g t h ( ) ;

5 }

6

7 v e c t o r <R o a d S e c t i o n > s e c t i o n C a n d i d a t e s ;

8 V e c t o r 3 d ∗ s t a r t = &p o i n t s [ 0 ] ;

9 f o r(i n t i = 0 ; i < ( p o i n t s . s i z e ( ) − 1 ) ; i ++)

10 {

11 c o n s t s i z e t i d x c u r r e n t = i ;

12 c o n s t s i z e t i d x n e x t = i d x c u r r e n t + 1 ;

13

14 d o u b l e l i n e s l o p e = f a b s ( s l o p e ( p o i n t s [ i d x n e x t ] ,

15 p o i n t s [ i d x c u r r e n t ] ) ) ;

16 i f( l i n e s l o p e > s l o p e a v e r a g e )

17 {

18 i f( s t a r t != &p o i n t s [ i d x c u r r e n t ] )

19 {

20 c o n s t V e c t o r 3 d a = ∗ s t a r t ;

21 c o n s t V e c t o r 3 d b = p o i n t s [ i d x c u r r e n t ] ;

22 s e c t i o n C a n d i d a t e s . e m p l a c e b a c k ( a , b ) ;

23 }

24 s t a r t = &s h a p e [ i d x n e x t ] ;

25 }

26 }

When all roadway candidates have been extracted from the cross-section, the best candidate is determined and, if good enough, kept. Figure 5.11 provides visualization of the best candidate, extracted using the algorithm outlined above.

Figure 5.11: Highlighted roadway cross-section annotated with roadway guess

The best candidate is selected by primarily comparing the length of the

(41)

5.2. Roads 33

candidate, but also taking into account elevation differences between candidates - the roadway is often elevated above other terrain. The elevation is not weighted very highly, however, as this assumption does not always hold.

Once best candidates have been extracted, the list of candidates consti- tute a crude approximation of a road. The list is then filtered to remove obviously inaccurate candidates, and is then smoothed by moving each midpoint to a weighed average of the surrounding midpoints. The smoothing is described further in code listing 5.2

Listing 5.2: Smoothing road curvature

1 Road smooth ( Road i n p u t )

2 {

3 Road r e s u l t ;

4 f o r( s i z e t i = 0 ; i < i n p u t . s i z e ( ) ; i ++)

5 {

6 c o n s t s i z e t i d x s t a r t = max ( i − 3 , 0 ) ;

7 c o n s t s i z e t i d x e n d = min ( i + 3 , i n p u t . s i z e ( ) − 1 ) ;

8 c o n s t s i z e t n u m s a m p l e s = i d x e n d − i d x s t a r t + 1 ;

9

10 V e c t o r 3 d sum ( 0 , 0 , 0 ) ;

11 f o r( s i z e t j = i d x s t a r t ; j <= i d x e n d ; j ++)

12 {

13 sum += i n p u t [ j ] ;

14 }

15 // C a l c u l a t e and i n s e r t a v e r a g e p o i n t

16 r e s u l t . e m p l a c e b a c k ( sum / s t a t i c c a s t<d o u b l e>( n u m s a m p l e s ) ) ;

17 }

18

19 r e t u r n r e s u l t ;

20 }

The road section midpoint lists are combined into a single road shape by simple list concatenation, and the detected width of the sections are averaged and applied to the road as a whole. The midpoints of a road are then used to construct a Catmull-Rom spline, which smoothly interpolates each midpoint.

By using a spline, additional curvature is introduced to the road mesh. The curvature is artificial, but justifiable as roads are typically curved rather than jagged.

The use of splines also allows us to trivially create the side edges of the road mesh, by giving semantic meaning to the concepts of left and right for each midpoint. Points on the spline are chosen, and on each point the velocity (or current direction) of the spline is rotated 90 degrees along the

(42)

XY plane. The resulting direction vector can be used to create points right and left of the point.

The left and right points are extended to have the average road width of the road, and a few complementary points are added outside and below the edge points to emulate the ditching. When there is no ditching in the terrain mesh, this will not be visible as the meshes intercept each other. Each set of curvature-defining points are then triangulated together with neighboring sets, producing the road mesh - see figure 5.12.

Figure 5.12: Road mesh produced by the road generator

(43)

Chapter 6 Evaluation

In this chapter, the prototype is evaluated. First, the evaluation method is described. Next, results are presented, paired with objective observations.

Lastly, the results are discussed with regards to what they achieve and what they fail to achieve.

6.1 Method

The prototype has been continually evaluated on the following aspects:

Terrain quality Loosely, to what degree the terrain is appropriate for use with regards to it’s aesthetic properties.

Road detection accuracy The accuracy of LAS-guided road detection, visually evaluated against the orthophotograph used as a texture.

Road generation quality Loosely, to what degree the roads are appropriate for use with regards to both its geometric properties and it’s quality in physics computations. No texturing and shading has been done - we only look to analyze how well the geometry fits with the surrounding terrain and how flat it is.

Evaluation of quality and accuracy is not numerical, yet the results can readily be visually verified by a knowledgeable reader.

35

(44)

36 Chapter 6. Evaluation

6.2 Results

Figure 6.1 shows generated terrain reproducing a typical northern swedish forest environment. No graphical artifact or blemish is visible at this distance, and the texture seems to fit the shape of the terrain.

Figure 6.1: Result: Forest terrain

Figure 6.2 shows the same terrain at a different angle. Here the percep- tible viewer will get a feeling of flatness for many areas which should not be flat, such as the forest. Additionally, there is some texture stretching visible on steep part of the bluff.

(45)

6.2. Results 37

Figure 6.2: Result: Forest terrain at another angle

Figure 6.3 shows a terrain with fields and a road. The flatly projected buildings are obvious.

Figure 6.3: Result: Farm land terrain with roads

Figure 6.4 shows the generated terrain of a mining site. The detail resolution is high enough to describe the curving paths down into the mining pit, and the texture further accents the detail to make it stand out. On the next figure (6.5) however, which is zoomed in, texture stretching and shadow

(46)

baking are very clearly featured.

Figure 6.4: Result: Mining site terrain

Figure 6.5: Result: Baked shadows and stretching

Figure 6.6 depicts the same area, but outside of the mining pit. Here we can see buildings projected onto flat terrain, breaking any potential illusion of realism.

(47)

6.2. Results 39

Figure 6.6: Result: Flatly projected buildings

Figure 6.7 visualizes road midpoints extracted by the road detection technique. Evidently, the points form a smooth line, and accurately describe the middle of the road.

Figure 6.7: Result: Road centerline detection visualized

Figure 6.8 shows another angle of visualized results of road-dection. All points are on the road. We can observe ”gaps” where the detection has failed to produce good-enough candidates, instead filtering those segments, leaving

(48)

them to be spline-interpolated later on.

Figure 6.8: Result: Birds-eye visualization of detected road

Figure 6.9 shows the result of road detection going past a junction. The resulting points, when not filtered, tend towards the turnoff.

Figure 6.9: Result: Road detection at junction

Figure 6.10 depics the results of a heavily inaccurate road detection. The surrounding area is presumably very flat, and the road detector found and

(49)

6.2. Results 41

kept many false positives, extracting a significant number of road segments from non-road terrain.

Figure 6.10: Result: Road detection at junction close to fields

Figure 6.11 shows a raw view of the generated geometry of a straight road. The edges of the road seem to accurately follow the edges of the road in the terrain. The road geometry is also very flat.

Figure 6.11: Result: Generated road stretch

Figure 6.12 shows the generated geometry of a slowly curving road. We can observe a sense of smoothness in the curving. We can also observe the overlap between the road geometry and the terrain in the near ditch. The visible depth of the road geometry varies.

Figure 6.13 shows the generated geometry of the points visualized in figure 6.9. The geometry shows a very abrupt change in direction.

(50)

Figure 6.12: Result: Generated non-linear road

Figure 6.13: Result: Generated road at junction

6.3 Discussion

The texture defects - flatly projected houses, texture stretching and baked shadows - prevents the terrain from looking realistic in many cases. This is an inherent characteristic of using Orthophotographs directly for texturing.

Another problem with the texture is the visibly low resolution, causing pixels of the texture to span up to several square meters. These flaws combined suggest that moving towards alternative texturing solutions would be a better option. Instead of using orthophotographs directly, the image data could be processed to increase detail and erase flaws. This could be achieved using

(51)

6.3. Discussion 43

methods outlined in chapter 3.

The road detection technique works very well in the general case. Roads, especially straight ones, are found with a high accuracy. However, it does have a noticeable rate of false positives for road cross-sections and junctions.

An especially difficult situation is exemplified in figure 6.9, where the algorithm treats the joining junction as the same road as is currently being extracted, resulting in the detection of a locally wider road. The failure is due to the candidate filtering, which is trying to both minimize false positives, but at the same time minimize unnecessarily filtered candidates. By simply making it stricter we would get more false negatives, which means we would have less detail of the extracted road. This can become a problem in tight road curves, where a discarded candidate can move the resulting road several meters.

As can be seen in figure 6.13, the result of extracted roads with sharp direction changes is a jagged geometry. The cause of this is that the generated polygons are based on the originally extracted midpoints of the roads, which means gaps in detection are represented in the length of the polygons. A better solution would be to resample points on the spline to produce smoother, equidistant points to base the mesh generation on.

(52)

(53)

Chapter 7 Conclusion and future work

This thesis intended to explore to what extent a 3D environment can be automatically generated using GIS data, in the context of Oryx’s simulation platform.

A number of GIS data types have been described in chapter 3 including outlining their strengths and weaknesses, how they are represented, and what they can be used for in our context. LiDAR data has been shown to be especially interesting due to its wealth of detail and relative ease of ac- quisition. Road data has been shown to be too inaccurate to use for real-life scale applications.

A prototype has been implemented inside an existing code base to evaluate and demonstrate the merits of GIS-driven automation and environment generation. The prototype uses DEM height data, orthophotographs, road vector data and LiDAR point cloud data to produce a textured terrain and processed road geometries.

The terrain quality itself is satisfactory, but the texturing using orthophotography is not. There are multiple unavoidable flaws in using it directly for texturing, including baked shadows, texture stretching and the inclusion of non-flat objects like buildings and vehicles. The conclusion is to move away from using Orthophotography directly in the end result, instead using it in a secondary fashion where it’s fed to the control and input of procedural texture generators. Using orthophoto texturing is a major aid during development, however, as it allows the programmer to trivially find positional inaccuracies.

A novel technique for LiDAR-based road extraction has been developed and demonstrated as part of the prototype. The technique exploits the typ-

45

(54)

46 Chapter 7. Conclusion and future work

ical cross-section shape of roadways to extract candidate roadway points. It does this by:

1. Compressing volumes of LiDAR points into planes, 2. Resampling the resulting shapes,

3. Finding level lines by comparing line slopes with the overall average slope,

4. Picking the best line using a heuristic based on line length, 5. Filtering unlikely candidates to reduce error,

6. Applying a smoothing interpolation based on a weighted average to the midpoints to reduce noise.

Overall, this works well, but the filtering may need improvement.

Drawing from the paper Smadja et al [21], the Random sample consensus (RANSAC) algorithm could be investigated as a means of better filtering.

RANSAC is an iterative error-minimizing algorithm for sets of data, where sets of points are picked to try to minimize error. The challenge, then, would be to invent a good error heuristic for our use case. There is also a performance consideration, as there is no upper bound on the execution time of RANSAC.

An alternative to perfecting the filtering and smoothing of detected road candidates is to break up the technique into a semi-automated process, where humans could correct mistakes in the input data before detection begins, and later correct detected road points before the road generation begins. This would result in a process where the computer still does the repetetive, heavy lifting, but the human can aid the computer in tasks that humans are, at least at the time of writing, better at.

Yet another alternative to improving the filtering would be to improve the detection. LiDAR data in the LAS format includes reflection instensity. The intensity for reflections off roads seem to adhere to certain characteristics, as can be seen in figures 4.2 and 5.4. Exploring these characteristics, and possibly incorporating them into the detection technique, would be interesting.

(55)

Chapter 8 Acknowledgements

I’d like to thank Fredrik Sandstr¨om, my supervisor at Oryx, for the invaluable help, input, and guidance during the project.

I’d also like to thank my university supervisor Jan-Erik Mostr¨om for giving support and advice, and sharing knowledge I would otherwise have gone without.

Last, I would like to thank my partner, Elin Swartling, for both the emo- tional support during times of doubt, and for sharing some of her extensive experience with writing scientific texts.

47

(56)

48 Chapter 8. Acknowledgements

(57)

Bibliography

[1] Borut ˇZalik. An efficient sweep-line Delaunay triangulation algorithm.

Computer-Aided Design, Volume 37, Issue 10, 2005. [Online;

downloaded 6-February-2015].

[2] Edward Angel. Interactive Computer Graphics: A top-down appreaoch with OpenGL^TM. Addison-Wesley, second edition, 2000.

[3] ASPRS. LAS Specification version 1.4 - R13. http://www.asprs.org/

a/society/committees/standards/LAS_1_4_r13.pdf. Accessed:

2015-04-20. (Archived by WebCite atR

http://www.webcitation.org/6Xvebat0B).

[4] Emmanuel P. Baltsavias. Digital ortho-images — a powerful tool for the extraction of spatial- and geo-information. ISPRS Journal of Photogrammetry and Remote Sensing, 51(2):63 – 77, 1996.

[5] Christopher Beasy. Lidar Mapping: High Accuracy, High Speed.

http://www.eaglemapping.com/_white_papers/Lidar%20WPaper%

20ENG%20-%20Mar08.pdf. Accessed: 2015-04-24. (Archived by WebCite at http://www.webcitation.org/6Y1VsyVeY).R

[6] Michael N. Demers. Fundamentals of Geographic Information Systems.

John Wiley & Sons, third edition, 2005.

[7] ESRI. ESRI Shapefile Technical Description. https:

//www.esri.com/library/whitepapers/pdfs/shapefile.pdf.

Accessed: 2015-05-13. (Archived by WebCite at^R http://www.webcitation.org/6YUgYkU86).

49

(58)

50 BIBLIOGRAPHY

[8] Igor V. Florinsky. Chapter 3 - digital elevation models. In Digital Terrain Analysis in Soil Science and Geology, pages 31 – 41. Academic Press, 1st edition, 2012.

[9] Alberto Holgado-Barcoa, Diego Gonzalez-Aguileraa, Pedro Arias-Sanchezb, and Joaqu´ın Martinez-Sanchez. An automated approach to vertical road characterisation using mobile LiDAR systems: Longitudinal profiles and cross-sections. ISPRS Journal of Photogrammetry and Remote Sensing, Volume 96, 2014. [Online;

downloaded 2-May-2015].

[10] Howard Butler and Martin Daly and Allan Doyle and Sean Gillies and Tim Schaub and Christopher Schmidt. The GeoJSON format

specification. http://geojson.org/geojson-spec.html. Online;

Accessed: 2015-05-13.

[11] George Kelly and Hugh Mccabe. A survey of procedural techniques for city generation. ITB Journal.

[12] Sergejs Kodors, Aivars Ratkevics, Aldis Rausis, and Jazeps Buls.

Building Recognition Using LiDAR and Energy Minimization

Approach . Procedia Computer Science, 43:109 – 117, 2015. {ICTE} in Regional Development, December 2014, Valmiera, Latvia.

[13] Pankaj Kumar, Conor P. McElhinney, Paul Lewis, and Timothy McCarthy. An automated algorithm for extracting road edges from terrestrial mobile LiDAR data. ISPRS Journal of Photogrammetry and Remote Sensing, Volume 85, 2013. [Online; downloaded 2-May-2015].

[14] Land Information New Zealand. World Geodetic System 1984 (WGS84). http://www.linz.govt.nz/data/geodetic-

system/datums-projections-heights/geodetic-datums/world- geodetic-system-1984-wgs84. Accessed: 2015-04-20. (Archived by WebCite at http://www.webcitation.org/6XvVEYnGW).^R

[15] Sk. Sazid Mahammad and R. Ramakrishnan. GeoTIFF - A standard image file format for GIS applications.

http://www.gisdevelopment.net/technology/ip/mi03117pf.htm.

Accessed: 2015-05-15. (Archived by WebCite at^R http://www.webcitation.org/6YXlTCa0S).

Automating 3D graphics generation using GIS data - Terrain and Road reproduction