by Peter Batty Senior Applications Consultant Smallworld Systems
Abstract
"Object" would appear, to most people, to be a fairly innocuous, uninteresting word. Strange, then, that the objective of many GIS vendors these days appears to be to mention the word object as frequently as possible, objectivity being no object in labelling a system as object-oriented, to the extent that the word object is in danger of becoming an object of ridicule in the industry. Many people object to this rather objectionable state of affairs, where the word object is used as frequently and in as many different contexts as in this abstract, so the object of this paper is to try to introduce some objectivity into the use of the word object in relation to GIS.
The paper explains the difference between object-based systems, object-oriented interfaces, object-oriented programming and object-oriented databases. It concentrates in particular on explaining object-oriented programming, using real examples from a GIS application which the author has just implemented in an object-oriented environment.
The paper also asks the question, "So what?" Even if the user can work out in what respects a particular system is object-oriented, need they be concerned about the answer?
Peter Batty is a Senior Applications Consultant with Smallworld Systems of Cambridge, England. He has seven years of experience in the GIS industry- Most of this time was spent working for IBM in both the UK and the USA, and he moved to Smallworld Systems in 1992. His experience includes a wide range of GIS development and implementation projects in many different industries and countries. He has written and presented many articles and papers on technical issues in GIS. He has a BA in Mathematics and an MSc in Computing from Oxford University.
Outline
The term object-orientation has become so widely used in GIS that describing a system as object-oriented has become fairly meaningless. Rather than try to produce a single definition of what constitutes an object-oriented system, this paper attempts to outline the various ways in which the terms object and object-oriented are used in GIS, and produces a summary checklist which can be used to clarify exactly what a vendor means when they describe their system as object-oriented.
Topics which will be covered include the following:
- Object-based (as opposed to sheet-based or tile-based) systems
- Object-centred (as opposed to geometry-centred) systems
- Object-oriented user interfaces
- Object-oriented programming
- Object-oriented databases
The first two topics are largely a question of defining terminology and are fairly straightforward to understand. The third topic is rather vague, and is only briefly discussed. The fourth area of object-oriented programming is somewhat more complex to understand and it is this area that this paper will primarily focus on. The final topic of object-oriented databases is not well defined, and various definitions are discussed. Most of the (sensible) definitions of an object-oriented database relate back to object-oriented programming, which emphasises the importance of understanding this area in order to make sense of all the other definitions of object-orientation which one may meet.
The following sections explain each of the above terms, and in each case discuss the relevance of the topic to GIS.
Object-based Rather Than Map-based or Tile-based Systems
Perhaps the lowest level of functionality which is sometimes described as object-oriented in the context of GIS is what this author would describe as an object-based or feature-based approach to storing geographic data. Many GIS, especially those derived from CAD systems, split the database into map sheets, tiles, or geographic partitions. In such systems, any feature which crosses a map or tile boundary needs to be physically stored as multiple geometric objects, although the system will usually contain some functionality to make this split largely invisible to the end user.
In contrast, an object-based system does not partition the database into tiles, and stores geographic objects or features as a fundamental unit in the database. In such a system, linear or area objects never need to be artificially split because they cross a tile boundary.
Although, as mentioned above, systems which use a tile-based approach can make this reasonably transparent to the end user, extra code is required to do this, and typically application development is more complex because of the need to handle special cases where objects are split. There are also potential data integrity problems in trying to ensure that all parts of the object are correctly maintained. It is therefore generally agreed that an object-based approach is preferable to a tile-based approach. The main reason for using a tile-based approach is that this makes it simpler to achieve reasonable performance. However, modern spatial indexing techniques make it possible to get very good performance with a seamless object-based approach.
An object-based system as described in this section has nothing to do with the term object-orientation as it is used in the rest of the computer industry. However, in the experience of this author, many of the GIS which are described as object-oriented by their vendors fall into this category.
Object-centred Systems (as Opposed to Geometry-centred Systems)
Another sense in which the word object is used in relation to GIS data modelling is the term "object-centred" used by Newell (1). He contrasts what he terms object-centred and geometry-centred data models for use in GIS.
A geometry-centred model is one in which the primary classification of objects is a geometric one - for example each object is either a point, line or area. Each of these geometric types are then subdivided into classes which represent objects in the real world, for example a line might represent a road, a river or a gas pipe, and have appropriate attributes associated with it in each case.
In contrast, in an object-centred model, the primary classification of objects is based on the real world - so an object might be a road or a school. This object has multiple attributes, which may be either alphanumeric or geometric. Hence an object could have multiple different geometries of different types with this model. For example, a road might have a line geometry representing its centreline, which could be used for route tracing applications, and an area geometry representing its extent, which might be used in cadastral applications. This approach also facilitates generalisation, by allowing multiple geometric representations of an object which can be used at different scales.
In general, an object-centred data model provides a number of advantages over a geometry-centred model. However, as with the previous case, this use of the word object has nothing to do with object-orientation. At the risk of confusing the issue, it is possible to have an object-oriented system which is either geometry-centred or object-centred as defined in this section (real-world-object-centred might be a more accurate, if rather long, description for the latter data modelling approach). These two approaches are just different ways of classifying the objects within the system.
Object-oriented User Interfaces The term object-oriented interface is a somewhat nebulous one. Some people use it to describe any graphical user interface which makes use of windows, icons, etc., such as Microsoft Windows or X-windows. However, almost all GIS use a standard windowing system, so this is hardly a distinguishing factor in comparing different systems.
Some people use the term object-oriented interface in more specific ways, for example to describe the sort of interface used by systems such as the Macintosh, where the general approach is to select an object first and then choose an action to be carried out upon it, rather than choosing an action first and then an object. However, there is no general agreement on a precise definition of an object-oriented interface.
It is also true to say that, while user interfaces are obviously important in GIS, they are not really a major consideration in terms of the use of object-orientation in GIS, so we will not consider them any further here.
Object-oriented Programming
As stated earlier, understanding object-oriented programming is really the key to understanding definitions of object-orientation in relation to other areas such as databases, so it is this area that this paper will focus on.
One of the main challenges in explaining object-oriented programming is to find examples which are detailed enough to show how it can give significant benefits in practice, without being too long and difficult to understand. This section attempts to provide some such examples, based on real GIS applications.
The language used in the following examples is Smallworld Magik. This paper will just explain the minimum amount about the language syntax which is necessary to understand the examples, since the aim is to explain the important concepts of object-oriented programming in general, rather than any specific language. For a more detailed introduction to the Magik language, see (2).
First we will introduce the basic ideas of object-oriented programming: objects, classes, messages and methods. We will then look in turn at the concepts of encapsulation, polymorphism and inheritance, which are defined by most authors to be the key things which characterise an object oriented programming language.
Objects, Classes, Methods and Messages
Somewhat predictably, the idea of an object is central to object-oriented programming. An object is an item of data, very much like a variable (or constant) in a conventional programming language. Every object belongs to an object class, which is analogous to a data type in a conventional language. So for example, the number 1 is an object belonging to the class integer, and the letter x is an object belonging to the class character. These basic classes are defined as part of the system, as are slightly more complicated classes analogous to other data types in conventional languages, such as arrays.
However, one of the most important things about object classes is that new classes can be defined by the programmer, based on existing classes. For example, we could define a coordinate class, specifying that each coordinate has an x component and a y component, each of which are floating point numbers. This is similar to defining a structure in a conventional programming language such as C. We can access the components of an object as shown in the following example, which creates a new coordinate object with x coordinate of 100 and a y coordinate of 200, and then prints out the x and y coordinates separately:
c << coordinate.new(100, 200) write("x = ", c.x) write("y = ", c.y) This would produce the output:
x = 100 y = 200
The first line creates a new coordinate object and stores this in a variable called c (<< is the Magik assignment operator, like = in C or := in Pascal). In the second line, the expression c.x sends the message x to the object c, and this returns the value 100 (we will look further at messages in a moment). Components of an object, like x and y in this example, are known as slots in Magik or instance variables in Smalltalk.
As an aside, in Magik a slot does not have a fixed type - we could store a character string like "Hello" in the x component of a coordinate if we wanted to (although this might not be a good idea in this case, we will look at examples later where this capability is very useful). In some other languages like C++, the type (or class) or a slot has to be declared in advance and cannot be changed (this is known as strong typing).
Now we will look at messages and methods. So far everything we have discussed relating to objects has an equivalent in conventional languages, like C, which support the definition of composite data types or structures. However, a key difference in an object-oriented programming language is that an object class not only defines the data stored in objects of that class (as we have just briefly discussed), but it also defines all the functions which can operate on objects of that class. These functions are known as methods in an object-oriented system. Data in an object can only be accessed via methods defined on its object class. The significance of this will be discussed in the next section on encapsulation. A method is invoked on an object by sending a message to that object, which causes a method of the same name to be invoked. The distinction between messages and methods can be confusing at first, but the same message could be sent to objects of different classes and result in different methods being executed, because the method was defined differently on each class. This will be discussed further in the section on polymorphism.
To finish this section, we will look at a few examples of invoking methods on objects by sending messages to them. The Magik syntax for sending a message to an object is of the form
object name.message_name
Many methods will return a value (more accurately, they return an object). For example, suppose we had an object called a_road. The following example shows several Magik expressions in the left hand column and the object which is returned on the right:
"High Street" a_road.name (a character string object) A chain object (a a_road.centre_line chain is a basic geometric object in the Smallworld GIS) a road.centre_line.length 255.0 (the length of the road centre-line in metres - this example shows how we can send another message to an object which is returned from another method . . . expressions like this are evaluated from left to right).
As well as simply returning objects, as shown so far, methods can change data or cause other actions. For example, the message draw() will invoke a method which draws an object on all current windows in the GIS:
a_road.draw()
Parameters can be passed to a method - for example, the method draw_on() will draw an object on a specified window:
a_road.draw_on(a_window)
Some methods create or change objects. In our first example we saw the method new(), which creates a new object:
c << coordinate.new(100, 200)
There is a special message syntax for assigning data to slots, as in the following example:
c.y << 300
This sets the y component of the coordinate c to 300.
Encapsulation
We mentioned in passing in the previous section that the only way that data within an object (i.e. data in a slot) can be accessed or changed is via methods defined on that object's class. This is known as encapsulation, and we will consider its significance in this section. The most important thing about encapsulation is that it provides a well-defined and strictly enforced external interface to an object. This makes it possible to change the internal implementation of an object without affecting any of the other code which uses the object. This is a great advantage when building large and complex systems. We will look at some examples of how encapsulation could be used.
First consider the coordinate example we have already looked at. Our coordinate object class has two slots, and we have methods x and y which allow us to access these slots, and methods x<< and y << which allow us to directly assign values to those slots. For some operations it may be more convenient to work with coordinates expressed in terms of a polar coordinate system, as a radius and angle. We could define two new methods on the coordinate object class, called radius and angle, as follows:
method coordinate.radius return sqrt(x*x + y*y) endmethod method coordinate.angle return atan2(y, x) endmethod
Now executing the following . . .
c << coordinate.new(3, 4) write("x = ", c.x, " y = ", c.y, " radius = ", c.radius, "angle = ", c.angle) Would produce this output . . .
x = 3 y = 4 radius = 5 angle = 0.9273
Notice that there is no visible difference between the methods which directly access data in the slots (x and y) and the methods which access derived data (radius and angle). At the moment we have no way of setting the radius or angle directly though, as we have not defined methods to do this. However, we could do this as follows:
method coordinate.radius << new radius current_angle << self.angle # self.angle tells this # object to send the # message angle to itself x << x * new radius * cos(current_angle) y << y * new_radius * sin(current angle) endmethod method coordinate.angle << new angle current_radius << self.radius x << x * current radius * cos(new angle) y << y * current radius * sin(new_angle) endmethod
We can now change and access radius and angle just as though they were slots. If we now discovered that our application was using the polar form of the coordinates much more than the cartesian form, we could redefine our coordinate object to have slots called radius and angle instead of x and y, for efficiency, and define appropriate methods x, y, x<< and y<< so that all the methods which were previously defined were still available. Any existing programs using coordinates would run without any change, even though the underlying implementation of coordinate has completely changed. Note that slot access and update methods need not exist for all slots in an object, so slots can be hidden from the external programming interface for an object.
Encapsulation is a technique which can actually be used in non-object-oriented language, but it is usually not enforced by the language itself. For example, one could define a coordinate data structure in a language like C, and define functions called set_x, set y, get x and get_y, which were analogous to the slot access methods we have described. However, we are entirely reliant on the discipline of the programmers who use this data structure whenever they access or update a coordinate, they must use the specially provided access functions for doing so, rather than accessing the underlying data structure directly. An object-oriented system strictly enforces this principle of encapsulation.
Polymorphism
Polymorphism is the ability for the same variable to refer at different times to different classes of object. We have found this particularly useful in GIS applications, where there is often a requirement to handle heterogeneous groups of objects. We can send a message to an object without knowing its class, and the appropriate method for that class will be invoked on the object.
We will consider as an example a function to carry out Quality Assurance (QA) on electrical network data which has just been captured. We have a set of rules such as the following, for each object class which is relevant:
- All low voltage (LV) joints must have at least 1, and no more than 4, cables connected to them.
- All pole mounted transformers must have at least 1, and no more than 2, lines or cables connected to each of the low voltage and high voltage connections.
If we find an object which does not satisfy all the specified rules, we want to tell the user, highlight the object, and change the currently displayed area so that the object is in the centre of the screen. The way in which we will implement this function is to define a method called valid? on each relevant object class, which returns true or false depending on whether the object satisfies all the rules or not.
At capture time we run interactive checks to ensure that the only object which can be connected to an LV joint is an LV cable, so all we need to check at this stage is the number of objects which are connected to the LV joint. In this particular data model, an LV joint has a single point geometry called location. Thus our validation method can be written as follows:
method lv_joint.valid? num cables << self.location.all connected_geometry.size if num_cables < 1 or num_cables > 4 then return false else return true endif endmethod
In the first line, self.location returns the point geometry associated with this Iv_joint object. We then send this point object the method all_connected_geometry, which returns a set containing all the geometries which are connected to that object. In this case we do not wish to look at the individual items in this set, we just want to know the size of the set, so we just send the set the message size. All these methods are already defined in the standard class libraries (i.e. class definitions and methods) which are provided with the system. This last object which is returned (the size of the set, i.e. the number of cables connected to this joint) is assigned to the variable num_cables. We then do a simple test on the value of num cables to check whether this is valid or not, and return true or false accordingly.
We can define a similar method for pole mounted transformers as follows. This is slightly more complicated since this object has two point geometries, called Iv_connection and lv connection. These represent the distinct connection points for low voltage and high voltage cables or lines belonging to this transformer. Again we validate interactively that only LV cables and LV lines can be connected to the Iv_connection, and that only HV cables and HV lines can be connected to the hv connection, so we just need to check the number of objects connected to each of these geometries.
method pm_transformer.valid? num_lv_conns << self.lv_connection.all_connected._geometry.size num_hv_conns << self.hv_connection.all_connected_geometry.size if min(num lv_conns, num_hv_conns) < 1 or max(num_lv_conns, num_hv_conns) > 2 then return false else return true endif endmethod
This method is very similar in principle to the last one, except that in this case we have to check the connections to each of the two geometries belonging to the object.
We can now define our QA validation function as follows:
method qa_menu.validate objects() for an_object over grs.objects_inside_area(current_qa_area) loop if not an_object.valid? then grs.current object << an_object an_object.goto() grs.show_message("Invalid object found") return endif endloop grs.show_message("QA completed successfully") endmethod This is the complete code for this application. We define the validation function as a method on an object called qa_menu, which is a menu we have created from which the user will initiate the QA function by pressing a button. The qa_menu object has a couple of slots which are referred to in this method. The first is called grs, which is the graphics system we are currently running - this is quite a complex object which is essentially the whole GIS application, which has slots referring to the current database, all the menus displayed, the currently selected object, etc. There is also a slot which stores the QA area we are currently working within. We just want to check objects inside this area, so we send the message objects_inside_area() to the graphics system. This is a special type of method called an iterator method - it returns objects one at a time to the loop which follows. Inside the loop, we send the message valid? to each object which is found inside the area. This is where polymorphism is important - even though we don't know the type of object which has been returned (we could find out, but we don't need to), we can send it the same message, valid?, and the appropriate method called valid? gets invoked depending on the class of the object. This example should clarify the difference between a message and a method. We have defined two distinct methods called valid?, one on the class lv_joint and one on the class pm_transfomer. However, we can send exactly the same message called valid? to an object of either class and the appropriate method will be invoked.
If the object fails the validation test then we make it the current object in the graphics system, which causes its geometry to be highlighted and its object class and attributes to be displayed. We then send the object the message goto(), which causes this object to be displayed in the current graphics view, and finally we display an alert message to the user and exit from the loop (and the method) with a return statement.
The great beauty of this approach is that we can add a new object class to our application, define a method called valid? for it, and the validation code will work immediately without requiring any changes. You don't even need to compile or link anything. In contrast, with a conventional procedural language it would be very hard to write an equivalent QA function which could be extended to accommodate new object classes and rules without having to modify the source code of the validation routine itself. Allowing customers to directly modify product source code is highly undesirable for a software vendor (and indeed for the customer, as it makes support and problem resolution much more difficult), so it is much easier to produce systems which can be easily and cleanly extended in an object-oriented environment like the one we are discussing.
As another aside, one important point which has been touched on in passing is that the Magik programming environment is interactive. One can be running the GIS, modify a validation method like those above while the system is running, and immediately test the effects of the change without having to compile or link anything. The same is true of Smalltalk, but not of C++, which requires you to compile, link, and re-run your application before you can test the change. Having an interactive programming environment makes a huge difference to development productivity.
Inheritance
The third main area which characterises object-oriented programming is inheritance. Inheritance allows new object classes to be defined in terms of existing object classes, inheriting both data structure (i.e. definition of slots) and behaviour (definition of methods) from the defining parent class or superclass. A class which inherits from another class is said to be a subclass of its parent. It is possible to define additional slots and additional methods on a subclass. It is also possible to define a method in a subclass with the same name as a method in its parent class, and this new method will override the method from the parent class. We will look at examples of all these things shortly. In overview though, the inheritance mechanism provides a very powerful way of writing generic code which can be shared by many classes, whilst at the same time allowing any differences from this generic behaviour to be easily defined in subclasses. This results in much smaller amounts of code overall, which again greatly helps the reliability and maintainability of a system.
The value of inheritance is most apparent in quite complicated systems, so it is difficult to illustrate its full benefits in a short paper such as this. To illustrate the basic concept of inheritance though, we will return to our coordinate example. Suppose that for some applications we need to handle 3-D coordinates, and that for the most part these will be used in the same way as 2-D coordinates (displayed on 2-D maps etc), but that in some cases 3-D coordinates will have additional, or different, behaviour.
First we will define a few examples of behaviour on 2-D coordinates. We will assume that we have the access methods x and y which we used before.
We can define a method to measure the distance between two coordinates as follows:
method coordinate.distance_to(another_coordinate) dx << self.x - another_coordinate.x dy << self.y - another_coordinate.y return sqrt(dx*dx + dy*dy) endmethod
We could also define a method to check whether a coordinate was inside a bounding box (this is a horizontal rectangular area, often used for initial area comparisons in a GIS, which is defined by the its bottom left comer (xmin, ymin) and its top left corner (xmax, ymax)).
method coordinate.inside?(a_bounding box) bb << a bounding box if self.x >= bb.xmin and self.x <=bb.xmax and self.y >= bb.ymin and self.y <= bb.ymax then return true else return false endif endmethod
There would obviously be a lot more methods defined on a coordinate in practice, but these will suffice for this example. A simple example of creating and using some coordinates and related objects is as follows:
# Create a coordinate c1 << coordinate.new(5, 5) # Create another coordinate c2 << coordinate.new(5, 15) # Create a bounding box bb << bounding box.new(0, 0, l0, 10) # Check if c1 is inside the box write(cl .inside?(bb)) # Check if c2 is inside the box write(c2.inside?(bb)) # Calculate the distance from c1 to c2 write(cl .distance_to(c2))
This would produce the following output:
True False 10
We can now define a subclass of coordinate called 3d_coordinate which inherits from coordinate and has an additional slot called z. This will immediately inherit all the methods we have defined on coordinate, so the operations we have defined above will still work in the same way, accessing the x and y coordinate of the 3d_coordinate and ignoring the z coordinate. We could define a new method to calculate the 3d distance between two 3d coordinates as follows:
method 3d_coordinate.3d_distance_to(another_3d_coordinate) dx << self.x - another 3d_coordinate.x dy << self.y - another 3d_coordinate.y dy << self.z - another_3d_coordinate.z return sqrt(dx*dx + dy*dy + dz*dz) endmethod
In this way we can easily extend the behaviour of existing classes. We can also modify the behaviour of a subclass relative to its parent by overriding methods. We will look at a different example to illustrate this. As mentioned earlier, Magik allows multiple inheritance, i.e. inheritance from more than one parent class. It is possible to define special classes called mixins, which do not have any slots but are just used to define behaviour (methods) which can be inherited by other classes.
The example we will consider is a data conversion application. We will look at defining methods which specify how objects are interactively created. Within Smallworld GIS, there is standard functionality provided to allow the user to create and manipulate an object called a trail, which is just a general piece of geometry. The trail is a multi-point line, and functions are provided to add points to the trail, move and delete them, generate points by raster line following, etc. The geometry in the trail is used to define the geometry of objects which are added to the system, such as cables or poles. Point objects can be defined either with a single point trail, for an object with fixed orientation, or with a two point trail for an object with variable orientation, where the first point defines the centre of the object and the direction from the first to the second point defines the orientation of the object. This is illustrated in the following diagram:
[Fig not available at this time]
There are various types of behaviour common to point objects in this data capture application, so we define a class called point_object, on which we will define behaviour common to point objects which can be inherited by application objects such as joints, poles and transformers.
We will define a general method for creating the main geometry of a point object from a trail which will cover both of the cases above. It turns out to be useful to allow a point object to be added at the end of a long trail in certain situations, for example when digitising linear objects such as cables. We will therefore specify that point objects without orientation will be added at the location of the last point in the trail with an orientation of zero, whilst point objects with orientation will be added at the last but one point in the trail, and the orientation of the last trail segment will define the orientation of the object. This is illustrated in the following diagram:
[Figure not available at this time]
In this application, when the user presses the insert button, a new object of the current type is created with no geometry, and then this object is sent the message create_geometry_from_trail(), so that the appropriate default geometry will be created from the current trail. Since we have two different sets of behaviour, point objects with and without orientation, we can define two new classes called point_object_with_orientation and point_object_without_orientation on which we can define the appropriate behaviour to create geometry from the trail. Both of these classes inherit from point_object, so that any behaviour which applies to any point object (with or without orientation), can be defined on the point object class, and it will automatically be inherited by these two subclasses.
We now define our methods as follows:
method point_object_without_orientation. create_geometry_from_trail(grs) new_point << point.new_at(grs.trail.coords.last) self.default_geometry << new_point endmethod method point_object_with_orientation. create_geometry_from_trail(grs) trail << grs.trail if trail.size > 1 then new_point << point.new_at(trail.coords[trail.size - 1]) new_point.orientation << trail.segment_angle else new_point << point.new_at(trail.coords.last) endif self.default_geometry << new_point endmethod
The first method creates a new point at the last coordinate in the trail. This is done by sending the graphics system object, grs, the message trail which returns a trail object. This in turn is sent the message coords, which returns a vector (array) of coordinates, and this is sent the message last, which returns the last element of any ordered collection. So we now have a coordinate, and we create a new point at this coordinate (a point has more information than a coordinate, such as an orientation, and information on other geometries which are connected to that point). No orientation is specified for the point here, since the default orientation is zero, which is what we want in this case. We then assign the default geometry of the new object to the point we have created. This assignment causes user-definable rules to be invoked to connect this geometry to other specified geometries within a given tolerance, as appropriate.
The second method is similar, but in this case we define the location of the point to be at the last but one point of the trail, provided that the trail has more than one point. To do this we use the indexing method [n1 which accesses the nth element of any ordered collection. We also assign an orientation to the point, which we obtain by sending the trail the standard message segment angle, which returns the angle of the last segment in the trail. If there is only one point in the trail, we create the new point in the same way as for a point object without orientation.
When we define application point objects like joints, poles and transformers, each of them will inherit either from point object_with_orientation or point object_without_orientation. We could also define a new create_geometry_from_trail() method on any of these specific objects if we wished its behaviour to be different in terms of how its geometry was created from the trail. For example, we might wish to regard a substation as a point object with orientation, since like the other point objects we have considered it is a valid end point for a cable, so it shares behaviour in this respect. However, we wish to represent the primary geometry of a substation as a rectangular area geometry, of a size which depends on the voltage level of the substation.
We would like to define the location of the substation by placing a point at its bottom left corner and making a second pointing to indicate its angle. This could be done with the following method:
method substation.create_geometry_from_trail(grs) trail << grs.trail # Define the bottom left corner and the angle # from the trail if trail.size > 1 then base_coord << trail.coords[trail.size-1] orientation << trail.segment_angle else base_coord << trail.coords.last orientation << 0 endif # Set the substation size (in mm) depending # on the voltage if self.voltage = "LV" then xsize << 5000 ysize << 3000 else xsize << 12000 y size << 8000 endif # Now create the relevant area geometry new_area << area.new_rectangle(base_coord, xsize, ysize, orientation) self.default_geometry << new_area endmethod
So now our substation object has all the behaviour of a point object with orientation, except for the way in which its geometry is created from the trail. It can be seen that in this way inheritance gives us a very powerful technique for sharing code between object classes - we only need to write additional code for a new object class where its behaviour differs from its parent class. This example also illustrates the flexibility of a "real world object centred" data model rather than a "geometry centred" data model: we can define a range of objects to be regarded as "point objects" for the purposes of this application, even though they have different geometry types.
Object-oriented Databases
Whilst there is a reasonable degree of agreement as to what constitutes object-oriented programming, as described in the previous section, there is less agreement as to what constitutes an object-oriented database. Some people, including some well known figures in the GIS industry, seem to use the term for any database which can store "blobs" (binary large objects, such as images), in addition to traditional data types such as numbers and character strings.
An alternative definition is that it is a system which provides a persistent store for objects in an object-oriented programming environment, so that objects continue to exist when a program finishes running. To be regarded as a proper database management system (DBMS), such a system should also support multi-user access to the data, and handle the associated issues of concurrent update, and also provide other standard database functions such as security, backup and recovery. The interface to objects in such an object-oriented database, from a programming point of view, is usually exactly the same as the interface to non-persistent objects.
The advantages of an object-oriented DBMS are essentially an extension of those for object-oriented programming: with such a DBMS it is possible to use all the same data modelling techniques on objects which need to be stored in the database.
However, whilst there is general agreement in the computer industry that object-oriented programming is a good thing, database experts seem to be divided over the virtues of object-oriented databases. There is a well-developed theory behind relational databases, a lot of experience has been gained with them, and there are established standards such as SQL. No such formal theory has been developed for object-oriented databases. There are still some unresolved issues with object-oriented databases, such as providing a general query language and optimising queries. There is therefore a school of thought which says that rather than regarding object-oriented databases as something completely independent of current database technology, relational database systems should be extended to accommodate object-oriented ideas, and to allow them to be used within an object-oriented programming environment.
Smallworld has taken an approach which uses a version managed relational database management system, with an object-oriented programming interface added to it. Accessing objects in the database is very similar to accessing non-database objects, but with a couple of restrictions. The first restriction is that slots in database objects have to have a fixed type (class) which is declared in advance, as with any relational database. This is in contrast to non-database objects in Magik, whose slots can be used to store any object of any class. The second restriction is that in the current version of the system, behavioural inheritance (inheritance of methods) is supported on database objects, but structural inheritance (inheritance of slots) is not. However, exploratory work has been done on structural inheritance and it is planned to support this in a future release of the product.
A database table is regarded as a collection in Magik. A collection is a general class which stores a group of objects. There are many standard subclasses of collection which are provided with the system, such as sets, arrays, ordered collections, etc. Database tables form a class called ds_collection (datastore collection). There are various standard methods which apply to all collections, for example size, which returns the number of elements in a collection, and elements(), which is an iterator method which returns all the elements of the collection in turn.
The following example gives a brief flavour of how database objects can be accessed. Suppose that we have a cost attribute in pipes, which we wish to set in all pipes based on other attributes in the pipe (in reality we would probably set this interactively, triggered by any change in the pipe, but this sort of batch update is a reasonable illustration of access to the database).
for p over pipe_table.elements() loop material_cost << material_table.at(p.material).unit_cost p.cost << p.length * material_cost endloop
In this example we loop over each of the objects (records) in the pipe table. For each one we obtain the material cost by looking in another table. The method at() returns the database object at a specific primary key value in a table, which is a very efficient means of accessing a record. We can also access records using generic SQL-like predicates. The record object returned has slots like any other object, so we access the unit_cost slot of the material record returned. We then assign the cost attribute of the current pipe database record to the pipe length multiplied by the material cost. Since this is a database object, this value is automatically stored in the database.
Summary
We have discussed a number of uses of the term object-oriented in relation to GIS. The following is a summary set of questions which you should ask of anyone who calls their system object-oriented in order to clarify what they mean:
- Does it store objects as a fundamental unit in the database, with no need to split objects across tile boundaries or partitions? This is what we called an object-based system: we would not call such a system object-oriented.
- Does it have a "real world object centred" data model rather than a "geometry centred" model, as described above? The answer to this question has no bearing on whether or not a system is object-oriented.
- Does it provide an object-oriented programming environment which supports the following:
- a) Encapsulation
- b) Polymorphism
- c) Inheritance
- Does it provide a set of standard class libraries which can be extended by the customer?
- Does it provide a database system which supports each of the previous concepts?
We will not be pedantic about trying to specify a precise set of answers to these questions which mean that a system is object-oriented or not, since this seems a rather pointless exercise.
Conclusion: So What?
Even if you can obtain answers to these questions, what does all this mean? To an end user of the system, it really makes little direct difference. When sitting in front of a system, you cannot tell whether or not it is object-oriented. The primary benefits of object-orientation are in ease of customisation and maintenance of the system, so the person who really sees the benefits of object-orientation is the application developer. In turn, this of course benefits the end user, who can expect to see applications delivered, and bugs fixed, much more quickly in an object-oriented system. It is Smallworld's experience after several years' work developing a GIS using an object-oriented programming environment that this approach is significantly more productive than traditional approaches to development.
References
1. Richard G. Newell. Practical experiences of using object-orientation to implement a GIS, Proceedings of GIS/LIS 92.
2. Arthur Chance, Richard G. Newell and David G. Theriault. An Overview of Smallworld Magik, Smallworld Technical Paper no. 9.
Posts
No comments:
Post a Comment