Future Work

This research focusses the FGAS data model and its spatial analysis operations. However, a geometry implementation is a complex task which involves many aspects. Many issues had to be limited from the start due to the time limit for this thesis, but deserve of further research.

• Implementation of the missing operators: This work does not support all operations specified by the FGAS for the selected data types. These should be implemented. Specially the complex and aggregate classes still need work.

• Implementation of 3d operations: This implementation provides most of the operations for 2d data only, because algorithms for 3d data are vastly more different and complex. The long-term objective of this implementation is to support complete analysis of 3d data.

• Implementation of missing data types: The FGAS defines a large diver- sity to represent geometric objects such as Splines or Béziers to represent curve segments. At that time, the only curve segment implementation is the LineString. However, due to the clear hierarchy of the data model, curve segments can be easily exchanged. Those objects could be implemented to enhance the implementation’s capabilities to represent the real world’s enti- ties more realistically.

• Topology: The FGAS specifies a set of objects to represent an internal topol- ogy. Topology brings great performance to many spatial operations.

• Storage and Persistence: The suggestions made in this thesis to store data in files or databases are not the only possibilities of persistence. Further research in this area could discover more efficient, maybe standardized approaches.

• I/O support: The instantiation of the geometric objects can be performed directly from other sources such as files in standardized format. The Geo- graphic Markup Language (GML) is a promising standard, based on the

FGAS data model. The adoption of this model can realize the direct instanti- ation based on GML data.

• Practice oriented operations: In practice, there are many typical spatial oper- ation which should be supported better by the underlying geometry model. An overlay for more than two geometries is one example: Many GIS appli- cations support overlaying more than two layers. However, most data mod- els’ operations are binary, i.e. they only support the operation between two objects. The support of more than two geometries at the same operation call would be a great performance benefit for these functions. Due to the struc- ture of the overlay algorithm, an overlay of three or more geometries (instead of only two) is possible in little extra time. Developers of the JTS community already reported their interest in this idea in the JTS developer mailing list jts-devel. This shows the relevance in practice.

Some of these points have already gained interest. A french research group of the University of Provence in Arles and the LSIS CNRS Laboratory pronounced their interest in the implementation of missing 3d operations in order to use the implementation in their project. They are specialized in 3d data modelling and operations and are already involved in the evaluation of such operations.

Appendix A

Glossary

2.5d two and a half dimensional 3d two dimensional

API Application Programming Interface CAD Computer aided design

CAM Computer aided manufacturing ccw counter clockwise

CG Computational Geometry

CORBA Common Object Request Broker Architecture CRS Coordinate Reference System

cw clockwise

DCEL Doubly-Connected Edge List DCP Distributed Computing Platform

DE-9IM Dimension extended 9-Intersection-Matrix DEM Digital Elevation Model

DGIS Distributed GIS DTM Digital Terrain Model

EU European Union

FGAS Feature Geometry Abstract Specification FTP File Transfer Protocol

GIS Geographic Information System GML Geographic Markup Language GNU General Public License

GUI Graphical User Interface

IEEE Institute of Electrical and Electronics Engineers ISO International Organization for Standardization

ISO/OSI ISO Open Systems Interconnection Basic Reference Model IT Information technology

JDK Java Developer Kit JVM Java Virtual Machine

LGPL GNU Lesser General Public License

MB Minimum Bounding; usually the minimum bounding region OGC Open Geospatial Consortium

OLE Object Linking and Embedding OMG Object Management Group OMI Object Model Interface oo Object oriented

OS Operation system

SF Simple Feature Geometry

SFS Simple Feature Geometry Implementation Specification SQL Structured Query Language

SRS Spatial Reference System SCID Spatial component identifiers

TCP/IP Transmission Control Protocol/Internet Protocol TELNET Teletype Network

Tin Triangle Irregular Network W3C World Wide Web Consortium XML Extensible Markup Language

Appendix B

Technical definitions

TheIEEE Standard 754-1985 for Binary Floating-Point Arithmetic[P7585] is the most accepted standard of floating-point computation by hardware-manufacturers. The standard requires that the results of+,−,·and√ are exactly rounded according to a chosen rounding mode. Rounding to the nearest (LSB1becomes zero), round- ing toward zero, rounding toward ∞ and rounding toward −∞ are rounding modes which have to be supported.

Intention of the development of this standard was the different hardware behaviour on elementary floating-point operations. Usually, source code which does not behave equally on different machines is not useful. The IEEE floating- point standard guarantees machine-independent results on basic operations and thereby makes code portable.

The standard specifiesfloating-point computation single,single extended,doubleand double extendedprecision. Single precision can store a 32-Bit word with a mantissa lengthl = 24and an exponent range of[−126..127]. Double precision stores two consecutive 32-Bit words with a mantissa lengthl= 53and an exponent range of [−1022..1023]. Thus, the relative errors are bounded by2−24and2−53.

Monotone Chains.

Monotone chainsare a technique to gain computational performance in many spa- tial operations without bringing a lot more complexity to the code. The set of all line segments is divided into monotone chains of connected segments. A mono- tone chain has two important characteristics:

Figure B.1:Examples of Monotones Chains (from [viv03b])

• Non-Intersection Property: the segments within a monotone chain do not intersect.

• Endpoint Envelope Property: the envelope of any continuous subset of the segments in a monotone chain is the envelope of the endpoints of the subset. Based on this rules, monotone chains bring effective advantages: There is no need to search intersections within a monotone chain. Therefore, the number of intersection tests decrease drastically. Furthermore, a binary search can be used to find intersections along the monotone chain (see figure B.1 (b)). In practice, monotone chains often result in great performance wins. A further documentation of this technique can be found in [viv03b].

Polynomial expression.

Expressions with a finite number of constants and variables combined using only the operations Addition, Subtraction, Multiplication and non-negative whole number exponents, i.e. raising to a power.

For example:

3·x4·y·z3−3·y2−5

is a polynomial expression. But

3 1 +x2

Appendix C

Notations

Class attributes object1.attribute1:

This notation refers to the value of the attributeattribute1of objectobject1. object1.method1():

Appendix D

Implementation Overview

This Appendix gives an overview of the implemented classes and methods, spec- ified by the ISO19107 and the GeoAPI.