Evaluation of .NET API:s for Reading and Writing MicroStation V8

Evaluation of .NET API:s for Reading and Writing

MicroStation V8 Design Files to and from Spatial Databases

N E L L I E G H A S S E M I N O

Master of Science Thesis Stockholm, Sweden 2006

Evaluation of .NET API:s for Reading and Writing

MicroStation V8 Design Files to and from Spatial Databases

N E L L I E G H A S S E M I N O

Master’s Thesis in Computer Science (20 credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2006 Supervisor at CSC was Kjell Lindqvist Examiner was Stefan Arnborg TRITA-CSC-E 2006:147 ISRN-KTH/CSC/E--06/147--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

Abstract In the world of CAD and GIS there is a growing need for storing spatial information in neutral contexts. Storing the information in a database rather than in files gives rise to greater options concerning what can be done with the information. Being able to perform analyses on spatial information is an area of interest for many companies. In particular since analyses provide foundations for planning and modelling infrastructure. The main purpose of the evaluation in this thesis is to function as a feasibility study for the planning and development of an independent .NET code library that would update and simplify the currently scattered conversion process at TietoEnator. The current conversion process only converts V7 design files into a spatial database. An independent .NET code library that reads and writes the new V8 version of design files would not only update the conversion but also reduce the current costs of the conversion process and help re-modelling it in a way that would enable future development of GIS functionality into current web applications, which depend on the data in the design files.

On commission by TietoEnator AB, this thesis has therefore evaluated four different .NET application programming interfaces (API:s) used for reading and writing the MicroStation V8 CAD file format called design files. The first part of the evaluation dealt with the API:s FME Objects .NET by Safe Software and DGNdirect Toolkit by Open Design Alliance. They are used for reading and writing V8 design files. The other two API:s that were dealt with in the second part of the evaluation are called ODP .NET by Oracle and Npgsql by PostgreSQL. They are data providers that are used for insertion and extraction of data to and from databases.

The evaluation was based on specific criteria and on the experiences from the implementation of test applications for each API.

DGNdirect Toolkit proved to be the best suited API in the first part of the evaluation and is better suited to function as a basis for the reading and writing functionalities of the independent .NET components. The recommendation of DGNdirect toolkit is mainly based on its independence from other software, the advantageous lack of costs and the specialization on the V8 file format.

FME Objects is heavily dependent on other FME products and is therefore not independent. Furthermore, FME Objects is better suited for reading design files when the data schema of the content is known in advance, for example in conversion between two FME supported formats. The need to know the schema of the data in advance would be a disadvantage in a large conversion process where with hundreds of files involved. FME Objects does offer special licenses for conversion of design files directly into the spatial databases Oracle Spatial and PostGIS by PostgreSQL.

However, those licenses are very expensive and since DGNdirect Toolkit does the job, it was a rather simple choice. The second part of the evaluation showed that ODP .NET by Oracle is better suited than Npqsql for building the .NET code library upon. The recommendation of ODP .NET was mainly affected by greater reliability of the supplier and excellent documentation and support. Furthermore, Oracle spatial is currently being used by TietoEnator. Changing database vendor is a costly process and has to be worth the money and the effort. Functionality wise Npgsql is not superior ODP .NET and the insufficient documentation and support of Npgsql made ODP .NET a more suitable choice in this matter.

Utvärdering av .NET-API:er för läsning och skrivning av V8-designfiler till och från spatiala databaser

Sammanfattning Inom CAD- och GIS-området finns ett växande behov av att lagra spatial information i neutrala lagringssystem. Att lagra sådan information i spatiala databaser istället för i filer i filsystemet ökar möjligheterna för vad informationen kan användas till. Att genomföra analyser baserade på den spatiala informationen är av stort intresse för många företag som arbetar med GIS. Detta beror i synnerhet på att möjligheten att analysera spatial data är en grund för planering och modellering av infrastrukturen.

Huvudsyftet med examensarbetet har varit att det ska vara en förstudie för planering av utveckling av ett oberoende .NET-kodbibliotek för att uppdatera och förenkla den nuvarande konversionsprocessen. TietoEnator konverterar varje natt CAD-filer i form av V7-designfiler till en spatial databas för att ge .NET-webbapplikationer tillgång till informationen. Ett oberoende kodbibliotek med stöd för att läsa och skriva V8-designfiler skulle ge TietoEnator möjlighet att även konvertera sådana filer samt reducera kostnaderna för konversionen genom att samla allt arbete i en och samma .NET-mijö. Dessutom skulle en sådan lösning möjliggöra framtida utbyggnad av dagens webbapplikationer till att även hantera GIS-funktionalitet.

Examensarbetet utreder vilka kodbibliotek (API:er) som lämpar sig bäst för att konvertera V8-designfiler samt ligga till grund för utvecklingen av ett oberoende .NET-API. Utvärderingen har delats in i två delar. Den första delen har utrett två kodbibliotek som är tänkta att hantera läsning och skrivning av V8-designfiler i .NET; FME Objects .NET av Safe Software och DGNdirect Toolkit av Open Design Alliance. Den andra delen av utvärderingen jämförde två kodbibliotek som används för att läsa och skriva från databaser; ODP .NET av Oracle och Npgsql av PostgreSQL.

Utgångspunkten i utvärderingen var ett antal specifika kriterier som varje API bör uppfylla. Dessutom har även testapplikationer implementerats för att ytterligare få en bild av kodbibliotekens lämplighet.

Resultaten från första delen av utvärderingen visade att DGNdirect Toolkit lämpar sig bäst för hantering av V8-designfiler. Rekommendationen baseras främst på att DGNdirect Toolkit är ett fristående API utan beroenden till annan mjukvara. Dessutom vägde det fördelaktiga priset (gratis!) samt att det är specialiserat på V8-formatet in i beslutet. FME Objects är beroende av annan mjukvara samt är inte specialiserat på enbart V8-designfiler. Vidare är det mycket svårt att med FME Objects läsa och skriva designfiler i situationer då dataschemat inte är känt i förväg. Behovet att känna till hur datat ser ut innan det läses är en nackdel vid konvertering av stora mängder data.

Den andra delen av utvärderingen visade att ODP .NET är bättre lämpad än Npgsql för att bygga oberoende .NET-komponenter med. Valet av ODP .NET beror främst på bättre pålitlighet och utmärkt dokumentation och support. Dessutom används Oracle Spatial för närvarande av TietoEnator för att lagra spatial data. Ett byte av databashanterare måste vara värt kostnaderna och mödan. Funktionsmässigt är Npgsql inte bättre än ODP .NET. Den sparsamma dokumentationen av Npgsql och den begränsade supporten är ytterligare skäl till att välja ODP .NET.

Acknowledgements This report summarizes a master thesis project at the School of Computer Science and Communication at the Royal Institute of Technology, on the commission of TietoEnator AB (Telecom & Media, Web & GIS Solutions) in Sweden. The project comprises 20 academic points and is the concluding part of a master’s degree in computer science. Supervisor at the School of Computer Science has been Kjell Lindqvist and the supervisor at TietoEnator was Claes-Göran Boström.

I would like to take the opportunity and thank both Kjell Lindqvist and Claes-Göran Boström for their support throughout the project. Furthermore, I would also like to thank Åke Wikner at TietoEnator for making this work possible.

Table of Contents 1 Introduction................................................................................................................................ 1

1.1 Background Theory............................................................................................................. 1 1.1.1 CAD ............................................................................................................................. 1 1.1.2 GIS ............................................................................................................................... 1 1.1.3 Storage in GIS.............................................................................................................. 3

1.1.3.1 First Generation of GIS......................................................................................... 4 1.1.3.2 Second Generation GIS......................................................................................... 5 1.1.3.3 Third Generation GIS............................................................................................ 6

1.1.4 Areas of Usage ............................................................................................................. 7 2 Problem Background and Definition ......................................................................................... 8

2.1 TietoEnator AB ................................................................................................................... 8 2.1.1 Problem Definition....................................................................................................... 8 2.1.2 The Current Situation................................................................................................. 10 2.1.3 Future Plans................................................................................................................ 11

2.2 Purpose.............................................................................................................................. 12 2.3 Method Description........................................................................................................... 14 2.4 Requirements for Reading and Writing Design Files ....................................................... 15 2.5 Requirements for Reading and Writing to/from Databases .............................................. 17 2.5 Software ............................................................................................................................ 20 2.6 Delimitations..................................................................................................................... 20

3 MicroStation V8....................................................................................................................... 21 3.1 New Features in V8........................................................................................................... 22

4 Spatial Databases - DBMS with spatial extensions ................................................................. 23 4.1 Background ....................................................................................................................... 23

4.1.1 DBMS ........................................................................................................................ 24 4.1.2 Spatial Data Types ..................................................................................................... 25 4.1.3 Spatial Operators in Extended DBMS ....................................................................... 25

4.2 Oracle and PostgreSQL Representation of Spatial Data ................................................... 26 4.2.1 Oracle Spatial ............................................................................................................. 26

4.2.1.1 Oracles Geometric primitive types...................................................................... 27 4.2.1.2 Oracle Spatial Elements ...................................................................................... 27 4.2.1.3 Geometry............................................................................................................. 29 4.2.1.4 Spatial Operators................................................................................................. 29

4.2.2 PostgreSQL and PostGIS ........................................................................................... 30 4.2.2.1 PostGIS Geometric Types................................................................................... 30

4.2.2.2 Spatial Functions and operators .......................................................................... 31 5 API Introduction ...................................................................................................................... 32

5.1 ODP .NET......................................................................................................................... 32 5.1.1 ODP.NET Types ........................................................................................................ 32

5.2 Npgsql ............................................................................................................................... 34 5.2.1 Npgsql Types ............................................................................................................. 35

5.3 Safe Software .................................................................................................................... 35 5.3.1 FME Objects .NET .................................................................................................... 36

5.3.1.1 FME Features ...................................................................................................... 36 5.3.1.2 Reading Features................................................................................................. 36 5.3.1.3 Writing Features.................................................................................................. 37 5.3.1.4 IGDS Reader and Writer for Design Files .......................................................... 37 5.3.1.5 IGDS Reader ....................................................................................................... 37 5.3.1.6 IGDS Writer ........................................................................................................ 38 5.3.1.7 FME Igds_type.................................................................................................... 38

5.4 Open Design Alliance ....................................................................................................... 39 5.4.1 DGNdirect Toolkit ..................................................................................................... 39

5.4.1.1 DGNdirect Representation of Lists ..................................................................... 40 6 Evaluation Part I....................................................................................................................... 42

6.1 FME Objects .NET – Test Applications ........................................................................... 43 6.1.1 Implementation of Test Applications......................................................................... 43 6.1.2 Reading from a Design File ....................................................................................... 43 6.1.3 Writing to a Design File............................................................................................. 44

6.2 Evaluation of FME Objects .NET..................................................................................... 47 6.2.1 Compatibility with .NET............................................................................................ 47 6.2.2 Independence ............................................................................................................. 47 6.2.3 Reliability................................................................................................................... 47 6.2.4 Documentation ........................................................................................................... 47 6.2.5 Development Support................................................................................................. 47 6.2.6 Licence Costs ............................................................................................................. 47 6.2.7 Support for reading V8 design files ........................................................................... 47 6.2.8 Functionality for Writing to a V8 Design File and Creating New Design Files ........ 48 6.2.9 Support for Representing MicroStation V8 Elements................................................ 48 6.2.10 Support for Server-Client Architecture .................................................................... 48

6.3 DGNdirect Toolkit – Test Applications ............................................................................ 49 6.3.1 Implementation of Test Applications......................................................................... 49 6.3.2 Reading from a Design File ....................................................................................... 49

6.3.3 Writing to a Design File............................................................................................. 50 6.4 Evaluation of DGNdirect Toolkit...................................................................................... 52

6.4.1 Compatibility with .NET Environment...................................................................... 52 6.4.2 Independence ............................................................................................................. 52 6.4.3 Reliability................................................................................................................... 52 6.4.4 Documentation ........................................................................................................... 52 6.4.5 Development Support................................................................................................. 52 6.4.6 Licence Costs ............................................................................................................. 52 6.4.7 Functionality for reading V8 design files................................................................... 52 6.4.8 Functionality for Writing to V8 Design Files and Creating New Design Files ......... 53 6.4.9 Support for Representing MicroStation V8 Elements................................................ 53 6.4.10 Support for Use in Server-Client Architecture......................................................... 53

7 Evaluation Part II ..................................................................................................................... 54 7.1 ODP .NET – Test Applications......................................................................................... 55

7.1.1 Implementation of Test Applications......................................................................... 55 7.1.2 Insertion ..................................................................................................................... 55 7.1.3 Extraction ................................................................................................................... 57

7.2 Evaluation of ODP .NET .................................................................................................. 58 7.2.1 Compatibility with.NET............................................................................................. 58 7.2.2 Independence ............................................................................................................. 58 7.2.3 Reliability................................................................................................................... 58 7.2.4 Documentation ........................................................................................................... 58 7.2.5 Development Support................................................................................................. 58 7.2.6 License Costs ............................................................................................................. 59 7.2.7 Support for Spatial Data Types and Representation of MicroStation Elements ........ 59 7.2.8 Support for Calling Stored Procedures and Functions ............................................... 60 7.2.9 Support for Use in Server-Client architecture............................................................ 60 7.2.10 Support for Datasets................................................................................................. 60 7.2.11 Support for Ref Cursors ........................................................................................... 60 7.2.12 Large Object Support ............................................................................................... 63 7.2.13 Support for Bind Variables ...................................................................................... 63

7.3 Npgsql – Test Applications............................................................................................... 65 7.3.1 Implementation of Test Applications......................................................................... 65 7.3.2 Insertion ..................................................................................................................... 65 7.3.3 Extraction ................................................................................................................... 66

7.4 Evaluation of Npgsql ........................................................................................................ 67 7.4.1 Compatibility with.NET environment ....................................................................... 67

7.4.2 Independence ............................................................................................................. 67 7.4.3 Reliability of Supplier ................................................................................................ 67 7.4.4 Documentation ........................................................................................................... 67 7.4.5 Development Support................................................................................................. 68 7.4.6 Licence Costs ............................................................................................................. 68 7.4.7 Support for Spatial Data Types and Representation of MicroStation Elements ........ 68 7.4.8 Support for Calling Stored Procedures and Functions ............................................... 68 7.4.9 Able to use in Server-Client Architecture .................................................................. 69 7.4.10 Support for Datasets................................................................................................. 69 7.4.11 Support for Ref Cursors ........................................................................................... 69 7.4.12 Large Object Support ............................................................................................... 70 7.4.13 Support for Bind Variables ...................................................................................... 70

8 Analysis.................................................................................................................................... 71 8.1 FME Objects vs. DGNdirect Toolkit ................................................................................ 71 8.2 ODP vs. Npgsql................................................................................................................. 73 8.3 Recommendations ............................................................................................................. 75 8.4 Conclusion ........................................................................................................................ 77 8.5 Future Outlook for .NET Components.............................................................................. 77

9 Appendix.................................................................................................................................. 78 References................................................................................................................................... 79

Literature................................................................................................................................. 79 Manuals................................................................................................................................... 80 Internet sources ....................................................................................................................... 82 Additional Sources .................................................................................................................. 84

Chapter 1 - Introduction

1 Introduction

1.1 Background Theory

Before introducing the problem that this report deals with, it is necessary to explain and elucidate common concepts that are important in order to comprehend the background and purpose of the project. This chapter will start by explaining CAD and GIS, focusing on how they relate to each other. Furthermore, the chapter will bring up the architecture of GIS’s and how it has evolved over time, which is essential for understanding the bigger picture surrounding the approach to the problem in this report.

1.1.1 CAD In order to grasp what constitutes a geographical information system, it is of interest to get introduced to the conception CAD, which stands for Computer Aided Design. CAD-programs are programs for construction and design of models that often can be applied to the reality. Modelling in CAD exclusively has a design purpose and CAD data only contains information about the appearance and position of geometries. The application MicroStation by Bentley is an example of a well-known CAD-tool where you can place elements and design CAD-drawings. Why is it so important to know about CAD one might ask? Well, construction of designs in CAD is directly related to the modelling used in today’s geographical information systems and it is important to separate those two when speaking of GIS. Historically, some GIS software packages have developed from CAD software. [A1]

1.1.2 GIS Our world can be explained as both spatial and temporal. Therefore, there is a need for information that has both dimensions, in order for us to make plans for future infrastructure. In a modern society there is a constant need for planning of new roads, cities, electrical networks etc. Future decisions rely upon properly collected, managed, distributed, analyzed, and presented spatial and temporal information. [11] A Geographic Information System (GIS) is a tool that assists us in making those decisions that concern civil infrastructure. [6]

A GIS can be explained as a system for creating, editing, managing, analyzing, and displaying geographic information. [11] For creating editing and displaying geographic data, CAD-based functionalities are used. Often the CAD functionalities are referred to as Mapping-tools. [A5] However, CAD-data is not enough when dealing with geographical information systems. Management and analysis of the data are parts that require structured ways to store and categorize the data and those parts are the parts that make data in a GIS different from pure CAD. [4] Unlike CAD, GIS software is used to manipulate datasets that are geographically referenced. As a consequence, GIS software is usually used with larger data sets and more complex data models than CAD software, since there is an analytical purpose behind GIS. In other words, the analysis possibilities that come with GIS are what make it interesting. [5]

By storing spatial data digitally in a GIS, you can simplify and analyze complex data for presentation in a foreseeable matter.

It is not a matter of course to say how a complex set of information about geographic objects should be interpreted and transferred to a database in order for a GIS to be able to use the data.

1


In the field of geographic information technology, useful data is descriptive data that gives as many characteristics of an object as possible. [7]

The characteristics of spatial data objects in GIS can be described as partly geometrical and partly topological. [6]

The information stored in a GIS is represented by a series of spatially referenced datasets. [I9] These datasets, which can be vector or raster based, are used to organize and manage geometrical and topological descriptions associated with various types of geographic features. [I6] Vector based data is geometrical data with geometrical properties and raster based data is simply images. [A2]

Geometrical properties are for example surface, length and position and these are a natural part in all geographic information. That kind of data is no more different than CAD-data.

As mentioned above, there is more to geometrical data than just the geometric aspects. The topological or non-spatial data is also a part of geometrical data and what makes the data useful in other ways. Topological data is attributes and details surrounding the geometrical objects, for instance the relationship between different elements and for how they are connected to each other. [6]

This brings us closer to the fact that data stored in GIS’s is very decisive to whether or not you can perform analytical queries on it, or not. The data stored in a GIS should therefore be multidimensional in order to make analysis possible. The term multidimensional in this context simply means that the geometrical data should have metadata that describes other aspects than just the geometry. [A3] For example, it might be interesting to know the voltage capacity of a cable, or perhaps how deep down into the ground it is placed. Those details add another dimension to the data, which facilitates queries that for example tell us how many low voltage cables with a thickness of 2 dm that exist 5 meters below the ground, in a certain area.

A GIS system consists of several smaller elements for handling different functionalities, which the system relies upon. [11] The mapping-tool that has its origin in CAD modelling is used to edit and manipulate geometries and attributes in the system. Presentation is another functionality required for visually presenting maps, diagrams and tables as results of analysis. This element is often integrated in the mapping-tool. [5] A GIS also needs an engine that performs analyses and interprets the spatial and topological data and statistics into results. To perform such analyses the engine uses a rule-base for how data should be interpreted, managed, stored and retrieved.

At the centre of a GIS is the database, which stores the spatial data. [6] By storing spatial data digitally in a GIS, it is possible to simplify and analyze complex data for presentation in a foreseeable matter.

One very important aspect of GIS is that it should be seen, just as the name indicates, as an information system. Therefore its purpose is mainly to act as a communication tool between different users. [4] Just as all information systems have a purpose to facilitate information exchange, both when it comes to user interfaces that are easily manageable, but also when it comes to the conceptual data models, so does the GIS. Recently, it has also become desirable for GIS’s to support universal data formats so that different programs can exchange information in different formats. [A1]

The architecture surrounding storage looks different for different GIS:s. Different GIS:s have their individual algorithms for reading spatial data. A problem with differences in data management between GIS-engines is that issues have been raised when companies change GIS

2


vendor and the data format in which the spatial data is stored. However, this is not so much depending on differences in design choices. It is more a result of the evolution of GIS over a time period of 15 years. [2]

1.1.3 Storage in GIS The GIS database can look in many ways. Some GIS’s have completely integrated databases; others store the data externally in files. A third type uses a database with references to files in an outside file system. In many GIS-programs the latter is a common method to handle map related data, mainly because of the fact that the database management has not been very satisfying when it comes to geometric data until recent years. Geographical information systems that have this kind of architecture are referred to as hybrid systems. [6]

3


1.1.3.1 First Generation of GIS

The early GIS architectures stored spatial data in external files in the file system. Therefore the data was only available for one GIS at a time which created a problem. The data input process was also time-consuming and conversion between different data formats was often necessary.

Figure 1 – First generation GIS [6]

GIS tools – Client software for managing spatial data.

GIS engine – Program that visualizes and analyses spatial data.

GIS API – Appplication library that interprets geometries in files.

4


1.1.3.2 Second Generation GIS

In the beginning of the 1980’s, GIS architectures started using relational databases in combination with external files to store the spatial data. Actually, the data was still stored in files but there was also a database manager (DBMS) involved. The difference was that the DBMS referenced the geometries in the files using SQL (Structured Query Language, a standardised language used for writing queries for relational databases) [13]. However, despite the use of a DBMS, this architecture still did not allow more than one GIS-engine at a time to access specific data. [6]

Figure 2 – Second generation GIS [6]

5


1.1.3.3 Third Generation GIS

The most recent architecture surrounding storage in GIS is the use of an integrated database.

Figure 3 – Third generation GIS that has a combined storage of files and an Object Relational DBMS. [6]

The integrated database approach, which is the most recent approach, is good to keep in mind since this project aims to investigate solutions that in the future will strive towards such GIS architecture where all CAD-data is converted into a spatial DBMS that supports GIS functionality. The integrated approach uses an extended object relational database management in combination with geometry descriptions in the file system. [6]

As this report will elucidate, the problem with conversion of data to or from different systems in the GIS area is very common since data exists in many formats and contexts. It often occurs that companies still store their data in CAD-files, as a result of staying in old patterns, and suddenly face the need to transform that data in another more universal format that can be used in a GIS. [11] The need for migration of such data into other more useful contexts is increasing and this report will shed some light upon parts of a rather complex migration and conversion process for TietoEnator.

6


1.1.4 Areas of Usage During the 1980’s the development of GIS was foremost done by commercial companies and the national defence of several nations. In the 1990’s the technical development of computer systems escalated and GIS became a more accessible technology. [6]

That has led to an upraise of new GIS related solutions in many areas such as database extensions for handling spatial data. The evolvement in GIS is probably a result of the general growth of the information society. [7] The latest trend among GIS vendors is the aim to standardise data formats in which spatial and geometrical data is stored. Today, a lot of energy is put into converting between different formats of different software suppliers. There are clear traces of the movement towards a standardised format. One sign of this is that many of the largest GIS vendors have expanded their range of formats, which their products can interpret. [11]

GIS is currently established as a tool in several business areas in Sweden and worldwide. The GIS on the Swedish market has had a focus on atomizing and rationalizing the production of maps as a support for documentation and visualization of technical supply systems such as electricity and telephone supply. [6] Many Swedish electricity and telephone network suppliers are using GIS solutions to plan and support new decisions concerning the networks. One example of an area where GIS is frequently being used in Sweden is for analysis and documentation of power networks in cities. A GIS can for example answer questions such as; how the power network is affected by changes of a certain expansion in the network. [A1]

7

Chapter 2 – Problem Background and Definition

2 Problem Background and Definition

2.1 TietoEnator AB TietoEnator AB is a corporation that is actively developing new IT solutions in several countries worldwide. The area that this project is concerned with is CAD and GIS-solutions for telephone networks processed by TeliaSonera AB. Every company that handles any form of spatial data is ultimately looking for GIS-solutions that enable analyzing of the data in order to effectively plan future decisions.

2.1.1 Problem Definition The TeliaSonera solution which TietoEnator is providing services for today does not have GIS functionalities since it is not a GIS solution. TeliaSonera’s data is purely CAD, which means that the data does not have the topological dimension which is needed for analytical purposes and for use in a GIS. CAD stands for Computer-Aided Design” and historically many GIS software originate from CAD software (See chapter 1.1.1). [A1] CAD systems primarily focus on buildings/structures and the creation of construction documents, GIS systems focus on geo-graphic (land-based) information and the analysis of that information as a basis for the design and assessment of civil infrastructure.

However, this does not mean that the TeliaSonera’s CAD data is useless. Today, the data is stored in design files and each night converted into another context, which is an Oracle database. This conversion process today only deals with V7 design files (DGN files), which are MicroStation CAD files. The current conversion process does not give access to data in real-time and it is expensive to maintain. If it was possible to access the data in real time instead of waiting for the nightly conversion to take place, current web applications could not only present updated information, they could also start expanding their functionalities and become more useful from an analytical point of view. In other words, TietoEnator could start adding GIS functionality to their applications.

There are two issues that this project will look upon. They are dealing with preparations for an update of a current conversion process to be able to convert the latest version of MicroStation DGN files, V8. In addition to that, the results from this project will support finding a solution for simplification of the currently scattered conversion process. The simplification would be a result of limiting the conversion process to .NET, with help from an independent .NET code library. This would also increase the flexibility for other external applications that are depending on data in the design files.

One of TietoEnator’s customers, TeliaSonera AB, is currently using different web applications that deal with spatial data that originally comes from an application called IGS-T. IGS-T is an application based on a CAD-solution by Bentley Systems called MicroStation. The spatial data that the MicroStation program generates and manipulates can be stored in a file format called design files.

Below is an example of how a typical design file from TeliaSonera looks in MicroStation.

8


Figure 4 – A TeliaSonera network map (design file) opened in MicroStation.

Each night, a conversion process takes place where CAD data in the form of V7 DGN-files are converted to enter an Oracle database so that the web applications can access the spatial data. It is this process that is currently handled and managed from several different environments.

Since TeliaSonera will pass on from MicroStation V7 to the newer version of DGN-files called V8, there is a great need of a technical solution that also supports the new V8 DGN architecture.

Furthermore, TeliaSonera is aiming to reduce the expenses for maintenance of the conversion process. The process is currently scattered and requires jobs to be done in different environments. This means that the solution that is sought after would result in an easier conversion process that is exclusively run from one single environment, in this case .NET. To accomplish this, new .NET programs and code libraries are required for converting design files.

Another area of interest is to develop Desktop and Internet applications in .NET that are not depending on the CAD-program MicroStation. In order to enable such solutions, a .NET code library with functionalities for reading/writing DGN-files would be very useful. DGN files are a commonly used format and a .Net library would also give rise to a simple and relatively independent way to import and export CAD information into all kinds of applications.

Therefore, seeing the conversion process in a long-term perspective, a .NET based conversion of design files will enable the company to start thinking of using the data in other contexts and with more functionality, such as GIS-functionality.

9


2.1.2 The Current Situation Today the documentation and planning team at TeliaSonera who work with the digital maps use a MicroStation based program IGS-T to generate CAD files. The CAD-files are then stored in a file data warehouse. In order for web-based applications to access the data within the CAD files today, the data is exported and converted into an oracle database.

Figure 5 – This picture shows how the conversion of design files looks today.

10


2.1.3 Future Plans

In the future, the plan is to first of all export the CAD data into a spatial database with the independent .NET components. Afterwards, the documentation and planning team can directly access and alter their data in the database instead of storing it in CAD-files.

Every night the database will generate new versions of the altered CAD files and store these in a data warehouse of files.

Figure 6 – This picture illustrates how a future conversion may look, using the independent .NET components.

11


2.2 Purpose

The main goal is to enable an easier conversion process intended for transferring spatial information from one context, V8 design files, to another that is a spatial database.

Another objective is that all development of applications to process the conversion should exclusively be made in the .NET environment with as few dependencies on other systems and programs as possible.

Therefore this project aims to investigate around the possibilities to read and write V8 design files in .NET. as a starting point for future development of a .NET API with components that help reading and writing V8 design files to and from a spatial database. To widen the perspectives, the choice of spatial database vendor does not necessarily have to be Oracle, which is used today. In the evaluation, the PostgreSQL data access provider for .NET will be included, since it is interesting to explore other possibilities.

Having a .NET API or .NET components will lead to an advantage over time. Eventually in the future, when the .NET code library is completed, a lot of time will be saved since there will not be a need to wait for updated data to enter the database through the nightly conversion process and the database can be updated more frequently.

To summarize, the purpose of this project is to evaluate four different code libraries and suggest the two most suitable candidates for reading and writing V8 design files to and from a spatial database. Two of the libraries are for reading and writing V8 design files and the other two for inserting and extracting spatial data to and from databases.

The evaluation will function as a feasibility study that helps TietoEnator plan the development of an independent .Net code library to use when remodelling the current conversion process of design files. A remodelling with help from an independent .NET code library would have several positive effects, such as:

• It would give easier access to the content in the design files and enable future development of web applications that provide GIS functionality.

• Reduce dependencies on heavy CAD-programs such as MicroStation.

• Reduce the costs of the current conversion process of CAD files to a spatial database.

12


Figure 7 – Overview

This picture shows a systematic overview, illustrating the independent .NET components (API:s) that this project is investigating about, and how they fit in to the process of reading/writing V8 DGN-files from/to a spatial database.

13


2.3 Method Description

Now that the purpose of the project is hopefully clear, it is time to present how the evaluation process looks.

The evaluation consists of two parts and the first part is an evaluation of possibilities for reading and writing MicroStation V8 DGN-files in .NET applications, keeping an approach of independency as one of the requirements. There are different suppliers that currently offer support for reading and writing DGN-files. These suppliers have their own Application Programming Interfaces (API:s) that support reading and writing DGN files. These API:s will be evaluated. Test applications will be implemented in order to thoroughly examine the functionality of the API:s.

The following API:s will be evaluated in the first part that deals with reading and writing design files:

• DGNdirect Toolkit by the Open Design Alliance

• FME-Objects .NET by Safe software

The second part of the evaluation is a similar analysis, but deals with insertion and extraction of data to and from spatial databases. This part will be based upon the results of a recent evaluation of spatial databases at TietoEnator. The two databases in the evaluation were Oracle Spatial by Oracle and PostGIS by PostgreSQL. The results showed that both products satisfy the requirements of TietoEnator when it comes to managing spatial objects and functions. [17] Therefore, the second part of the evaluation focuses on .NET API:s used for inserting and extracting data to and from the databases, considering the spatial databases to be equally functional according to the results in [17].

The final purpose of the reading and writing of the spatial data in .NET is to be able to read/write design files from/to a spatial database, either Oracle Spatial or PostGIS. Which one of the two that is most suitable will be decided after an evaluation of what support for storing/accessing spatial data that the database suppliers provide when it comes to programming in .NET. By support I mean API:s provided by Oracle and PostgreSQL that offer data insertion and extraction functionalities, which can be called from .NET applications, in order to create independent .NET components for the spatial database. This evaluation will also include an implementation of test applications that test the functionality in Oracle’s and PostgreSQL’s API:s.

The database API that is best suited for the building of independent .NET components should determine the choice of supplier.

Database API:s to be evaluated:

• ODP .NET by Oracle

• Npgsql by PostgreSQL

Oracle’s solution is called ODP for .NET and consists of a code library that is specialized in giving .Net programmers easy access to the database. It is worth mentioning that Oracle also provides an alternative to ODP .NET for reading and writing to and from databases in .NET. It is not an exclusively .NET based library, but it is a C++ library that can be used in .NET. The code library is called Oracle C++ Call Interface (OCCI). [I3] OCCI is not included in this evaluation. Using such a library requires extra development of wrapper classes in order to make the C++ library useful from other .NET languages. [A2]

PostgreSQL’s solution for data access in .NET is called Npgsql and it consists of a C# code library.

14


Both evaluations will be based upon specific criteria’s. (See chapters 2.4 and 2.5)

The test applications that will be implemented during both evaluations, using the different API:s provided by the suppliers, shall examine the technical aspects and the functionality of the API:s. In other words, they will help the evaluation by showing the practical pros and cons for each API.

2.4 Requirements for Reading and Writing Design Files

As mentioned earlier, two code libraries for reading and writing design files will be evaluated. The following requirements will be a basis for the first part of the evaluation dealing with FME Objects .NET and DGNdirect Toolkit.

1. Compatibility with .NET

It is important that the API is compatible with the .NET framework since TietoEnator uses .NET and visual studio for developing applications.

2. Independency

Can the API stand by itself or does it require additional products to be installed, besides the dependency of having a database? This requirement is necessary in order to enable the development of independent .NET components in order to give a more independent conversion process.

3. Reliability

Requirements on software are constantly changing. Therefore a continual update of the software is needed so that the product can continue to fulfil demands, also in the future.

4. Documentation

Descriptive and thorough documentation that shows and explains functionalities is always beneficial in application development. Without documentation, it is very difficult to use all the features in the API.

5. Development Support

Having a good documentation of the API might not answer all the questions that rise in a development process. It is therefore important to have access to some kind of support system.

6. Licence Costs

The costs involved are always of interest for all companies before making investments. Therefore it is interesting to find out what the costs are in order to use the supplier’s API for application development within a company such as TietoEnator AB.

7. Support for Reading V8 Design Files

The API would be useless to evaluate in this report if it does not support reading V8 design files.

8. Support for Updating Existing V8 Design Files and Creating New V8 Design Files

In order to handle changes made in design files it is necessary to be able to write data to already existing design files and to create completely new design files containing the updated changes.

15


9. Support for Representing MicroStation Elements

The data in design files consists of elements that need to be represented by the .NET components. Therefore, it is required that the code libraries that read and write design files provide the functionality needed to support reading and writing the following elements, since they commonly occur in TeliaSonera’s design files.

Table 1 – The table shows the required elements to read and write.

MicroStation Type ID MicroStation Type

3 LINE_ELM

4 LINE_STRING_ELM

6 SHAPE_ELM

7 TEXT_NODE_ELM

11 CURVE_ELM

15 ELLIPSE_ELM

16 ARC_ELM

17 TEXT_ELM

10. Support for Use in Server-Client Architecture

.NET Applications and design files do not necessary have to be located on the same machines. TietoEnator keep their design files on special servers. The API must therefore enable for the .NET applications to read and write design files stored on other machines.

16


2.5 Requirements for Reading and Writing to/from Databases

The following requirements will be a basis for the second part of the evaluation dealing with ODP .NET and Npgsql.

1. Compatibility with .NET

It is important that the API is compatible with the .NET framework since TietoEnator uses .NET and visual studio for developing applications.

2. Independency

Can the API stand by itself or does it require additional products to be installed, besides the dependency of having a database? This requirement is necessary in order to enable the development of independent .NET components in order to give a more independent conversion process.

Reliability

Requirements on software are constantly changing. Therefore a continual update of the software is needed so that the product can continue to fulfil demands, also in the future.

Documentation

Thorough documentation that shows and explains functionalities is always beneficial in application development. Without documentation, it is very difficult to use all the features in the API.

5. Development Support

Having a good documentation of the API might not answer all the questions that rise in a development process. It is therefore important to have access to some kind of support system.

6. Licence Costs

The costs involved are always of interest for all companies before making investments. Therefore it is interesting to find out what the costs are in order to use the supplier’s API for application development within a company such as TietoEnator AB.

17


7. Support for Spatial Data Types and Representation of MicroStation Elements

The data in design files consists of elements that need to be represented by the .NET components and the database. Therefore, it is interesting to know whether the spatial database and the API provide the functionality needed to represent the following elements in the database.

Table 2 – Required elements to be able to read and write to and from the spatial database.

MicroStation Type ID MicroStation Type

3 LINE_ELM

4 LINE_STRING_ELM

6 SHAPE_ELM

7 TEXT_NODE_ELM

11 CURVE_ELM

15 ELLIPSE_ELM

16 ARC_ELM

17 TEXT_ELM

8. Support for Calling Stored Procedures and Functions

Being able to call stored procedures and functions when inserting or extracting data to and from databases is important since it helps separating complex SQL statements from the application code and simplifies the insertion and extraction of data.

9. Support for use in Server-Client architecture

When the .Net components have read the design file content, they need to be able to store that content in a spatial database. Databases are not necessarily located on the same machines as the .Net applications calling them. The .NET API therefore has to enable calling databases that are located on other machines.

10. Support for Datasets

A Dataset is an in memory representation of a collection of database objects including tables of a database schema and is represented in .NET. [I18] The dataset contains a collection of Tables, Relations, constraints etc. The dataset contains all the objects as a Collection of objects. [18]

It can be used for manipulating the data remotely and finally updating the database with the modified data. This way it enables disconnected means of working with data. This improves performance in terms of reducing the number of times a database is accessed for data manipulations. [18]

Support for loading data into datasets with the .NET API is an aspect that is beneficial and therefore interesting to include in the evaluation.

11. Support for Ref Cursors

The REF CURSOR is a data type in the SQL language and it represents result set in the database. Being able to retrieve ref cursors from a database means being able to get whole result sets from procedures and functions. When loading large amounts of data from the database during conversion of design files, this feature will be very beneficial and effective. Therefore, the API should support the use of ref cursors. [13]

18


12. Support for Large Objects

MicroStation CAD files such as design files can also be stored as images files called raster images. Raster files may occur and it is important to have some support in order to also store that kind of data in the database. The Large object data type is a type that can be used to store images in the database. Support in the API for sending and retrieving images to and from the database is therefore needed. [I17]

13. Support for Bind Variables

From a performance point of view, bind variables are very useful when working with SQL statements in applications. When an SQL statement is sent to a database it is stored in the memory. The use of bind variable is effective since it helps reusing those statements that already have been parsed and optimized in the database once. [12]

19


2.5 Software

The software used to perform the evaluation is listed below.

MicroStation V8

Visual Studio .NET 2003 (for development of test applications).

FME Suite 2006 (Including FME Objects 2006).

DGN Direct Toolkit 0.0.993.

ODP.NET 10.1.0.3.

Oracle 10g Release 2.

PostgreSQL 8.1 (PostGIS 1.1.2).

Npgsql 1.0.

2.6 Delimitations

The numbers of spatial elements that are taken in consideration in the evaluations are narrowed down to the most basic 2D elements. Furthermore, no complex or compound elements are included in the evaluations. Performance testing has not been included in the evaluation.

The evaluation of the database API:s is not an evaluation of the spatial DBMS:s even though the spatial DBMS influences the evaluation to some degree. The purpose of the evaluation is mainly focused on functionalities provided by the API:s for inserting and extracting spatial information. However, this evaluation will be based upon an evaluation of the spatial DBMS:s that has already been performed at TietoEnator and that showed that both Oracle and PostgreSQL provide what is necessary for handling the spatial information that TietoEnator is interested in.

20

Chapter 3 – Microstation V8

3 MicroStation V8 MicroStation is a CAD-program for the design, construction and operation of infrastructure. It is a single platform for design and engineering projects and is the foundation of the V8 Generation of software from Bentley. [I7]

In the mid-80s, MicroStation cloned Intergraph’s CAD system, making its features available for the first time on a personal computer. The first version was mainframe compatibility. The second generation started with V4 and lasted until MicroStation/J and V7. This was the generation of desktop CAD. V8 is the third generation and referred to as network CAD. [I12]

There is a variety of elements that can be placed in MicroStation, both in 2D and 3D. An element is usually a geometric shape or a text. Examples of possible elements to place in 2D are lines, curves, arcs and ellipses.

The elements all have a symbology that is a set of common information, such as: color, weight, style and many other properties. [M13]

Figure 8 - This figure shows a design file opened in MicroStation. You can see several elements such as lines and text elements, also known as attributes. When an element is placed in the application, all details about it are stored on a specific place in the design file.

All the data and the elements that are designed in MicroStation are stored in DGN files. Each element has features that describe it. These features are also stored in the DGN file together with other element specifications.

MicroStation design files have been used by GIS’s for a long time. They were from the beginning pure CAD-files but have evolved and now facilitate storage of other types of descriptive information which make them useful for GIS purposes. [I18]

21

Chapter 3 – Microstation V8

3.1 New Features in V8

[I12] V8 is the new generation of design files and is a lot different from the earlier V7 version.

One new feature in V8 is the Digital Security which includes multi-level access control for projects and digital signature functionality. This means that access to V8 DGN files can be controlled by assigning a password or by granting specific digital rights to that file. Digital signatures on DGN files can indicate approval of the design and help identify whether the integrity of the DGN has been compromised.

Another V8 feature is the Change Tracking core technology which enables users to isolate and view any change or set of changes to a design. Users can record, review, and restore a complete history of modifications, including all data and references, dates, and authors.

Changes are tracked at the element level, and identified with a revision number. The time, date, author, and a description and are committed to the Design History log. Design History revisions record changes from the inception of history to the present.

Design History can also be used to recover the prior state of the model, in whole or in part, or to undo any change.

22

Chapter 4 – Spatial Databases

4 Spatial Databases - DBMS with spatial extensions

4.1 Background

Spatial Database Management Systems (DBMS) are relatively new and have only been available for the last 10 years.

Before giving a short presentation of what spatial DBMS:s are, it is necessary to know what is expected of a GIS in terms of storage and access to data, since spatial DBMS:s are often used for storing spatial data in GIS. [2]

A system needs to perform the following on geospatial data:

• Input and store

• Retrieve and analyze

• Display and select

A GIS needs to store both spatial and alphanumeric data. Storage can be controlled either directly by the application or by a DBMS. Early GIS were built on top of proprietary file systems. Some off-the-shelf GIS’s still follow this approach. Geospatial and alphanumeric data are both stored in files controlled by the application, and functions are defined on this data. This however leads to many problems regarding for instance, data security and concurrency control.

There are two ways to use a DBMS in a GIS environment. Pure relational databases are not suitable for this. The two alternatives: Loosely coupled approach and use of extensible DBMS. [2]

The problems with using pure relational databases in a GIS context have been that small changes in the structure of the objects stored, implies a deep reorganization of the database and changing the query formulation.

The many relations that the spatial data would require would also lead to bad performance. Furthermore it would be difficult to define new spatial types.

The loosely coupled approach is an architecture that uses both a relational database and a separate storage context for descriptive data. This means that it separates descriptive data management from geospatial data management.

A Problem with this kind of approach is the co-existence of heterogeneous data models, which implies difficulties in modelling, use and integration. Another issue is the partial loss of basic DBMS-functionality, such as recovery techniques, querying, and optimization because of the fact that the storage is scattered and all data is not stored in one place.

23


Figure 9 – The figure above shows the architecture of a system implemented with the loosely coupled approach.

The best approach for storing spatial data for GIS’s is therefore the most recent integrated approach which has proven to be the most convenient.

The integrated approach means an extensible DBMS where spatial support is built into the DBMS. [2]

4.1.1 DBMS [12] DBMS stands for database management system. It is a software that helps processing queries towards a database and accessing the data in a database.

[1] DBMS:s handle different kind of tasks and one of those deals with storage. A DBMS manages an efficient organization of data on a persistent secondary storage unit (one or many discs). It also provides access methods and paths that accelerate data retrieval.Query processing is another important task. Processing a query usually involves several operations. To efficiently evaluate the query, these operations must be properly combined.

[1] A spatial extension to the query language is added and new features are built in, in order to support spatial data objects as well as descriptive data. New spatial data types are handled as base alphanumeric types.

[2] Many other DBMS functions such as query optimization are adapted in order to handle geospatial data efficiently. A DBMS also takes care of query optimization to a certain degree. It is the responsibility of the system to find an acceptably efficient way to evaluate a query. Last but not least, concurrency and recovery are two important features that need to be provided in a DBMS.

24


4.1.2 Spatial Data Types A DBMS with a spatial extension offers spatial data types to facilitate storing of geometries. Spatial data types are a collection of geometrical objects that provide the necessary functionality to store, access and manage the contents of the spatial data. Geometries stored in these kinds of objects can either be of two or more dimensions. The type of data and the SQL queries for spatial DBMS:s are based on standards for SQL and OpenGIS Consortium-standards. [17]

Figure 10 - Common Geometrical data types and how they can be shaped [1].

4.1.3 Spatial Operators in Extended DBMS For manipulating and using queries on spatial data, you need spatial operators. Spatial operators are functions that are used in spatial queries. Spatial queries for example give functionality for area and length calculations of geometries. [1]

25


4.2 Oracle and PostgreSQL Representation of Spatial Data

This chapter will shortly present how Oracle and PostgreSQL represent spatial information in their systems. It is useful to know about this since the evaluation in the report deals with evaluating two .NET API:s for accessing data, one of them provided by Oracle and the other by PostgreSQL. Therefore, it is good to know what kind of data the API:s are used to access and how that data is represented in the different systems.

4.2.1 Oracle Spatial Oracle is a company that offers a spatial extension to their DBMS called Oracle spatial. Oracle Spatial is an option for Oracle Database 10g Enterprise Edition and requires a licence for usage. It includes advanced spatial capabilities to support GIS applications, location-based services, and enterprise spatial information systems.

Representation of spatial data is done with the data type SDO_GEOMETRY. To be able to make such a representation, Oracle has extended its standard SQL with functions and operations that act upon the new geometry data type. [I6]

Oracle Spatial is designed to make the storage, retrieval, and manipulation of spatial data easier and more natural to users. Once this data is stored in Oracle, it can be easily and meaningfully manipulated and retrieved as it relates to all the other data stored in the database. [8]

The types of spatial data that can be stored using Oracle Spatial include location-based and geographic information system (GIS) data as well as data from computer-aided design (CAD) and computer-aided manufacturing (CAM) systems. Instead of operating on objects on a geographic scale, CAD and CAM systems work on a smaller scale such as an automobile engine, or a much smaller scale, such as printed circuit boards. [M7]

The spatial data is stored in Oracle spatial is physically stored in ordinary tables. The tables have a number of regular relational attributes and one spatial attribute of type MDSYS.SDO_GEOMETRY. It is therefore the column of type SDO_GEOMETRY in the table that stores the actual spatial data and makes the table a spatial table. [10] A table that stores geometry types represents a theme that is a collection of geographic objects of the same type, one per row. The spatial attribute of the tuple is called geometry. The projection of a table onto its spatial column returns a collection of geometries called a layer of an ordered list of elements. A layer is synonymous to a column in a table and consists of geometries that share a common set of attributes. [2]

Working from bottom to top, an element is synonymous to a geographic primitive type. An element can be a point, line string, polygon, compound line string or compound polygon. A geometry is made up of one or more elements. An example of geometries that are made up of multiple elements might be: 6th Avenue in New York City—6th Avenue starts in southern Manhattan, hits Central Park, and continues on the other side of Central Park. This is an example of a geometry with 2 line string elements. [10]

26


4.2.1.1 Oracles Geometric primitive types

Oracle Spatial supports several primitive types and geometries composed of collections of these types.

Figure 11 - This figure illustrates the geometric primitive types in Oracle. [10]

4.2.1.2 Oracle Spatial Elements

An element is the atomic building block of the geometry and elements are the same as geometric primitive types (see above). The supported spatial element types are: point, line string, polygon, compound line string, and compound polygon. Geometries consisting of a list of elements model complex geometries, such as compound polygons or line strings (See figure 11).

Below are descriptions of geometric primitive types or element types supported by Oracle spatial.

27


Table 5 – The Oracle spatial geometric primitive types with descriptions. [M7]

Geometric Type Representation Description

Point (X1, Y1) A Coordinate can be either 2D, 3D, or 4D.

A point could represent a building, a customer location, or an ATM.

Line String

(X1, Y1,…, Xn, Yn)

A series of 2 or more points that are connected by either straight lines or circular

Arcs are called line strings. Line strings can cross themselves. Line strings have no area, even if they close to form a ring. A line string could represent a river, a road, a utility cable or any other linear feature. Line strings may be straight lines or circular arcs.

Polygon

(X1, Y1,…, Xn, Yn)

A polygon is a series of connected points, where the first point is the same as the last point.

Compound Line String

(X1, Y1,…, Xn, Yn) Compound Line Strings are a combination of straight lines and circular arcs.

Compound Polygons

(X1, Y1,…, Xn, Yn) Compound Polygons are a combination of straight lines and circular arcs.

The polygons discussed earlier were either all connected with straight lines or all connected with circular arcs. One can think of compound as combination.

28


4.2.1.3 Geometry

[10] A geometry is the representation of a user’s spatial feature, modelled made up of multiple geometric primitive elements. Another way to explain geometry in Oracle is to see it as an ordered sequence of vertices that are connected by straight line segments or circular arcs. The semantics of the geometry are determined by its type.

Figure 12

Each of the geometries to the left are examples of US States (California, Texas, Florida, Hawaii), that are made up of multiple elements. In the example, all the geometries are made up of multiple elements, where all of the elements are the same type. Geometries that contain different element types are supported by Oracle Spatial. [10]

4.2.1.4 Spatial Operators

[I13] Oracle Spatial includes a set of spatial operators and functions. Spatial operators and functions both perform spatial analysis, the difference being operators leverage spatial indexes and functions do not.

29


4.2.2 PostgreSQL and PostGIS [I1] The PostgreSQL system for spatial support became an open source project in 1996 and contains an extended relational DBMS, also called an object-relational DBMS. What this means is that it has some object-oriented features such as concept of inheritance and ability to define complex data types with special functions to deal with these data types, but is for the most part relational in nature. Just as Oracle’s, this system also provides a spatial extension to its standard SQL. It is widely used in the open software community and is regarded as a very complete DBMS implementation. PostgreSQL is cost-free to use. [I2]

The PostgreSQL spatial extension called PostGIS is an extension with an extended SQL that enables geometric functionalities that enable PostgreSQL to store, relate, join and query with spatial data. This system is a popular choice and is widely used on the open software society. [I2]

Spatial objects in PostGIS are implemented in the same way as in Oracle spatial. A column of the type geometry type is added to a table to make it spatial. [2]

4.2.2.1 PostGIS Geometric Types

PostGIS represents geometries as a set of geometric types and operations on these. Geometric data types represent two-dimensional spatial objects. The PostgreSQL DBMS provides 7 native geometric data types.

The geometric types supported by PostGIS are points, lines, line segments, boxes, paths, polygons and circles. The most fundamental type is the point and it forms the basis for all of the other types. The types are implemented according to standards. [M2]

30


Table 6 – The PostGIS geometric types with descriptions [M2].

Geometric Type

Representation Description

Point (X1, Y1) Point in space.

Line (X1, Y1, X2, Y2) Infinite straight line defined by two points.

Lseg

(X1, Y1, X2, Y2)

A line segment defined by its two endpoints.

Box (X1, Y1 X2, Y2) A rectangular box.

Path ((X1, Y1) …) Can be of two types. A closed polyline is called closed path. A polyline is a path.

Polygon ((X1, Y1),…) Polygon, a series of connected points (similar to closed path).

Circle <(X, Y), r > A circle with centre and radius.

4.2.2.2 Spatial Functions and operators

A large set of functions and operations to enable SQL queries on the geometric data types is provided in PostGIS. The functions and operators support a limited set of basic functions, set operations and spatial analysis queries on the native geometric types shown in table 4.2 above. [2]

31

Chapter 5 – API Introduction

5 API Introduction In the following chapters, the .NET API:s that are included in the evaluation in this report will be presented and shortly described. The first two API:s are .NET providers for Oracle and PostgreSQL. A .Net Data Provider is a component that allows any program developed for the.Net framework to connect to data sources such as databases and get and send data to them. [I21]

5.1 ODP .NET

[I6] ODP stands for Oracle data provider and is an API part of Oracle9i Release 2 Client and above. ODP.NET is native to the .NET environment, so it does not use a data access bridge. It can be used by applications in any .NET language. The ODP version used in the evaluation in this report is ODP.NET 10.1.0.3.

Furthermore, ODP.NET has many optimizations for retrieving and manipulating Oracle native types, such as for example Large Objects and REF Cursors.

ODP.NET exposes many other Oracle database features, including PL/SQL and transactional support. ODP.NET users can fully execute PL/SQL stored procedures and functions in the database. PL/SQL can be packaged or non-packaged. Programmers are provided significant flexibility in using PL/SQL, including the ability to return multiple result sets from a stored procedure. For example, in ODP.NET, multiple Ref Cursor objects obtained as PL/SQL output parameters can be accessed in an arbitrary way.

5.1.1 ODP.NET Types [M8]With ODP .NET native Oracle data types can be retrieved and manipulated in a safer and more efficient way in a .NET application than .NET types. A majority of the Oracle types are represented in ODP .NET. However, the spatial data types are not among the ODP supported types.

32


Table 7 - This table lists all the Oracle native types supported by ODP.NET and their corresponding ODP.NET type. The third column lists the .NET Framework data type that corresponds to the Value property of each ODP.NET Type. [M8]

Oracle Native Type

ODP.NET Type .NET System Type

BFILE OracleBFile class Byte[]

BLOB OracleBlob class Byte[]

CHAR OracleString structure String

CLOB OracleClob class String

DATE OracleDate structure DateTime

INTERVAL DAY

TO SECOND

OracleIntervalDS structure

TimeSpan

INTERVAL YEAR

TO MONTH

OracleIntervalYM structure

Int64

LONG OracleString structure String

LONG RAW OracleBinary structure Byte[]

NCHAR OracleString structure String

NUMBER OracleDecimal structure Decimal

REF CURSOR OracleRefCursor class Not applicable

TIMESTAMP OracleTimeStamp structure

DateTime

VARCHAR2 OracleString structure String

XMLType OracleXmlType class String

33


5.2 Npgsql

[M9] Npgsql is an open source .Net data provider for PostgreSQL and is developed by an independent project team of developers. It is implemented in C# and is compatible with PostgreSQL 7 and 8. Npgsql is also OS independent. The version used in this evaluation is Npgsql 1.0

The API allows a .NET client application to use a PostgreSQL server to send queries, manipulate and receive data. Some features are the possibility to call functions, receive result set from functions, use of Input and Output parameters in queries and support for transactions.

34


5.2.1 Npgsql Types Npgsql supports a majority of the PostgreSQL native types, including the geometric types.

Table 8 - This table lists all the PostgreSQL/PostGIS types supported by Npgsql and their corresponding Npgsql type. The third column lists the .NET Framework data type that corresponds to the Value property of each Npgsql type. [M9]

PostgreSQL Type Npgsql Db Type .NET System Type

Int8 Bigint Int64

bool Boolean Boolean

Box, Circle, Line, LSeg, Path, Point,

Polygon

Box, Circle, Line, LSeg, Path, Point, Polygon

Object

bytea Bytea Byte[]

date Date DateTime

float8 Double Double

int4 Integer Int32

money Money Decimal

numeric Numeric Decimal

float4 Real Single

int2 Smallint Int16

text Text String

time Time DateTime

timestamp Timestamp DateTime

varchar Varchar String

5.3 Safe Software Safe Software is a provider of GIS data interoperability and conversion tools. Their product FME (Feature Manipulation Engine) makes it possible to transfer data between many clients that use many different software platforms and data formats. As an extension to FME, it is possible to use an embeddable version of FME that is called FME Objects. FME objects .NET is basically a software library for working with spatial data. A developer can use this library to read, write and thereby convert different spatial formats. Among these accepted formats is the DGN file. FME objects is a part of FME Developer Tools, which consist of software development kits and libraries for embedding FME technology. This developer kit supports development in the .NET environment.

An FME suite license gives access to the FME Objects library. Additional functionalities in FME Objects follow the FME Suite professional license. [I5]

35


5.3.1 FME Objects .NETFME Objects .NET is a cross language compliant application programming interface (API). It means that it is possible to develop an FME Objects application in any .NET language. [M15]

FME Objects is used to build spatial data access and processing capabilities directly into new or existing applications and it is ideally suited for situations where the schema of the data is not known a priori.

The starting point for using FME Objects is to create an FME Objects session object, which creates a session that enables the use of FME functions for reading and writing to/from a source. [M17]

5.3.1.1 FME Features

The feature object is the fundamental data unit of an FME Objects application. When an application reads from a dataset, it receives the data one feature at a time. When an application writes to a dataset, it sends the data one feature at a time. Features can be manipulated using all of the standard FME functions and factories. [M17]

To transport features from one format to another, the FME considers features to be collections of attribute names and values associated with two or three dimensional geometry that has an associated coordinate system. FME places no restrictions on the values, or types of attributes. Attribute names consist of one or more ASCII characters. [I14]

In addition to attributes and geometry, each FME feature has a feature type.

A feature type is a well-defined data classification scheme. For example, a simple classification scheme is to identify features according to the file name or database table where they reside, in which case the feature's type is the file base name or respectively table name.[M19]

Every format supported by FME identifies features by feature type which means that reader and writer modules interpret the feature type in ways specific to their own formats. For example, the IGDS reader and writer use the feature type to store the IGDS level of the feature. [M15]

IGDS is the name of the reader and writer for design files and will be described more in section 5.3.1.4.

5.3.1.2 Reading Features

The basis for the readers and writers with FME Objects is actually the same as the readers/writers that the product FME Translator uses. FME Translator is a program used for converting between different spatial formats. [A1]

The FME universal reader object provides access to data stored in any of the FME-supported formats. The methods and properties of that reader object provide a simple and configurable interface.

The FME reader object returns two types of features: schema features and data features. Schema features describe the model of a dataset. Every format supported by FME Objects identifies data features according to a well-defined data classification scheme. This primary classification is known as the feature’s type and it serves as the main handle to a data feature. A schema feature is a data model for all the features of one feature type. A schema feature describes the attributes, coordinate system, and allowed geometries that features of that type share. [M19]

36


5.3.1.3 Writing Features

The FME universal writer object allows applications to create new datasets in any supported format. The methods and properties of the writer object also provide a simple and configurable interface. [M19]

5.3.1.4 IGDS Reader and Writer for Design Files

[M15] Each format has its own readers and writers specific for the properties of that format. The reader and writer for the design file is called IGDS, which stands for Intergraph Interactive Graphics Design System. The IGDS reader and writer modules support both two- and three-dimensional V8 Design files.

The Design File Reader and Writer modules provide the Feature Manipulation Engine (FME) with access to files used by MicroStation.

[M13] As described in chapter 3, design files consist of a header, followed by a series of elements. The header contains global information including the transformation equation from design units to user coordinates, as well as the dimension of the elements in the file. Each element contains standard display information, such as its colour, level, weight and style, as well as a number of attributes specific to its element type. For example, a text element has fields for font, size, and the text string in addition to the standard display attributes.

5.3.1.5 IGDS Reader

The FME reader detects the version of the source dataset, meaning design file of version 7 or 8, internally and handles it accordingly. There is no difference to users in terms of the reader keyword or attribute names of the elements. The only thing the user needs to do is to say when reading design files is that the reader object should be of the “IGDS” type.

The IGDS reader first reads the header information from the Design file being processed, and extracts the conversion parameters required to translate coordinates from internal IGDS units to ground units. It also determines the dimension of the input file.

It then extracts each individual element, one at a time, and passes it on to the rest of the FME for processing. Complex elements are extracted as single FME features. If the element had any attribute linkages attached to it, these are read and added as attributes to the FME feature being created. When the IGDS reader encounters an element type it does not know how to process, it simply ignores it and moves on to read the next element. DGN Version 8 also reads the models to which the features belong. All the models read retain their respective working units and global origin values. [M15]

37


5.3.1.6 IGDS Writer

To create a new Design file, header information is obtained from an existing Design file, called a seed file. [I15] A seed file is a template file used when writing to or creating new design files.

The IGDS writer first copies the seed file’s header information to the destination file, and then extracts the conversion parameters required to translate coordinates from feature coordinate units to internal IGDS units.

The IGDS writer needs the seed file to determine whether the destination file will be two-dimensional or three-dimensional.

The IGDS writer then outputs each FME feature it is given. Most often, a single FME feature corresponds to a single IGDS element. If any linkages are specified for the element, they are also output. [M15]

5.3.1.7 FME Igds_type

To represent MicroStation elements in design files, the IGDS reader and writer use symbolic names for the IGDS element types rather than the IGDS/MicroStation numeric values. This greatly simplifies element type specification when working with FME objects applications, since the elements can be referred to with FME igds_type names. [I19]

38


5.4 Open Design Alliance

The Open Design Alliance is a non-profit membership-based consortium. Software developers that work commercially pay an annual membership fee to belong to the Alliance. End-users pay no membership fees at all. The alliance strives for open industry standard formats for exchange of CAD data, since they believe that the users of the data should be the ones controlling it. They provide two software libraries which enable their members to develop applications capable of reading and writing popular CAD file formats. One of their libraries is DWGdirect, based on the OpenDWG industry standard format. OpenDWG is based on the DWG format used in AutoCAD, developed and sold by Autodesk. However, this report only deals with design files and the evaluation has therefore only looked upon the design file software library provided by the Open Design Alliance.

The design file C++ code library that the alliance provides is called DGNdirect Toolkit. It is based on the OpenDGN specification, which is the V8 file specification provided by Bentley Systems. Bentley has provided full documentation and technical support to the Alliance for its implementation, delivery, and maintenance of software library to read and write Bentley’s format, V8 DGN. [I22]

5.4.1 DGNdirect Toolkit The DGNdirect toolkit provides the ability to create .NET programs that read and write MicroStation V8 DGN files. You can read or create a new DGN file or you can load an existing file, make modifications and write the revised DGN file. The toolkit provides access to the DGN file data through a number of interfaces.

The DGN V8 file format that contains its own “directory” system and multiple streams of data. The DGNdirect toolkit handles the considerations of working with this multi-stream organization and exposes its contents as a list of element records.

When reading a design file with the toolkit, it creates a list of element objects that attempt to preserve all of the data contained in the DGN file, including data whose meaning is currently unknown.

There are several types of lists of elements in a DGN file. Header, geometry, and application data lists are usually present. In addition, a DGN file can contain multiple models, with each model having its own geometry and perhaps application data lists. [M11]

39


5.4.1.1 DGNdirect Representation of Lists

The DGNdirect toolkit collects all of the element records in lists and places them into a single linked list, with each element having member data items that indicate the type of list (header, geometry, or application data) that an element belongs to, and the model id. This distinguishes the source list completely.

The reason that elements are placed in a single master list is that it simplifies scanning a design file. Scanning the list is a very quick operation, which was found to be slower with code that separated them into distinct lists, due to the need to access list objects in order to scan it for elements.

Each element contains a forward and back element handle – handles to the actual object that precedes or follows the current element.

Record Enumerator objects are available to scan any list with desired selection criteria, and it is possible to add any element object to another with the Append() method.

Each DGN file is accessed by creating an design file object called IDgnFile, and loading it from the file with IDgnFile::Load(filename). This object maintains the list of elements that comprise the DGN file’s data, as accessing the file name, model names, and model descriptions.

The base object in the toolkit is called an IRecord. All objects within a DGN file are derived from IRecord. Its methods provide the basic interface of an object with the list of records. The methods of this interface provide primitive interaction with the master list of objects, such as the ability to relocate records within the list. There are no instantiations of an IRecord – it serves as a base class only.

All actual instantiated records in a DGN file derive from either IElement or IEntity, depending on their graphical nature.

IElement is the interface to the base class object for all records stored in the DGNdirect database list.

IElement records have an element header data structure that specifies the type of object, its size in the file, if it has attribute data appended the level (layer) or the element, etc. Each element can have zero or more attributes, which is of variable length, identified by an attribute id value and follows the element-specific data in the file data stream. The IElement class provides methods for accessing attributes. The collection of all attributes for an element is stored in an IAttributes object. You access the single instance of this object for each element by using the IElement method GetAttributes() which returns a pointer to an IAttributes object. Data in attributes includes variable length string text, level names, descriptions and pointers to other elements. Each element also has a unique 64-bit integer id number.

Those elements that are graphical and can be displayed derive from the IEntity class, which derives from IElement. These records have a display header data structure, which specifies line color, style, and weight, among other things.

MicroStation documentation refers to the visible properties of an entity as symbology. [M13] It includes the color, line weight, and line style used to draw the geometry. The IEntity class supports methods for setting and accessing symbology of the geometries stored in the design files. For example, the methods GetColor() and SetColor() are used to get and set the entity line color.

DGN Toolkit reads design files simply by scanning the lists with elements and using methods to access different kind of information. The writing to design files is done in two ways depending on what type of writing it is.

It is possible to create new DGN file or load an existing file, make modifications and write the revised DGN file. When writing to an existing file, the file is first loaded into the application.

40


When the modifications are made, the file is simply saved using the DGNSave(filename, DGN_WRITE_V8) method.

When creating a completely new design file from scratch, instead of loading an existing file, a new file object is created with the DgnNew(boolIs3d) method.

Each MicroStation element is represented with a corresponding element type in DGNdirect Toolkit. [M11]

41

Chapter 6 – Evaluation Part I

6 Evaluation Part I This chapter presents the evaluation of the application programming interfaces used to read and write V8 design files. The two API:s in this part of the evaluation are FME Objects .NET and DGNdirect Toolkit.

As a complement to studying documentations of the API:s, test applications were implemented in order to acquire a greater understanding of the possibilities each API provided to read and write the content in design files.

Both test applications read a line string element with all of its specifications from a design file. The purpose of extracting specifications such as coordinates and attributes is that the future .NET components that are being investigated about in this report will preferably need to have their own object classes and therefore, it is necessary to be able to create objects from the information that is extracted from the file. Furthermore, an application for writing a line string element to a design file was also created for each API.

Figure 13 – This is an overview picture of how the test applications on the database side look.

42


6.1 FME Objects .NET – Test Applications

In order to gain a better understanding of the suitability of the API:s, it was necessary to also look at the API:s from a more technical point of view. Therefore, two test applications were created.

6.1.1 Implementation of Test Applications Two C# applications were created to obtain an understanding of how FME Objects operates while reading and writing V8 design files. A design file containing a line string element was first read by the test application using the FME Objects 2006 API. The second application tested writing line string elements to a design file.

6.1.2 Reading from a Design File First of all, a design file containing line string elements was created in the CAD program MicroStation. The application then read the design file content into an FME features container (vector) and the content could be accessed with help from FME Objects classes and methods.

This code example illustrates how the content was read into FME Features from the design file roads.dgn.

// Creates an IGDS reader

IFMEOReader fmeReader = fmeSession.CreateReader("IGDS", false, null);

// Opens the design file

StringCollection readerParams = new StringCollection();

string souceDataset = @"C:\roads.dgn"; fmeReader.Open(@souceDataset, readerParams);

// Creates a feature vector

IFMEOFeatureVector fmeFeatureVector = fmeSession.CreateFeatureVector();

IFMEOFeature fmeFeature = fmeSession.CreateFeature();

while (fmeReader.Read(fmeFeature)){

// Appends the feature. The feature vector takes ownership of //the feature.

fmeFeatureVector.Append(fmeFeature);

// Creates a new feature to hold the results of the read since // the original feature is now owned by the feature vector.

fmeFeature = fmeSession.CreateFeature(); }

Getting the coordinates of the elements in the design file is done by calling each features GetAll2DCoordinates method. The method then puts the coordinates in two arrays. One for the x coordinates and one for the y coordinates. [M16]

43


GetAll2DCoordinates(x,y);

Similarly, getting information about specific elements or features can be done by calling a features GetStringAttribute method with a parameter that indicates what feature attribute should be returned. In the example below, the parameter “igds_color” tells the method to return the element color. Some other parameters that can be used are “igds_level”, “igds_style” and “igds_weight”. [M15]

GetStringAttribute("igds_color")

6.1.3 Writing to a Design File This C# application wrote line string elements to a design file. The easiest way to demonstrate FME’s writing functionality is to show how easily it can be used to convert from one format to another. The line string elements were stored in an XML file which was read and converted to design file format by FME Objects. FME objects writes to one format be reading from another FME supported format and converting to the specified format. For testing, XML was a very suitable format to use as source. Line string elements were stored in the XML file as the figure below shows.

Figure 14 – An XML-file containing line string elements.

In the application an FME GML-reader was first created which is a reader for the XML format, in order to read the contents and translate them to FME features. The FME Features could then be written to another FME supported format, in this case the design file format. By creating an IGDS-writer, which is the design file writer, the features were written to a design file. [M16]

44


The following code illustrates how the design file writer war created and how it was used to write the FME Features to a design file.

// Creates an IGDS writer

IFMEOWriter fmeWriter = fmeSession.CreateWriter("IGDS", null);

// Opens the IGDS writer

StringCollection writerParams = new StringCollection();

string destDataset = GetDataFileDir() + "roads.dgn";

fmeWriter.Open(destDataset, writerParams);

// Gets the schema for the Features and prepares the writer

IFMEOFeature schemaFeature = fmeSession.CreateFeature();

while (fmeReader.ReadSchema(schemaFeature)){

fmeWriter.AddSchema(schemaFeature);

}

schemaFeature.Dispose();

// Reads and writes all features from the XML-file to the design file

IFMEOFeature fmeFeature = fmeSession.CreateFeature();

while (fmeReader.Read(fmeFeature)){

fmeWriter.Write(fmeFeature); }

Setting element properties directly from .NET is also supported. For example, IFMEOFeature objects can be added to a file and properties and attributes can be set to the feature. For example, symbology can be added with the SetStringAttribute that similarly to the GetStringAttribute method takes the name of the parameter it is setting. [M19]

SetStringAttribute("igds_color")

Coordinates can be set directly in the application by calling the Add2dCoordinate method as shown below.

Add2dCoordinate(10.2 , 1.5);

45


FME Objects also enables accessing features that are not graphical. For examples features containing header information or non graphical elements in the design file. However, such an implementation was not part of the FME test applications. [M19]

46


6.2 Evaluation of FME Objects .NET

Below follows the requirements set for the evaluation and the results of FME Objects on each aspect.

6.2.1 Compatibility with .NET FME Objects is compatible with the .NET framework and can be called from the languages C#, Visual basic, Java, C++ and C. [M17]

6.2.2 Independence FME objects require an installation of FME Suite with a valid license file for usage. [I5]

6.2.3 Reliability Safe software is a large company with many customers using their FME solutions around the world. Their reliability is very high since Safe has been developing software for conversion purposes for a long time. It is very unlikely that they would disappear from the market in a near future. New releases of their products are constantly being made. [I5]

6.2.4 Documentation FME Objects is very well documented. Apart from very detailed documentation and development guides, tutorials, many samples and quick start guides are available on the FME website. [I5]

6.2.5 Development Support Safe software offer their users extensive support in many ways.

Fmepedia is a recently launched user collaboration site and is maintained both by Safe Software staff as well as members of a user community called FME MVP. The FME MVP is a program that is designed to recognize and reward the active participation and technical expertise, of those who voluntarily share their knowledge and expertise in this mailing list and thereby a good source for support. Another valuable resource is the Safe Software Yahoo Groups where FME Objects support is available.

Safe software also has a contact support team who are ready to directly answer technical questions. For instance, the FME Objects contact support can be reached at the following e-mail address [email protected]. [I5]

6.2.6 Licence Costs An FME suite license is required for using FME Objects and costs approximately 60 000 SEK per year for a company like TietoEnator. [A5]

6.2.7 Support for reading V8 design files FME Objects can read and write any of the FME supported formats. V8 design files are supported by the FME software and can therefore be read or written. FME reads each format that it supports and translates it to the universal FME features that can later be used to convert the content and write to any other FME supported format. To be able to do this, FME Objects uses the different FME readers and writers for each format.

47

mailto:[email protected]


FME Objects works best when it is used to read and write information where the data schema is known in advance. For example in cases when converting from one FME supported format to another, as in the case of the test application. Reading data when the schema is not known is possible but not recommended. [M17]

6.2.8 Functionality for Writing to a V8 Design File and Creating New Design Files It is possible to create completely new design files or write to existing files with FME Objects. To do so, it is important to make sure that the seed file in use is a suitable template for the new design file. If it is not, a design file with the correct settings can be set as a seed file. FME Objects then uses the seed file to create a design file and writes to it or adds the features to an already existing design file. [M17]

6.2.9 Support for Representing MicroStation V8 Elements

Table 9 – The table shows some of the igds_type attribute values that the FME Features use to represent [M15].

MicroStation Type ID

MicroStation Type

FME IGDS_type

3 LINE_ELM Igds_point

4 LINE_STRING_ELM

Igds_line

6 SHAPE_ELM Igds_shape

7 TEXT_NODE_ELM Igds_text_node

11 CURVE_ELM Igds_curve

15 ELLIPSE_ELM Igds_ellipse

16 ARC_ELM Igds_arc

17 TEXT_ELM Igds_text

6.2.10 Support for Server-Client Architecture FME Objects can be used remotely. The FME objects .dll just has to be included from its location on the server. Applications using FME objects can be executed anywhere where there is an FME suite installation with a valid license file.

Moreover, writing and reading design files that are stored on a server is also possible. The path to the file is specified in the application and to call a file stored on a server is done simply by specifying the complete path to the file. [M16]

48


6.3 DGNdirect Toolkit – Test Applications

In order to gain a better understanding of the suitability of the API:s, it was necessary to also look at the API:s from a more technical point of view. Therefore, two test applications were created.

6.3.1 Implementation of Test Applications The DGN toolkit test applications were implemented in Visual C++, because the code library itself is a C++ library.

6.3.2 Reading from a Design File DGN Toolkit reads a design file by creating a design file object and loading the content of a specified design file into the object. A design file containing a line string element was loaded by the application. The line string is a graphics element and was accessed by using the knowledge of that. The coordinates could then be obtained using functions in DGN toolkit.

The code below shows how the reading was done and how the line string coordinates and other properties can be obtained using DGN Toolkit.

//load the specified dgn file object

hDgn = IDgnFile::Make(); hDgn->DgnLoad(szFileName);

//Reading elements from the design file

//Scan the DGN file

IElement* hRecord;

IEnumRecords* hScan = hDgn->EnumRecords(NULL);

hScan->All();

while(hRecord=(IElement*)hScan->Next())

{

nest = hScan->Nest();

//If the record that’s currently being scanned is a graphics //record

if(hRecord->IsGraphics()){

//Read the line string element and obtain the

// coordinates

ILine2 *pElm = (ILine2 *) hRecord;

GLINE2 *point = pElm->GetGeoPtr();

49


print("x1=%d", point->p1.x);

print("y1=%d", point->p1.y);

print("x2=%d", point->p2.x);

print("y2=%d", point->p2.y);

print("Level=%d", hRecord->GetLevel());

Getting additional information about graphics elements can be done by calling the IEntity access methods that derives from the IElement object. The methods help obtaining information about symbology such as color style and weight etc.

Examples of a some methods are GetLColor(), GetLWeight() and GetLStyle().

In a similar matter, the API provides methods to access non graphics elements, header information and with attributes but that was not included in the implementation of the DGN toolkit test applications. [M11]

6.3.3 Writing to a Design File When writing to a design file, it is possible to either write to an existing file or create a new one. The following illustrates how a new file was created.

// Create a new initialized 2d dgn file

DgnTkInit(dgn::DgnLibVerNo(),true);

IDgnFile* hDgn = dgn::IDgnFile::Make();

hDgn->DgnNew(fileName,false); //true if 3d, false if 2d

// Elements can be added here…

// save the new file

hDgn->Changed();

Adding new elements to an existing DGN file object is done by using each element’s Make() method, specifying the IDgnFile, list id, and the model id to which the new element will belong. Below is an example of how and how a line string element can be added added to a design file.

// adding a 2d diagonal line from 0,0 to 10.0,10.0

ILine2* hNew = ILine2::Make(hDgn,DGN_LISTID_GEO,0);

GLINE2* pGeo = hNew->GetGeoPtr();

pGeo->p1.x = 0.0;

pGeo->p1.y = 0.0;

pGeo->p2.x = 10.0 * DistScale;

50


pGeo->p2.y = 10.0 * DistScale;

//saving the changes

hNew->Changed();

Element properties can also be set similar to the way coordinates can be set when writing new elements to a design file. The IEntity class that is derived from the IElement object and provides methods for setting symbology and other attributes to elements. Example of some methods are SetColor(), SetLWeight and SetLStyle(). [M11]

51


6.4 Evaluation of DGNdirect Toolkit

Below follows the requirements set for the evaluation and the results of DGNdirect toolkit on each aspect.

6.4.1 Compatibility with .NET Environment DGN Toolkit is compatible with the .NET framework. It is a code library implemented in C++ which makes it accessible from visual C++ .NET.

6.4.2 Independence DGN Toolkit is independent and does not require the installation of other software in order to enable usage. [I22]

6.4.3 Reliability The Open design alliance is the organization behind DGNdirect Toolkit. The alliance believes in open standards and is supported by Bentley Systems in order to maintain the software library that reads and writes Bentley’s format, V8 DGN. Because of the close cooperation with Bentley, the alliance can be seen as reliable to continue developing and updating the code library to insure its support for the design file format. [I22]

6.4.4 Documentation The documentation of DGN Toolkit consists of one User’s Guide document containing information about how the library represents design files and their contents. Short code examples are provided to illustrate implementation. The documentation is detailed but at times difficult to understand. It is difficult to get an overview of how the different kinds of classes relate to each other by reading the document. A UML drawing would have been very useful. Furthermore, three very helpful sample applications were provided that compensate some drawbacks in the documentation. The documentation and the samples were only accessible to licensed users of the library.

6.4.5 Development Support Development support for DGNdirect toolkit is very limited. Some help is provided on the web site but it far from satisfying. The open design alliance forum is a place online where Alliance members exchange tips on using the libraries and find answers to support questions. No other support system is provided. However, there are some very useful sample applications that can be downloaded that cover most of the features in the API and answer some questions that might arise. [I22]

6.4.6 Licence Costs The DGNdirect Toolkit requires a license. The costs depend on the purpose behind the use of the library. For commercial usage costs may be involved. In TietoEnator’s case, the library is aimed to be used only within the organisation and the license is therefore free of charge. [A4]

6.4.7 Functionality for reading V8 design files DGNdirect Toolkit is specialized to support reading V8 design files. The reading is done by scanning the content of the design file and storing it in the design file object type. Each element

52


that is scanned is stored as element objects in a list of elements. Different methods can then be used to access information about the elements. The data that is being read does not need to be known in any matter. DGNdirect Toolkit does not have to know the schema in advance. [M11]

6.4.8 Functionality for Writing to V8 Design Files and Creating New Design Files DGNdirect Toolkit supports creating completely new design files or loading an existing file, make modifications and write the revised design file. It is also possible to use a seed file as a template to create a new design file. You simply load an empty “seed” file and modify that to create a new design file. [M11]

6.4.9 Support for Representing MicroStation V8 Elements

Table 10 – The table lists some of the MicroStation 2D elements and their equivalence type in DGNdirect Toolkit. [M11].


MicroStation Type

DGN Toolkit type

3 LINE_ELM Cline2

4 LINE_STRING_ELM

CPath2

6 SHAPE_ELM CPoly2

7 TEXT_NODE_ELM

CTextNode2

11 CURVE_ELM CCurve2

15 ELLIPSE_ELM CElip2

16 ARC_ELM CEla2

17 TEXT_ELM Ctext2

6.4.10 Support for Use in Server-Client Architecture Using the DGNdirect Toolkit in Client-Server architecture is possible. When a file is loaded or saved, the path to the file is used as a parameter. Therefore, the files can be located on other machines and accessed by knowing the exact path. [M11]

53

Chapter 7 – Evaluation Part II

7 Evaluation Part II

This chapter presents the evaluation of the application programming interfaces used to insert data to and extract data from the spatial databases Oracle spatial and PostGIS. The API:s are as familiar ODP .NET and Npgsql.

As a complement to studying documentations of the API:s, test applications were implemented in order to acquire a greater understanding of the possibilities each API provided to insert and extract spatial elements.

Both test applications inserted a line string element into a spatial database, and extracted specifications of a line string element from the database spatial object. The purpose of extracting specifications such as coordinates and attributes is that the future .NET components that are being investigated about in this report will preferably need to have their own object classes and therefore, it is necessary to be able to create objects from the information that is extracted from the database.

Figure 15 – This is an overview picture of how the test applications on the database side look.

54


7.1 ODP .NET – Test Applications

In order to gain a better understanding of the suitability of the API:s, it was necessary to also look at the API:s from a more technical point of view and that is why implementation was interesting for the evaluation.

7.1.1 Implementation of Test Applications The simple test application for ODP .NET inserted and extracted a line string element to and from an Oracle 10g database. The experience from the implementation will be a basis for the evaluation together with specific requirements that will also be looked upon.

7.1.2 Insertion A MicroStation line string element consists of several parameters such as coordinates, type, color, level, style and weight. When inserting a line string element into Oracle spatial with ODP, the only way is to basically construct an SQL that takes the line string parameters and creates an SDO_GEOMETRY line string type. The same principle goes for any other elements that are to be inserted.

The most appropriate method to insert information in any database is often by using stored procedures, since it is a clean and simple way for data input. In Oracle, this required programming of a PL/SQL procedure in the database, that takes the Line string coordinates and attributes as input parameters, creates a spatial object and inserts the data into a spatial table together with the attribute data.

In addition to the line string parameters, it is also good to have an ID field that identifies the specific line string.

Figure 16 on the next page provides an overview of how the line string data was inserted. The code example below shows how the line string element defined when inserted into the SDO.GEOMETRY column. The first parameter 2002 defines that the element is a two dimensional line string.

MDSYS.SDO_GEOMETRY(2002, NULL,NULL,

MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1), -- linestring

MDSYS.SDO_ORDINATE_ARRAY(x1,y1,x2,y2)))

55


Figure 16 – The test application used for writing an element to Oracle spatial with ODP .NET.

56


7.1.3 Extraction The data extraction was also evaluated by using a simple test application that extracted a line string element, or more specifically line string parameters from a table in Oracle spatial.

This process was a bit more complicated than the insertion since you need to access the line string coordinates. The coordinates are stored within the object and can be accessed by calling spatial functions, which is not as simple as it might sound. Oracle spatial does not fully support the OGC-standards for easy input and output of spatial objects in text or binary format. [A2]

The OpenGIS specification defines two standard ways of expressing spatial objects: the Well-Known Text (WKT) form and the Well-Known Binary (WKB) form. Both WKT and WKB include information about the type of the object and the coordinates which form the object. [I1]

Because of that, the simplest way to get to the information was by using a stored procedure that returns the line string coordinates with a ref_cursor. With ODP it is then possible to get hold of the parameters in the ref_cursor. The figure below provides an overview of how the line string data was extracted from the database. The SQL query below shows the coordinates of the vertices of a line string element can be obtained in Oracle.

SELECT t.X, t.Y

FROM Table1 c,

TABLE(SDO_UTIL.GETVERTICES(c.shape)) t

Figure 17 – The test application used for reading an element from Oracle spatial with ODP .NET.

57


7.2 Evaluation of ODP .NET

Below follows the requirements set for the evaluation and the results of ODP .NET on each aspect.

7.2.1 Compatibility with.NET ODP is an API intended for usage in .NET. The compatibility with the .NET environment and visual studio is therefore very satisfying. An installation of ODP .NET is very simple and after the product has been installed, visual studio detects the .dll file automatically and the ODP help is then included in the Visual Studio. [M8]

7.2.2 Independence An installation of an Oracle database is necessary in order to be able to use ODP. No other dependencies are attached. [I3]

7.2.3 Reliability Oracle is a leading database vendor with excellent documentation of their products. Being one of the established database suppliers worldwide, constantly updating products with new functionalities to meet the demands of their customers, Oracle is very reliable. The reliability concerns both development support and upgrading of products. [I3]

7.2.4 Documentation Oracle is well known for good and thorough documentation. In addition to that, there are very useful free sample applications following with the documentation. The documentation of ODP is very detailed and covers all features in detail. Moreover, many very useful free samples are provided on the Oracle web site. [I3]

7.2.5 Development Support Oracle provides several channels for support. The web support portal Metalink is one place where support is provided. Customers with an active support contract can register and search previous solutions by product, problem type, and release. Furthermore, on Metalink customers can access information about Oracle products, technology and services.

Another portal of support is Oracle Technology Network which is Oracles online support community where Oracle users can share ideas and help solving each others problems. A membership in this online community is free and after registering the member can get access to product documentation, read technical articles and discuss problems with other users in discussion forums.

A third channel from which users can learn more about Oracle technologies is OLN – Oracle learning network. OLN is a portal that offers online courses and web seminars.

Tutorials from Oracle experts, quizzes, demonstrations, practices and simulations are also available for OLN members. However, an OLN membership is not free and each course requires a fee. [13]

58


7.2.6 License Costs The costs in this matter are related to the license of the database. ODP .Net is itself a cost free API. An Oracle database license with spatial extension is quite expensive and depends on the number of CPU’s. For a standard customer to a company with the size of TietoEnator Telecom operators, the cost is approximately 100 000 SEK for the product and 20 000 SEK for support per year according to Oracle in Sweden. [A3]

7.2.7 Support for Spatial Data Types and Representation of MicroStation Elements ODP .NET does not support all Oracle data types, but a large majority of those. The spatial data types are for example not supported by ODP. It is possible to insert and extract spatial types without using ODP .NET supported types.

Calling stored procedures with input parameters is an effective method. All Oracle spatial element types can be inserted and extracted in .NET by using ODP. The MicroStation elements can for example be translated into the following Oracle spatial types. [M8]

Table 11 – MicroStation types and their corresponding Oracle Spatial types [M7].


MicroStation Type

Oracle Spatial Type

3 LINE_ELM Line string

4 LINE_STRING_ELM

Line string

6 SHAPE_ELM Polygon

7 TEXT_NODE_ELM

Point

11 CURVE_ELM Arc line string

15 ELLIPSE_ELM Optimized polygon

16 ARC_ELM Optimized polygon/Arc line string

17 TEXT_ELM Varchar2

59


7.2.8 Support for Calling Stored Procedures and Functions ODP provides functionality for calling functions and stored procedures from .NET applications with input parameters. Working with output and input output parameters is also supported. [M8]

OracleCommand cmd = new OracleCommand("myTestProcedure",connection);

cmd.CommandType = CommandType.StoredProcedure;

// Instantiate Oracle parameters

OracleParameter paramCoordinate_x = new OracleParameter("x",OracleDbType.Int32);

paramCoordinate_x.Direction = ParameterDirection.Input;

//Data to put into table paramCoordinate_x.Value = 11;

// Add Oracle Parameters to Command

cmd.Parameters.Add(paramCoordinate_x);

cmd.ExecuteNonQuery();

ODP also supports calling procedures with output and inputoutput parameters by setting the ParameterDirection to Output or InputOutput.

7.2.9 Support for Use in Server-Client architecture

The connection to an oracle database is created as shown below. string constr1 = "User Id=myschema;Password=mypwd;Data Source=oracle";

OracleConnection con1 = new OracleConnection(constr1);

con1.Open();

The connection data source can easily be set to call a database on another machine, perhaps a server machine, since data sources are defined with IP addresses. [M8]

7.2.10 Support for Datasets With ODP it is possible to populate DataSets in .NET from ref cursors but also populating tables with DataSets. Furthermore ODP enables updating LOBs using DataSets. [M8]

7.2.11 Support for Ref Cursors [M8] The REF CURSOR is a data type in the Oracle PL/SQL language. It represents a cursor or a result set in the Oracle database. The OracleRefCursor is a corresponding ODP.NET type for the REF CURSOR type.

60


ODP supports several features related to ref cursor use. For example it is possible to obtain a REF CURSOR as an OracleDataReader, DataSet, or OracleRefCursor.

Obtaining an Oracle REF CURSOR as an OracleDataReader type is done by calling the OracleCommand ExecuteReader method. If there are multiple output REF CURSOR parameters, the OracleDataReader NextResult method can be used to access the next REF CURSOR. The OracleDataReader NextResult method provides sequential access to the REF Cursors; only one REF CURSOR can be accessed at a given time.

The order in which OracleDataReader objects are created for the corresponding REF CURSOR depends on the order in which the parameters are bound. If a PL/SQL stored function returns a REF CURSOR, then it becomes the first OracleDataReader and all the output REF CURSOR objects follow the order in which the parameters are bound.

REF Cursors are not updatable. However, data that is retrieved into a DataSet can be updated. ODP allows REF CURSORS to populate DataSets.

Populating an OracleRefCursor From a REF CURSOR is another feature that ODP provides.

If the REF CURSOR is obtained as an OracleRefCursor object, it can be used to create an OracleDataReader or populate a DataSet from it.

With the latest version of ODP .NET, it is not only possible to retrieve data from a ref cursor but also possible to pass a ref cursor as an input parameter to a PL/SQL stored procedure or function.

The code example below illustrates using ref cursors in both directions.

static void Main(string[] args)

{

string constr = "User Id=hr; Password=hr;Data Source=oramag; Pooling=false";

OracleConnection con = new OracleConnection(constr);

con.Open();

OracleCommand cmd = con.CreateCommand();

cmd.CommandText = "begin open :1 for

select * from employees

where manager_id=101; end;";

OracleParameter p_rc = cmd.Parameters.Add(

"p_rc",

OracleDbType.RefCursor,

DBNull.Value,

ParameterDirection.Output);


cmd.Parameters.Clear();

cmd.CommandText = "cursor_in_out.process_cursor";

cmd.CommandType = CommandType.StoredProcedure;

OracleParameter p_input = cmd.Parameters.Add(

61


"p_input",

OracleDbType.RefCursor,

p_rc.Value,

ParameterDirection.Input);


p_input.Dispose();

p_rc.Dispose();

cmd.Dispose();

con.Dispose();

}

62


7.2.12 Large Object Support There are two basic types of LOB data—binary and character—and both are accessible via ODP.NET. LOB data types are quite flexible and excel at handling small amounts of data as well as extremely large amounts.

The Large Character data types in Oracle are:

• CLOB - Character data can store up to 4 gigabytes (4 GB).

Large Binary data types:

• BLOB - Unstructured binary data can store up to 4 gigabytes.

• BFILE - Binary data stored in external file can store up to 4 gigabytes.

ODP.NET makes it easy to access and work with LOB data. All LOB objects within ODP.NET inherit from the Stream class provided by the .NET framework and are connected objects. LOB data types are supported by ODP.NET via the OracleBlob, OracleBFile , and OracleClob classes.

Table 12 – The Oracle LOB types and their corresponding ODP type.

Oracle LOB Type ODP.NET LOB object

BFILE OracleBFile object

BLOB OracleBlob object

CLOB OracleClob object

The ODP.NET LOB objects can be obtained by calling the proper typed accessor on the OracleDataReader or as an output parameter on a command execution with the proper bind type.

Oracle spatial also provides a special feature apart from the large object support that is specialized to manage raster images.

GeoRaster is a feature of Oracle Spatial in Oracle Database 10g that allows storing, indexing, querying, analyzing, and delivering GeoRaster data, that is, image and gridded raster data and its associated metadata. [I20] This feature is however not supported by ODP .NET. [M8]

7.2.13 Support for Bind Variables From a performance point of view, bind variables are a very useful when working with statements.

When Oracle Database 10g is presented with an SQL statement, it checks a shared memory area to see if the statement already exists and is stored in memory. If the statement does exist in memory and Oracle Database 10g can reuse it, then the database can skip the task of parsing and optimizing the statement.

With bind variables, the likelihood that SQL statements will be stored in memory increases greatly. That makes the statements available quickly to the next operation that needs them. In other words, a statement that is called several times requires fewer resources from the database.

If the statement doesn't exist in the shared pool, then the database must parse and optimize the statement and that's where performance might be reduced.

63


The following c# code example shows how a statement with an input bind variable is executed with ODP.

string constr = "User Id=hr; Password=hr; Data Source=oramag"; OracleConnection con = new OracleConnection(constr); con.Open(); StringBuilder sbSQL = new StringBuilder(); sbSQL.Append("select country_name "); sbSQL.Append("from countries "); sbSQL.Append("where country_id = :country_id"); OracleCommand cmd = new OracleCommand(); cmd.Connection = con; cmd.CommandText = sbSQL.ToString(); OracleParameter p_country_id = new OracleParameter(); p_country_id.OracleDbType = OracleDbType.Varchar2; p_country_id.Value = "UK"; cmd.Parameters.Add(p_country_id); OracleDataReader dr = cmd.ExecuteReader(); if (dr.Read()) { Console.WriteLine("Country Name: {0}", dr.GetOracleString(0)); }

64


7.3 Npgsql – Test Applications

In order to gain a better understanding of the suitability of the API:s, it was necessary to also look at the API:s from a more technical point of view and that is why implementation was interesting for the evaluation.

7.3.1 Implementation of Test Applications The applications that were used to evaluate Npgsql also inserted and extracted a line string element to and from a PostgreSQL 8.1 server. Again, the implementation will be a basis for the evaluation of Npqsql together with the predefined requirements.

7.3.2 Insertion During the implementation of this test application, some interesting differences between the databases and their spatial extensions were discovered. In Oracle, the use of stored procedures simplified the insertion process quite a lot. With PostGIS it was just as easy to insert an element by just calling existing spatial functions. The functions in PostGIS are very user friendly and simple to call. The line string was easily created and the SQL for the job was not as complicated as in Oracle spatial.

The line string was created and inserted into a table simply by calling the function GeometryFromText in a standard SQL for inserting data to a table.

The -1 indicates no specified SRID. GeometryFromText('LINESTRING(10 15, 21 34)', -1))

Figure 18 – The test application used for writing an element to PostGIS with Npgsql.

Of course, a stored procedure can also be used to insert the element and it is often preferable to use procedures when dealing with insertion of large amounts of data. To confirm that it was possible, a stored procedure that inserted the element was also created for testing Npgsql.

65


7.3.3 Extraction A test application similar to the one used for extracting data with ODP was created to evaluate Npgsql. Extracting information about the line string object was very simple thanks to functions that made it very convenient to access the coordinates.

PostGIS provides functions that return spatial elements represented in text and characters in an easy way. Because of that, using procedures for accessing data about the spatial elements is not necessarily the way to go with PostGIS. Obtaining results directly in .Net can be just as simple.

The following statement illustrates how line string coordinates can be retrieved using functions in PostGIS. The function X takes a point and returns its x coordinate. The StartPoint function takes a geometry object and returns its first point. The same principle goes for functions Y and EndPoint.

select X(StartPoint(geom)), Y(StartPoint(geom)), X(EndPoint(geom)), Y(EndPoint(geom)

Figure 19 – The test application used for reading an element from PostGIS with Npgsql.

66


7.4 Evaluation of Npgsql

Below follows the requirements set for the evaluation and the results of Npgsql on each aspect.

7.4.1 Compatibility with.NET environment Npgsql is just as ODP an API intended for usage in .NET. The compatibility with the .NET environment is therefore evident. However, Npgsql is not as integrated with visual studio as ODP. The .dll file is added to visual studio manually and installing the library on a work station or server is somewhat complicated. [I8]

7.4.2 Independence Besides from an installation of the PostgreSQL database and the PostGIS addition for spatial functions, no other dependencies are required. [I8]

7.4.3 Reliability of Supplier This aspect is always an issue with open source products. There is no guarantee for the product’s longevity. The fact that Npqsql and PostgreSQL are not as extended as fully commercial products and fewer people master them makes them less reliable from an investment point of view despite the fact that functionalities are satisfying. Updates of Npqsql are closely dependent on updates of the database software. PostgreSQL is a product that has existed for some time and updated versions have continuously been developed. Still the question of guarantees for future software updates might still arise when choosing this type of open source software. More importantly there is also a time aspect involved when discussing reliability of a supplier. Customers and users constantly develop new demands that trigger the need of extensions and updates of the software and often, time is important. Therefore, reliability goes hand in hand with how the resources the supplier can invest in further development of the software to quickly. Large companies have the advantage of having more resources and therefore the companies behind them can offer their customers updated software more frequently. A product that costs money does not necessarily have to be better but it can be considered as more reliable because the costs sponsor resources and thereby the longevity of the software. In a sense, you could say that you get what you pay for in terms of reliability. [I8]

7.4.4 Documentation The only available documentation of Npgsql is a user manual and an API overview. Those cover the most necessary parts. The manual provides a very short introduction to the API explaining functionalities with simple code examples. It is a very short document that does not textually explain any details which is a clear disadvantage. The code samples could have been supplemented with explanations concerning the functionalities and possibilities. Other than the short code samples in the manual, no other samples are provided which is another disadvantage. Providing advanced samples to illustrate the full capability of the API would have been quite useful. The API overview is a very good way to learn more about what classes that exist but such documentation is more useful when the user knows how to implement functionality but needs to know the code specific details. The poor user manual failed to provide such in-depth information about Npgsql that would make the API overview useful to those who are not familiar with Npgsql.

67


7.4.5 Development Support The Npqsql project group have created two public web forums on the project web site where Npgsql users can support each other and help answering each others questions. One forum is a help forum where specific questions are asked and public help is provided. The other forum is an open discussion forum for general discussions. Both forums depend on the generosity of other users to provide help. No support is given by the team behind Npgsql which makes it almost impossible to get help if no other users can provide it.

The forums are very well visited and almost all questions raised have been answered by members of the project team themselves or other knowledgeable users, so the support system seems to work surprisingly well. [I8]

7.4.6 Licence Costs Both PostgreSQL and Npgsql are so called open source products and using them does not require any license costs, which always is an advantage for companies from an investment point of view. [I8]

7.4.7 Support for Spatial Data Types and Representation of MicroStation Elements Npgsql supports almost all PostgreSQL data types. The spatial data types are also supported by the API, which means that they can be used directly in the .NET application. [M10] All PostgreSQL spatial element types can be inserted and extracted in .NET with Npgsql.

The MicroStation elements can be translated into the following PostGIS spatial types.[M2]

Table 13 – MicroStation types and their corresponding PostGIS types.[M2]


MicroStation Type

PostGIS Type

3 LINE_ELM Line

4 LINE_STRING_ELM

Path

6 SHAPE_ELM Polygon

7 TEXT_NODE_ELM

Point

11 CURVE_ELM Path

15 ELLIPSE_ELM Polygon

16 ARC_ELM Arc

17 TEXT_ELM Text

7.4.8 Support for Calling Stored Procedures and Functions Npqsql provides functionality for calling functions and procedures from .NET applications. To call a function, you just set the CommandType property of the NpgsqlCommand object to CommandType.StoredProcedure and pass the name of the function you want to call as the query string. Below is a basic example that illustrates how procedures are called with Npgsql. [M9]

68


Code example for calling a procedure with an input parameter: //Setting the command type to StoredProcedure NpgsqlCommand cmd = new NpgsqlCommand("myTestProcedure", connection); cmd.CommandType = CommandType.StoredProcedure; NpgsqlParameter param = new NpgsqlParameter("i_Number", DbType.Int64); param.Value = 100; param.Direction = ParameterDirection.Input; cmd.Parameters.Add(param); NpgsqlDataReader reader = cmd.ExecuteReader(); while ( reader.Read() ) { //etc... }

The parameter direction can be changed to output or inputoutput depending on the function or procedure that is being called. [M9]

ParameterDirection.Output

ParameterDirection.InputOutput

7.4.9 Able to use in Server-Client Architecture Npgsql can be used in client server architecture. The connection string parameter can easily be replaced with a database located on another machine. [M9]

NpgsqlConnection conn = new NpgsqlConnection("Server=127.0.0.1;Port=5432;UserId=user1;Password=secret;Database=mydb;");

conn.Open();

7.4.10 Support for Datasets Npgsql can be used for working with Datasets. This makes it possible to do changes in the dataset and have them propagated back to the database. [M9]

7.4.11 Support for Ref Cursors Obtaining ref cursors is possible with Npgsql, which enables obtaining whole resultsets from procedures and functions in the database.

The example below illustrates how a ref cursor is retrieved from a procedure that returns one. NpgsqlTransaction t = conn.BeginTransaction();

NpgsqlCommand command = new NpgsqlCommand("procedyreGetRefCursor", conn);

command.CommandType = CommandType.StoredProcedure;

NpgsqlDataReader dr = command.ExecuteReader();

If the procedure returns several ref cursors as output parameters they can be added to a NpgsqlCommand. Parameters collection and handled in the same way.

69


However, Npgsql does not support using ref cursors as input parameters. [M9]

7.4.12 Large Object Support Npgsql supports dealing with large objects and uses the PostgreSQL large object type to enable such functionality. It is possible to store and retrieve files or images with Npgsql by using the LargeObject object. However, neither PostGIS nor Npgsql have any features to support managing raster images in a structured way. [17]

7.4.13 Support for Bind Variables To send a parameterized query, meaning a query with bind variables, to the database server the NpgsqlParamenter or NpgsqlParamenterCollection objects are used. The parameter is a string prefixed by : in the query string. [M9]

Npqsql supports the Input, Output and InputOutput parameter directions. Note that Npgsql "simulates" output parameters by parsing the first result set from the execution of a query and translating it to output parameter value. This is done in one of two ways, either mapped or not. A mapped parsing, tries to match the column name returned by result set into a parameter with the same name. If a match is found, only the output parameters which have a match will be updated. If a mapping is not found, the output parameters are updated based on the order in which they were added to the parameter collection. [M9]

Below is a code example with bind variables in Npgsql: NpgsqlConnection conn = new NpgsqlConnection("Server=127.0.0.1;Port=5432;User Id=joe;Password=secret;Database=joedata;");

conn.Open();

// Declare the parameter in the query string

NpgsqlCommand command = new NpgsqlCommand("select * from tablea where column1 = :column1", conn);

// Now add the parameter to the parameter collection of the command specifying its type.

command.Parameters.Add(new NpgsqlParameter("column1", DbType.Int32));

// Now, add a value to it and later execute the command as usual.

command.Parameters[0].Value = 4;

try

{

NpgsqlDataReader dr = command.ExecuteReader();

while(dr.Read())

{

for (i = 0; i < dr.FieldCount; i++)

{

Console.Write("{0} \t", dr[i]);

}Console.WriteLine();}

70

Chapter 8 - Analysis

8 Analysis The evaluation of the different API:s has hopefully shed some light upon the possibilities that each API provides in terms of reading and writing spatial information and V8 design files. The experiences from the test applications and the requirements that were evaluated together form a basis for a discussion about each API:s suitability for the purpose of building .NET components. As mentioned in chapter 2, this report is an evaluation that investigates about API:s to use for building .NET components for an easier and more beneficial conversion process and a basis for future development of GIS functionalities in current applications.

8.1 FME Objects vs. DGNdirect Toolkit

FME objects and DGNdirect Toolkit are both .NET compatible code libraries that support reading and writing all the MicroStation elements listed in the requirements and many more. Although many of the functionalities in the requirements are fulfilled by both API:s, the methods in which they read and write look different. DGNdirect Toolkit reads the entire file content, interprets it and saves it as a design file object. Other classes in the API are then used to access different parts of the object. FME Objects does not represent the design file with an object. Instead, the content is read and translated into a set of objects called FME features. Those features can then be written to another file format or help accessing the content of the design file.

Another difference is the language in which the API:s are implemented. FME Objects is easy to use from C#, Visual basic, Java, C++ and C which offers more diversity. Diversity and freedom to choose among more languages is an advantage when planning the implementation of .NET components and the competences that are required. DGNdirect is implemented in C++ and therefore delimits the choices of programming languages for development of .NET components.

Moving on, it is optional to use seed files with DGNdirect Toolkit when creating new design files or writing to already existing files. With FME Objects, a seed file is mandatory when writing to design files. If a suitable seed file does not exist, the outcome of the writing will not be as planned. When reading many of design files that all look different and have different preferences, the need for changing seed files will be an issue that has to be overcome.

FME Objects fails the independence requirement since FME Objects is not independent and can only be used with an FME Suite installation. That is a disadvantage since the goal with this feasibility study is to evaluate possibilities for planning to build independent .NET components. DGNdirect Toolkit is on the other hand independent and does not require any other installations in order to work.

Using FME Objects requires purchase of license whereas DGNdirect Toolkit is free. Furthermore, buying FME objects could mean paying for functionalities that are never going to be used. However, with the costs of FME Objects come many benefits. The support that Safe software offers is very extensive and the documentation of FME Objects is detailed and useful. Compared to FME Objects, the DGNdirect documentation is not as extensive but it is still satisfying because of the level of detail it contains. The development support is also an area where FME Objects is better. Fortunately, very helpful sample applications are provided for DGNdirect Toolkit which compensates the poor development support at times.

There are also differences in what other possibilities the API:s provide. FME objects does not only interpret the Design File format but supports many other formats and features as well. Among those other features is the support for directly inserting and extracting design file content in and out from spatial databases. That would be an advantage when developing .NET

71


components since all parts of the conversion process then could be handled by using FME Objects. However, those features come with additional costs since they require a special license. With an FME suite professional license, it is possible to read and write design file data directly from a file to Oracle spatial or PostGIS. The procedure can therefore only be implemented in .NET using a professional edition of FME Objects.

Being a large company with many resources, Safe Software can offer continual updates and improvements of their products, which makes them a reliable supplier. DGNdirect Toolkit is developed by a well known organisation and is the result of cooperation with Bentley, the company behind the design file format. Therefore the Open Design Alliance can be considered reliable to update the software when it is needed. However, the resources of Open Design Alliance are limited compared to Safe Software.

FME Objects is a product widely used around the world. Its usefulness in conversion between formats can not be overlooked. The experiences from the implementation of the test applications showed that FME is very powerful when converting from one FME supported format to another. Even though it is possible to create FME feature objects on application level, the strength of FME lies in conversion between already supported formats. It is therefore better suited for situations where the schema of the data that is being read has to be known on pre hand. DGNdirect Toolkit is not as acknowledged as FME Objects, but it is specialized on design files and it does not need to know the schema of the data before it is read.

The conclusion is that there are a few small differences concerning functionality between FME Objects and DGNdirect toolkit. The more conspicuous differences concern license costs, independence, documentation and support.

72


8.2 ODP vs. Npgsql

Both API:s proved to fulfil requirements for insertion and extraction of information surrounding the geometrical elements. The spatial DBMS:s are both able to represent all elements listed in the requirement with their own spatial types. Furthermore, Npgsql also supports representation of the spatial types as Npgsql .NET data types which is something that ODP currently does not. Supporting spatial types directly in .Net is an advantage for building .NET components since the spatial objects can be created on application level without the interference of SQL-statements for creating them. Moving on, all technical requirements such as support for use in client server architectures, bind variable use, support for procedure and function calls and LOB support were fulfilled by both API:s.

Therefore, from a functional point of view, both ODP and Npgsql are suitable candidates that respond to many of the prerequisites that future .NET components need. The difference in some areas is that ODP offers more extensive features, for example when dealing with ref cursors. ODP supports passing a ref cursor as an input parameter to a PL/SQL stored procedure or function, which Npgsql does not. Datasets is another area where ODP seems to offer a broader range of possibilities. ODP not only supports updating data reader objects with ref cursors as Npgsql does, but with ODP you can also update datasets and the ODP ref cursor type with ref cursors. More features leads to more possibilities and thereby flexibility in the development process of .NET components.

Judging from the experience from the test applications, PostGIS offers easier methods for accessing the spatial information about objects in the database. Many functions for extracting the information or creating spatial object from textual parameters already exist in PostGIS and OGC standards for representing geometries as text are better followed by PostGIS than by Oracle spatial. Using Oracle spatial and ODP can require spending more time programming PL/SQL procedures that simplify the extraction of information from geometrical objects in the database. The fact that Oracle does not provide easy ways to retrieve spatial data in textual form is a disadvantage since it makes the applications dependent on stored procedures that will require time and resources to develop. Procedures are beneficial from a performance point of view when inserting and extracting large amounts of information but at the same time, being forced to use procedures does not support the idea of having a completely .NET based conversion process, or at least to a very large extent.

One area where ODP and Npgsql really differed was documentation and development support. Oracle offers excellent documentation and many sources for development support, whereas PostgreSQL offered poor documentation and had very limited development support resources. Npgsql users have to completely rely on getting help and support from other users. Since PostgreSQL is not as widely established as Oracle and the documentation is insufficient, the development support is not impressive. An explanation to this is that Oracle licenses cost a great deal and PostgreSQL is free. Oracle evidently has the money and thereby the resources to invest in good documentation and support. Npgsql is an open source API developed by an independent team of programmers with much less resources to put on documentation. Although it is evident that you get what you pay for and that a company would save large amount of money by choosing PostgreSQL and Npgsql instead of Oracle and ODP, an Oracle license also provides insurance of continual software updates. The Npgsql development team can never guarantee the same services and reliability as a multibillion company.

The choice of API for reading and writing spatial data to and from the database is partly dependent on the functionality and partly on the services provided by the code libraries and the license costs. Functionality is an area where ODP and Npgsql do not differ very much. ODP has some extra features but Npgsql manages to read and write spatial information according to the

73


requirements in the evaluation. The choice should therefore be based on the costs of the software, the supplier’s reliability, documentation and development support.

74


8.3 Recommendations

The choice of API:s for building .NET components will be based on the results of the evaluation meaning how well each API fulfilled the requirements set up in the evaluation weighting functionality against other properties such as documentation and support.

An investment such as the implementation of .NET components must take future demands and changes in consideration. The goal with the investment is to enable an easier and more beneficial conversion process of V8 design files. Keeping the costs down is always essential but that does not mean that you should always choose the cheapest alternative. A cheap alternative that proves to be insufficient further on could end up costing more.

In the case of database API:s, it is theoretically possible to proceed with the open source alternative Npgsql since the requirements concerning functionalities are all fulfilled.

Npgsql requires using the PostGIS database and PostGIS gives easier access to spatial elements than Oracle spatial does. Using Oracle could therefore mean having to spend time developing procedures for easier access. However, the documentation and support that Oracle provides is very detailed with many advanced samples which might speed up the development process. Oracle is also an established and reliable vendor. To be able to adjust the conversion and development of .NET components to future changes and demands is important for the survival of the solution. That is why reliability should be considered as an important aspect when choosing API.

TietoEnator currently uses Oracle to store spatial information. Changing database vendor to PostGIS would mean spending time and money on migrating data and data models. Changing vendor must be worth the effort. An Oracle license costs a great deal but the costs come with services and insurance of the products future longevity. In my opinion, choosing PostGIS and Npqsql means taking a risk that could end up costing more than buying an Oracle license. First of all, with Npgsql you would probably have to spend more time on developing the .NET components because of the poor documentation and lack of satisfying development support. Secondly, a product that is a result of an open source initiative is not as reliable as a product developed by one of the world’s largest database vendors.

Moving on to the other part of the evaluation, the choice is between FME Objects and DGNdirect Toolkit.

Both API:s are more or less useful for the development of .NET components since they both fulfil all functionality requirements for reading and writing design files. The methods in which they work are however different.

FME Objects is very powerful when converting from different FME supported formats. For example converting from XML to design files or directly from a database to any other FME supported format. DGNdirect Toolkit does not handle conversions and is only specialized on reading and writing design files which perhaps is the reason why it seems to suit the purpose of .NET components better. The cooperation between Bentley and Open design alliance has resulted in a very integrated API that is relatively simple to use. For example when writing to a design file, elements are added to directly the file object and in a simple way. The fact that there are no license costs involved is another advantage with DGNdirect Toolkit.

Furthermore, the fact that FME Objects is not an independent API and depends on an FME Suite installation is a great disadvantage since one of the requirements specifically demanded independence. Adding the license costs of FME to the list of disadvantages makes the choice rather simple.

75


FME Objects comes with better documentation and support compared to DGNdirect Toolkit. FME Objects also offers a greater freedom of choice in choosing a programming language for creating .NET while DGNdirect Toolkit requires developing in C++.

However, DGNdirect Toolkit provides satisfying documentation and support and combined with the advantages of being free, independent and providing all the necessary functionality needed, it appears as a quite sensible choice.

76


8.4 Conclusion

The evaluation in this feasibility study showed that the best API:s to use for the conversion of V8 design files and for building independent .NET components are ODP.NET provided by Oracle and DGNdirect Toolkit provided by Open Design Alliance.

The recommendations were very hard decisions to make since all API:s proved to fulfil many of the functional criteria’s.

The reasons behind those two recommendations are based on a combination of how well the code libraries fulfilled all the requirements of the evaluation and their suitability for the purpose of working as a basis for the development of independent .NET components.

ODP .NET is recommended mainly because of the excellent documentation and support provided by Oracle. An Oracle license is expensive, which is a clear disadvantage. However, considering reliability and other factors such as the fact that Oracle provides functionality for topological queries [17] makes ODP .NET and Oracle a good choice with respect to possible future development of GIS applications.

DGN direct Toolkit appeared to be the best choice for reading and writing design files because of its specialization on the design file and ability to read design files without needing to know the schema of the data in advance. Furthermore, the most important aspect is that DGN Toolkit stands on its own without depending on other products. Therefore it is highly suitable for building independent .NET components.

8.5 Future Outlook for .NET Components

The results of this report showed that it is possible to use already existing code libraries to build an independent .NET API called .NET components used for reading and writing the MicroStation V8 design file format. The use of .NET components and the use of .NET overall, for the purpose of reading and writing design files also seems to be a suitable choice when it comes to the choice of platform. Bentley which is the company behind MicroStation has recently presented MicroStation XM which is a new version of their program which is more compatible with .NET. The new XM edition is also compatible with Oracle spatial 10g. The integration with Oracle and .NET will affect the development of .NET components positively. In a long term perspective, the evolvement of the .NET components with the recommendations made in this report has a very positive future outlook. [I23]

77

9 Appendix

9 Appendix API Application Programming Interface

BFILE A Binary File is a file that contains binary data.

BLOB Binary Large Object. Data that is not stored as a text string. When such data is stored in a database, it is called a BLOB.

CAD Computer Aided Design

CLOB Character Large Object. In database contexts, for example XML-files can be stored as CLOB’s.

DBMS Database Management System

DGN The filename extension of Microstation Design files.

FME Feature Manipulation Engine. Software that is used for conversion between different file formats, including files storing spatial information.

GIS Geographical Information Systems

MicroStation V8 CAD Software for modeling

.NET Microsoft Windows platform.

Object Relational DBMS Database management system for object relational databases.

ODP .NET Oracle Data Provider for .NET.

PL/SQL PL/SQL is Oracle's Procedural Language extension to SQL. and can be used to program procedures and functions.

Relational DBMS A database management system for relational databases.

Spatial Database A database that can manage geometries as spatial objects.

SQL Structured Query Language, a query language used for managing databases.

V7/V8 Version 7 and 8 of the MicroStation design file.

78

References

References

Literature

[1] Shashi, S & Sanjay, C. (2003). Spatial databases A tour. New Jersey. Pearson Education, Inc.

[2] Rigaux, P. Scholl, M & Voisard, A. (2002). Spatial databases with application to GIS. San Francisco. Morgan Kaufmann Publishers.

[3] Matthew, N. & Stones, R. (2005). Beginning databases with PostgreSQL from novice to professional. New York. Apress.

[4]Chrisman N.(1997). Exploring Geographic Information Systems. Toronto. John Wiley & Sons inc.

[5]Fischer M., Scholten Henk.J., Unwin D. (1996). Spatial Analytical Perspectives in GIS. Bristol. Taylor & Francis.

[6]Lars Eklundh (Red). (2001). Geografisk informationsbehandling, metoder och tillämpningar. Byggforskningsrådet. P.11-29, 33-38, 119-148(kap5), 321-338

[7]Longley P A., Goodchild M F., Maguire D J., Rhind D W. (1999). Geographic Information Systems, Management Issues and Applications. Volume2. USA. John Wiley & Sons inc. ISBN 0471-33133-3.

[8]Kothuri R., Godfrind A., Beinat E., (2004). Pro Oracle Spatial. New York. Springer Verlag. ISBN 1-59059-383-9.

[9]Templeman J., Olsen A., (2002). Visual C++ .NET. Washington. Microsoft Press. ISBN 0-7356-1567-5.

[10] Oracle Corporation. (2003). Oracle spatial, user’s guide and reference.

[11] Worboys, M & Duckham, M. (2004). GIS: A computing perspective. nd 2 edition. CRC press.

[12] Silberschatz, A. Henry, F & Korth, S. (2002). Database system concepts, th 4 edition . ISBN 0-07-112268-0

79

References

[13] Connolly T., Begg C. (2002). Database systems,3rd edition .Pearson Education Limited. ISBN 0-201-70857-4

[14] Oracle Database (2003). SQL Reference 10g Release 1. Part No. B10759-01

[15] Geringer.D, Abugov.D. (2002), Oracle University, Learn Oracle From oracle, Oracle 9i Database: Spatial. Student Guide vol1

[16] Geringer.D, Abugov.D. (2002), Oracle University, Learn Oracle From oracle, Oracle 9i Database: Spatial. Student Guide vol2

[17] Abravesh B. (2006), DSV, Utvärdering av lämplig databasteknologi för lagring av spatial-information.

[18] Deitel P., (2002). Prentice Hall, C# How to program. ISBN 0-13-062221-4

Manuals

[M1] PostgreSQL 8.0

http://www.PostgreSQL.org/docs/8.0/static/index.html

[M2] PostGIS 1.0

http://postgis.refractions.net/docs/

[M3] Pgadmin III

http://phppgadmin.sourceforge.net/

[M4] Oracle 10 g

http://www.oracle.com/technology/documentation/

[M 5] MapGuide

http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=1992156

[M6] MapInfo

http://extranet.mapinfo.com/common/docs/mapxtend-user-2.1-webeng/ docs/guide/userguide/introduction.htm

80

http://www.postgresql.org/docs/8.0/static/index.html

http://postgis.refractions.net/docs/

http://phppgadmin.sourceforge.net/

http://www.oracle.com/technology/documentation/

http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=1992156

http://extranet.mapinfo.com/common/docs/mapxtend-user-2.1-webeng/

References

[M7] Oracle Spatial

http://www.oracle.com/technology/products/spatial/spatial_10g_doc_index.html

[M8] ODP manual: Oracle10g Release 2 Data Provider for .NET (10.2.0.1) Developer's Guide

http://www.oracle.com/technology/docs/tech/windows/odpnet/index.html

[M9] Npgsql User manual

http://npgsql.projects.PostgreSQL.org/docs/manual/UserManual.htm

[M10] Npqsql API docs

http://npgsql.projects.PostgreSQL.org/docs/api/

[M11] The DGNdirect DGN File Toolkit. User’s Guide. Version 0.993(beta). August 29, 2005, OpenDWG Alliance.

[M12] MicroStation V8 File Format Reference. Bentley Systems Incorporated. 2003.

[M13] MicroStation V8 user manual. Bentley Systems Incorporated. 2003

[M14] Safe Software. FmeGetting started.

http://www.safe.com/products/developer-tools/fme-objects/index.php

[M15] Safe Software. FMEReadersWriters..


[M16] FMEObjectsDotNetTutorial.


[M17] BuildingAppsWithFMEObjects.


[M18] FME Objects Quick start guide

http://www.safe.com/support/online documentation/FMEObjects_QuickStart/quickstart.htm

[M19] FME Objects dev guide


81

http://www.oracle.com/technology/products/spatial/spatial_10g_doc_index.html

http://www.oracle.com/technology/docs/tech/windows/odpnet/index.html

http://npgsql.projects.postgresql.org/docs/manual/UserManual.htm

http://npgsql.projects.postgresql.org/docs/api/





http://www.safe.com/support/online%20documentation/FMEObjects_QuickStart/quickstart.htm

http://www.safe.com/support/online%20documentation/FMEObjects_QuickStart/quickstart.htm


References

Internet sources

[I1] PostGIS

http://postgis.refractions.net/index.php

[I2] PostgreSQL

http://www.PostgreSQL.org

[I3] Oracle

http://www.oracle.com

[I4] ESRI Sweden

http://www.esri.se

[I5] Safe Software

http://www.safe.com

[I 6] ODP .NET Feature Overview

http://www.oracle.com/technology/tech/windows/odpnet/ODP.NET-FOV.html

[I7] Bentley

http://www.bentley.com

[I8] Npgsql Project Site

http://pgfoundry.org/projects/npgsql

[I9] ESRI

http://www.esri.com/software/arcgis/arcgisengine/about/overview.html

[I10] FME support

http://www.fmepedia.com

[I11] Bentley, MicroStation, 2004 Edition Brochure– 2005-10-21

http://www.bentley.com/en-US/Products/MicroStation/

82

http://postgis.refractions.net/index.php

http://www.postgresql.org/

http://www.oracle.com/

http://www.esri.se/

http://www.safe.com/

http://www.oracle.com/technology/tech/windows/odpnet/ODP.NET-FOV.html

http://www.bentley.com/

http://pgfoundry.org/projects/npgsql

http://www.esri.com/software/arcgis/arcgisengine/about/overview.html

http://www.fmepedia.com/

http://www.bentley.com/en-US/Products/MicroStation/

References

[I12] Bentley Releases MicroStation V8, David Cohn, Brad Holtz, Dr. Joel Orr, November 01, 2001

http://www.aecnews.com/articles/676.aspx

[I13] Oracle Spatial best practices

http://www.oracle.com/technology/products/spatial/pdf/spatial_best_practices.pdf

[I14] FME Objects .Net

http://www.fme.ca/products/fme/under-the-hood.php

[I15] FME seed file

http://fmepedia.com/index.php/DGN_Format_-_Basic_FAQ

[I16] Comparison Oracle and PostGIS

http://charlotte.utdallas.edu/mgis/ClassFiles/gisc6383/TechAssess_2005/Spatial%20Database%20Presentation.ppt#6

[I17] LOB

http://www.lc.leidenuniv.nl/awcourse/oracle/appdev.920/a96591/adl01int.htm#117849

[I18] Datasetoperations

http://www.dotnetspider.com/tutorials/DataSetOperations.aspx

[I19] IGDS overview

http://www.safe.com/support/online-documentation/ReadersWriters/igds_-_overview.htm

[I20] Oracle Georaster

http://www.oracle.com/technology/products/spatial/pdf/10g_georaster_twp.pdf

[I21] ODP .NET

http://www.oracle.com/technology/tech/windows/odpnet/index.html

[I22] Open design Alliance

http://www.opendesign.com/

[I23] New MicroStation XM http://www.geoinformatics.nl/media/pdf/P42-47-van-Prod_GI_04_2005.pdf

83

http://www.aecnews.com/articles/676.aspx

http://www.oracle.com/technology/products/spatial/pdf/spatial_best_practices.pdf

http://www.fme.ca/products/fme/under-the-hood.php

http://fmepedia.com/index.php/DGN_Format_-_Basic_FAQ

http://charlotte.utdallas.edu/mgis/ClassFiles/gisc6383/TechAssess_2005/Spatial Database Presentation.ppt#6

http://charlotte.utdallas.edu/mgis/ClassFiles/gisc6383/TechAssess_2005/Spatial Database Presentation.ppt#6



http://www.dotnetspider.com/tutorials/DataSetOperations.aspx



http://www.oracle.com/technology/products/spatial/pdf/10g_georaster_twp.pdf

http://www.oracle.com/technology/tech/windows/odpnet/index.html

http://www.opendesign.com/

http://www.geoinformatics.nl/media/pdf/P42-47-van-Prod_GI_04_2005.pdf

References

Additional Sources

[A1] Håkan Thomasson, E-on Norrköping. [email protected]

[A2] Claes-Göran Boström, Tietoenator AB. [email protected]

[A3] Mehdi Ghassemino. Casptune. [email protected]

[A4] Open design alliance, Associate Membership Agreement. October 2005.

[A5] Pricelist, FME Products from Safe software. January 2004.

84




TRITA-CSC-E 2006:147 ISRN-KTH/CSC/E--06/147--SE

ISSN-1653-5715

www.kth.se

Evaluation of .NET API:s for Reading and Writing MicroStation V8

Documents

Transcript of Evaluation of .NET API:s for Reading and Writing MicroStation V8