modeling and querying mobile objects in location-based services

MODELING AND QUERYING MOBILE OBJECTS IN LOCATION-BASED SERVICES Dragan Stojanović, Slobodanka Djordjević-Kajan Faculty of Electronic Engineering, University of Nis Beogradska 14, 18000 Nis, Serbia and Montenegro E-mail: {dragans, sdjordjevic}@elfak.ni.ac.yu

Abstract. A location-based service delivers geo-related information and geo-processing services to a mobile/stationary user in accordance with their current location and preferences, or the location of stationary/mobile objects of their interest. Such services, like automatic vehicle location, fleet management, tourist services, transport management, traffic control and digital battlefield, are all based on mobile objects and management of their continuously changing locations. Thus modeling and the representation of mobile objects are fundamentally important in these applications. The goal of the work presented in this paper is to provide a mobile object data model for representing and querying mobile objects, with particular emphasis on those with point geometry, moving on a transport infrastructure that are pervasive in the location-based services. The mobile object data model extends widely accepted OGC Simple Feature model, also adopted by ISO TC 211. The implementation of the mobile object data model represents the foundation of the mSTOMM component framework, intended for development of the location-based services that deal with tracking and management of mobile objects. As such, it is suitable for integration in any OGC compliant GIS platform or a DBMS, enabling them in the mobile object domain.

1. Introduction The advances in the wireless communication technologies and the mobile, Internet-enabled devices, like the smart phones and PDAs, have enabled global Internet connectivity and ubiquitous Web-based computing and service distribution. The recent convergence of Internet, wireless communications, mobile positioning and the geographic information systems (GIS) has given rise to a new class of location-based applications and services. Location-based services (LBS) deliver geographic information and geo-processing power to the mobile users in accordance with their current location and preferences, or to the stationary users in accordance with the location of the mobile/stationary objects of their interest. Location-based services are specialized, multi-tiered, component Web GIS applications, which can be published, located and invoked across the wireless/wired Web ([18]). Such services are useful in traffic control, road navigation, vehicle and person tracking, fleet management, tourist guiding and military exercises. During its motion, the user of LBS

1

can express interest and issue queries related to the stationary objects (hotels, restaurants, roads, etc.), as well as the mobile objects (cars, passengers, tracks, etc.). The user may also represent the mobile object of interest to other mobile users within the same or another location-based service. Mobile objects that are of relevance in location-based services have point geometry and move along the predefined path in the transport network. To provide useful services to the mobile/stationary users based on their and locations of the surrounded objects, the LBS applications require database and application support to model and manage mobile objects in both database and the application domain, and to specify and process spatio-temporal queries with space and/or time conditions in respect to the actual time, to the past and to the (near) future. The main goal of our research work is to provide such support. The paper is structured as follows. Section 2 presents the necessary support for the mobile objects in location-based services and specifies the fundamental model of the motion of the mobile point objects. Section 3 describes a standard-based, object-oriented mobile object data model, reviews its classes, attributes and operations, which represent a foundation for the mobile object query language and query processing. Section 4 sets the particular emphasis on the modeling mobile point objects that move either freely or over a predefined path in a network. Section 5 presents an implementation of the proposed mobile object data model in an object-relational database system with an existing OGC compliant spatial extension. Section 6 presents the overview of the related research work. Section 7 concludes the paper and identifies promising directions for the future research.

2. Mobile Point Objects in Location-Based Services A location-based service is a specialized, multi-tiered Internet GIS application delivered across the wired/wireless Web to the stationary/mobile users ([18]) (figure 1). The location of the mobile devices in people’s hands or built-in vehicles can be determined by using GPS, or mobile network triangulation. Their location is transmitted to the LBS server through the wireless communication interface, from the device itself, or from a mobile positioning center of the mobile network. At the LBS server, the data is processed and services, based on such data, are provided to users. Mobile users may be also represented as the mobile objects registered at the server and tracked by others. Considering the location-based service applications we focus on the mobile objects with point geometry, whose size and shape are of no importance. Different components of the multi-tiered LBS architecture may use different mobile object data models for representation and management. Thus within the LBS application components, an object-oriented data model is implemented, while within the database system, relational or object-relational data model is implemented. To enable data communication between different application components, possibly implemented as Web services and distributed over the Internet, mapping between the different data models must be applied. With the advent of XML-based technologies in data transfer and exchange, it is reasonable to couple different data models by using a uniform representation of the mobile point objects. For the XML-based representation of the geographic features, OGC proposed an XML-based specification called GML (Geography Markup

2

Language) ([10]). The GML definition must be extended for representing continuously changing properties of mobile objects. GSM GPS

LBS clients GML, SVG, WML

Wired/Wireless Internet Mobile object Web server (XSLT engine, XSL style-sheets)

GML Communication & Location Data Acquisition

LBS application server Mobile object management components & services (Real-time tracking, Mobile and Continuous Querying, Dynamic Visualization, Route Analysis, etc.)

GML

General GIS components and services (Querying, Mapping, Analysis)

GML

LBS Information Server Mobile Object Database (Mobile extension to OGC SF SQL)

Geographic Database (OGC SF SQL)

Figure 1. Mobile objects in location-based services According to T. Brinkhoff in ([1]) moving real-world point objects mostly move following a path in the network. Vehicles, trains, boats and passengers move following a particular network (roads, railways, rivers, pedestrian tracks). The air traffic also follows a 3-dimensional (3D) network of the air corridors. Even herds of animals often follow a (invisible) network path during their motion. In addition to this, mobile objects almost always know where they go, i.e. know their destinations. Also such mobile objects often use fast and/or shortest paths to their destinations depending on the cost criteria (time and/or distance). The application scenario for LBS that involves mobile objects both as the users of the service and as the tracked objects is as follows ([20]). The mobile object registers for a certain location-based service connecting to the LBS server by sending the starting location (the coordinates of the starting point or the address), the starting time, the ending location and eventually the set of points of interest that it is going to visit along its route and duration of the stay at each stop. The road network database accessed and managed by the LBS information server stores a network which is the layer supporting the object trajectories. Such road network database contains geometry for each road segment, the attributes used for geocoding, as well as the attributes needed for computing travel time and travel distance for a particular road segment, such as the average speed or the

3

typical drive time ([21], [23]). The road network database can be updated by using real-time traffic information about accidents, roadwork, traffic congestions, etc ([22]). Given the starting motion parameters, LBS server calculates the shortest cost (distance or travel-time) path in the road network. During its motion, at regular or irregular time intervals, the mobile object sends to the LBS server a location update, containing the location value and the time instant when it is at that location. Using the sequence of location updates, the LBS server forms the mobile object's trajectory. The trajectory of the mobile object is a polyline in three-dimensional space (two-dimensional space and time) defined by a sequence of points (xi, yi, ti) (figure 2). Such trajectory is only an approximation of the object's motion, because the object does not move in straight lines at constant speed. The number of points along the trajectory is proportional to the accuracy of such approximation. An additional parameter mti for every point defines the type of motion during a period [ti, ti+1]. The three motion types are defined: the punctual - the mobile object is not tracked and its location is not defined during a certain time period; the stepwise - the mobile object does not move during the time period; the linear - the mobile object moves along a straight line from (xi, yi) to (xi+1, yi+1), and at constant speed. When a mobile object moves along the curve segments with the variable speed, the fourth motion type, interpolated, must be defined to represent the motion by an interpolation function. These motion types correspond to the behavioral functions defined by Yeh and Cambray in ([25]). t P6

t6

y

P5

t5

P4

t4 t3 y4 t2 t1 y 1

y2

y5

P3

y6

P2

y3 P1

x5 x4 x1 x6 x2 x3

x

Figure 2. Mobile point in a 3D space (2Dspace, time) Based on the trajectory of the mobile object, at any point in time t between ti and ti+1, the LBS server can compute the expected location of the mobile object at time t by using the linear interpolation. If the underlying road network database contains attributes needed for computing travel time on road segments, they enable the LBS server to define the expected trajectory of the mobile object starting from the last location update to the object's destination. If such attributes are not available, in order to define the expected trajectory of the mobile object, the LBS server needs the object's (average) speed at every location update. Upon registering to the service, the LBS server sends to the mobile object an uncertainty threshold. The uncertainty threshold specifies the responsibility of the mobile object to send the location update to the LBS

4

server if its current location is deviated from its expected location on the expected trajectory by the defined uncertainty threshold. With every location update, the expected trajectory of the mobile object from that location to the destination must be updated by ∆t = ± ut / v, where ut is the uncertainty throeshold and v is the average speed for the current road segment. When the route of the mobile object is not known a priori, because of, for example, the unknown destination, at any location update, the mobile object must send to the LBS server an additional attribute, its direction. It enables the LBS server to associate the mobile object to the road segment of the underlying network, and define and store a new part of the object’s trajectory from the last to the new registered location, according to the shortest cost path between these two locations. Considering the modeling and the representation of the mobile point objects several research problems arise. The data model and its implementation representations must include the whole trajectory of the mobile point object in the past, present and the (near) future and enable the estimation of its location at any time during the motion. The implementation of the data model must be compliant to the contemporary standards of OGC and ISO TC 211, that are widely accepted by both the industry and research organizations and incorporated in a wide variety of commercial products, such as Oracle 9i Spatial ([12]).

3. Modeling Mobile Objects in the mSTOMM Framework The standard-based component framework, mSTOMM (mobile Spatio-Temporal Object Modeling and Management), represents a suite of the mobile object modeling and the management techniques, tools and components, developed with the aim to support the development of the location-based services that involve mobile objects ([18]). The mSTOMM data model was developed to support the conceptual modeling and querying of the discretely and continuously changeable properties of geographic features, i.e. mobile objects ([19]). The mSTOMM data model is extensible, object-oriented, and specified using the UML class diagram notation. We base our modeling approach on the comprehensive framework of the data types and the rich algebra of operators defined in ([4], [5], [7]). We extend their approach to the object-oriented modeling paradigm, with respect to the OGC and ISO TC 211 standards, and provide the representation of the complete motion of the mobile object from the past to the future. We define the set of the mobile object data types and operations that are sufficient for the modeling mobile object’s properties and expressing the queries based on them, in the real LBS implementations. Our main emphasis is put on the modeling the mobile point objects moving on the transportation network ([19]). Our goal is to develop the component framework, as a powerful and conceptually clean foundation for modeling and implementation of LBS applications that involve mobile objects on top of it. The mSTOMM data model appropriately extends the OGC Simple Features model, also accepted by ISO TC 211 ([8], [11]). The simple features are the geographic entities with the geometric properties represented by the collections of points represented by a pair of coordinates in 2D space, with a linear interpolation between the vertices. The standard defines abstract Geometry class, and its hierarchy of the specialized geometric classes (Point, LineString, Polygon, MultiPoint, etc.). The attributes and the operations, defined 5

within the geometry classes, support the specification of the topological relations, direction relations, metric operations and the operations that support spatial analysis (point-set operations) on appropriate geometry types. The time dimension of a mobile object is specified through the TimeObject class hierarchy, defined in accordance with ISO TC 211 Temporal Schema ([9]) (TimeInstant, TimePeriod, TimeDuration, MultiTimeInstant etc.). The TimeObject class includes the attributes and operations for specifying topological relations, metric operations and point set operations on time dimension. Object

TimeOb jec t

1 +object MobileObject Objec tAt(t : Ti meIn st ant ) : Objec t Objec tDu ring(t : TimeObject) : Mo bileOb.. . Whe n(c : Mo bileBo ole an) : TimeObjec t L if esp an() : Tim eSt am p Nu mOfSl ic es() : Intege r Moti onSl ic eNt h(ind : Int eger) : Mo ti onSlice

Mo bil eGeo me try

MobileNumber

{Object = Geometry} {Obj ect = Nu mb er}

1

TimeI nstant

+ ti me

0..n +mo ti ontype

1

MotionType

Punctual



MotionSlice

+motion

Stepwise

MobileBoolean

Linear

Int erpol ate d

MobileString

{Object = Boolean} {Ob jec t = String}

Figure 3. The MobileObject class hierarchy and associated classes The base class for introducing mobility of the feature properties in the mSTOMM data model is an abstract MobileObject class, as the root of the extensible hierarchy of classes for specifying mobile properties ([19]). Mobile attributes are represented as instances of classes, which inherit the MobileObject class and those are: MobileGeometry, MobileNumber, MobileBoolean and MobileString (figure 3). Userdefined mobile classes of objects can be also specified by inheritance from the MobileObject class, or any of its specialized classes. The MobileObject class defines general operations for the management and querying motion properties of the mobile objects, which are inherited and overridden in the specialized mobile classes. The ObjectAt operation retrieves an object’s value at specific time instant. In order to restrict the sequence of motion slices of the mobile object according to the specific time object, the ObjectDuring operation is defined. That operation restricts the mobile object to only those motion slices from the sequence that belong to the specified time object given as an argument. The Lifespan operation returns a time object defining the whole life span of the mobile object. The When operation returns the time object during which the mobile object satisfies the criteria specified by the mobile Boolean argument. The NumOfSlices and the MotionSliceNth operation enable navigation through the sequence of object’s motion slices. 6

The base class for modeling continuous change of geometric properties is an abstract MobileGeometry class, as the root of the extensible hierarchy of the classes for specifying mobile geometries (figure 4). The MobileGeometry class inherits both the MobileObject class and the OGC Geometry class. For every class in the Geometry class hierarchy an appropriate class for the representation of a particular mobile geometry is defined (MobilePoint, MobileLineString, MobilePolygon, MobileMultiPoint, etc.). Any of these classes appropriately restrict the Geometry class aggregated within the MotionSlice class ( stereotype). Mo bil eGeo me try equals(geo : Geometry) : Boolean touches(geo : Geometry) : Boolean contains(geo : Geometry) : Boolean ...() Equals(geo : Geometry) : MobileBoolean Touches(geo : Geometry) : MobileBoolean Contains(geo : Geometry) : MobileBoolean Within(geo : Geometry) : MobileBoolean Crosses(geo : Geometry) : MobileBoolean Disjoint(geo : Geometry) : MobileBoolean Overlaps(geo : Geometry) : MobileBoolean Intersects(geo : Geometry) : MobileBoolean North(geo : Geometry) : MobileBoolean East(geo : Geometry) : MobileBoolean Distance(geo : Geometry) : MobileNumber Intersection(geo : Geometry) : MobileGeometry ...() GeometryAt() : Geometry GeometryDuring(t : TimeObject) : MobileGeometry When(mb : MobileBoolean) : TimeObject LifeSpan() : TimeObject MotionSliceNth(ind : Integer) : MotionSlice NumOfSlices() : Integer Route() : Geometry

MobileObject

Geometry

Figure 4. The MobileGeometry class Being a specialization of the Geometry class, the MobileGeometry and its specialized classes can be treated in the same way as any other geometric object, i.e. it can represent the geometric property of any feature which is dynamic in nature and participate in all geometric operations and relations. An instance of the MotionSlice class, aggregated by the MobileGeometry class with multiplicity 0..n, represents the registered location of the mobile geometry, by containing a geometry value (the instance of the Geometry class), the valid time of such value (the instance of the TimeInstant class) and the motion type (the instance of the MotionType class), which describes the way geometry changes between two successively registered geometries. The mSTOMM data model provides four classes for modeling motion types, and those are: the Punctual, the Stepwise, the Linear and the Interpolated class. Those motion types are comprehensive and can be used for expressing both discrete and continuous changes of spatio-temporal objects. The first three motion types do not require any additional information to be included in the data model, but for the interpolated motion type, specific interpolation parameters must be specified. The MobileGeometry class specializes the ObjectAt and the ObjectDuring operations defined in the MobileObject class, in the form of 7

the GeometryAt and the GeometryDuring operations. Also the new operation applicable to mobile geometry classes, the Route operation, is defined, which returns Geometry result representing the path traversed by the mobile geometry. The motion of the mobile object also causes continuous change of its non-spatial properties like the distance from some static or a mobile object or topological relation between two mobile objects. The MobileNumber and MobileBoolean classes, which inherit Boolean and Number base classes respectively, model those properties by aggregation MotionSlice class with appropriate restriction. The mSTOMM data model overrides topological relations, direction relations, metric operations and the spatial analysis operations inherited from the base Geometry class ([8], [11]). These relations and operations take a mobile or a non-mobile geometry argument and generate non-mobile results (Boolean, Number, Geometry, etc.). The specialized topological and direction relations, like the touches and the contains, have a single argument of type Geometry (which could also be the MobileGeometry) and return Boolean true value indicating that such relations are satisfied during the lifespan of the MobileGeometry argument(s) according to the temporal aggregation defined in ([5]). Such operations correspond to spatio-temporal predicates. Metric and spatial analysis overridden operations can not be considered as the predicates, and for the MobileGeometry argument the operation is delegated by default to the geometry value at the current time instant defined using GeometryAt(Now) operation. The mSTOMM data model also defines mobile variants of the mentioned non-mobile relations and operations, named with the starting capital letter in figure 2. Such operations correspond to the temporally lifted operations that handle the non-mobile or the mobile geometry arguments and generate the mobile result, since for mobile argument(s) different results are generated in the course of time. The motion type associated with the mobile result depends on the operator or the relation. In general, it is not sufficient to inherit a motion type of a mobile argument. For example, for mobile points characterized by the linear motion type, a quadratic interpolation method is needed to represent the mobile result of the distance operation. Our concept for finding the corresponding mobile operations and relations are similar to the operator lifting described in ([7]). For example, four variants for the touches operator existed, which is applicable to two geometric object and returns corresponding result: touches: Geometry x Geometry -> Boolean touches: Geometry x MobileGeometry -> Boolean Touches: MobileGeometry x Geometry -> MobileBoolean Touches: MobileGeometry x MobileGeometry -> MobileBoolean

As explained, the first and the second variants correspond to the touches operation defined in the Geometry class and overridden in the MobileGeometry class, and the last two variants is defined as the Touches operation in the MobileGeometry class and its specialized mobile classes. For clarity reasons, the names of the mobile operations and relations start with the capital letter, to be distinguished from their nonmobile counterparts. To support the manipulation of mobile properties of type MobileBoolean and MobileNumber, predicates and operations (and, not, max, add, etc) are overridden from the base classes (the Boolean and Number class

8

respectively) and their temporally lifted counterparts (And, Not, Max, Add, etc.) are defined accordingly ([19]).

4. Mobile Point Objects on a Transport Network As previously noted, the location-based services are concerned by the mobile point objects, i.e. objects with zero extent that change their location continuously over a predefined network infrastructure (roads, rivers, trains, air-corridors). Such objects are pervasive in many real-life applications. Also, the mobile point objects constitute the simplest class of mobile objects so they can represent the foundation for modeling and representation of other mobile multi-point geometries with fixed or changeable extent. The MobilePoint class provides modeling mobile point objects that move continuously over a predefined network infrastructure (figure 5). Two attributes, the speed and the direction, are defined when the road network database does not contain travel attributes (average speed, travel time, etc.), or the route of the mobile object is not predefined (e.g. the destination is not known beforehand). The MobilePoint class inherits the MobileGeometry class and thus inherits and overrides the aforementioned spatio-temporal operations and relations. Geometry

MotionSlice 1

0 .. n +motion 1

1

Mobil eGeometry

1 Motio nType

TimeInstant Route

MobilePoint {Geo metry = Point} spe ed : Single directi on : Si ngl e Rout e() : Li neSt ring Enters(geo : Geomet ry) : B oolean Leaves(geo : Ge ometry) : Bool ean Cro sses(geo : Ge ometry) : Bool ean Bypa sses(geo : Geo metry) : Bool ean

start : Point dest : Point +route GetRoute() : LineString PointOnRoute(p : Point, d : Double) : Point 0..1 PointOnRoute(p : Point, td : TimeDuration) : Point RouteDistance(s : Point, e : Point) : Double TravelTime(s : Point, e : Point) : TimeDuration RoadSeg(p : Point) : RoadSegment

1..n + segmen ts RoadSegment centerLineOf : LineString

Figure 5. Modeling the mobile point object in the mSTOMM data model The GeometryAt operation is overridden and implemented for the case that the underlying road network data does not contain the average speed or the travel time on specific road segments:

Geometry* MobilePoint::GeometryAt(TimeInstant t)

9

{ int i=0; double dist, path; float v; TimeDuration td; while (i < NumOfSlices () && MotionSliceNth(i)->timeinst.Before(t)) i++; int j = i; i--; if( j < NumOfSlices()) { dist = route.RouteDistance((Point *) MotionSliceNth(i)->Location(), (Point *) MotionSliceNth(i+1)->Location());

td = MotionSliceNth(i+1)->Time() - MotionSliceNth(i)->Time(); v = dist / td.Seconds(); } else v = speed; path = v ⋅ (t - MotionSliceNth(i)->timeinst). Seconds(); return route.PointOnRoute( (Point *)MotionSliceNth(i)->geometry, path); }

The Route operation defined in the MobileGeometry class is redefined in the inherited classes, because for different mobile geometry types, the trajectory operation returns the specific geometric result. Such an operation applied to the mobile line string object yields the Polygon object as the result, and for the mobile point object with the associated linear motion function returns the LineString geometric object. The model defines operations arisen from the motion of a mobile point over a mobile or static polygonal area, such as Enters, Leaves, Crosses, Bypasses, etc. proposed in ([5]) as developments (figure 5). Such operations enable examination of changing spatial relations over time by simply sequencing basic spatio-temporal predicates. We extend the definition of those operations applying them to the mobile/static point and the linestring object using the same semantics and definitions given in ([5]) for the mobile point and the mobile region. Those operations are particularly useful in querying mobile points moving on network paths. Thus mobile object enters in the area of static or mobile polygonal object during given time period, if it was outside of the polygon at the beginning of the period (the disjoint relation), then at certain time instant was at the border of the polygon (the touches relation) and is within the region to the rest of the time period (the within relation). Thus, for a mobile point and a mobile linestring, the Enters predicate is expressed using a C++ syntax as: Boolean MobilePoint::Enters(geo: Geometry) { if(geo->GeometryType == "MobileLineString") { MobilePoint *int = (MobilePoint *) Intersection(geo); if(int->NumOfSlices == 0) return false; MotionSlice *touch = int->MotionSliceNth(1); TimeInstant *tt = touch->Time(); TimeInstant *ts = LifeSpan()->Start(); TimeInstant *te = LifeSpan()->End(); return GeometryDuring(TimePeriod(ts, tt-1))->disjoint(geo) && GeometryDuring(TimePeriod(tt+1, te))->within(geo); } …}

The implementation of the Enters predicate uses the temporally lifted Intersection point-set operation applied to the mobile point and the mobile linestring, yielding the mobile point as result. The spatio-temporal

10

predicates disjoint and within are applied according to semantics defined in ([5]) as temporal aggregation. Similar definitions hold for Leaves (inverse of Enters), Crosses and Bypasses predicates. For the purpose of constructing an object's trajectory over a predefined route, the Route class is defined. The MobilePoint class associates the Route class which aggregates an ordered set of the RoadSegment class objects with an OGC SF LineString geometry, and contains the starting and the destination points that lie on the first/last road segment respectively (figure 5). The Route class defines operations for the determination of the point along the route on a specific distance or the travel time from the defined point (two versions of the PointOnRoute operation). For calculation the route distance or travel time between two points on the route (the RouteDistance and the TravelTime operations respectively). The GetRoute operation enables retrieval of the LineString object, which represents the route geometry, while the RoadSeg operation retrieves the road segment along the route, which contains the specified point.

5. Data Model Implementation in a Database System The implementation of the proposed mobile object data model in an object-oriented application and a database is straightforward using the defined UML class diagrams. The data model implementation in the (object-) relational database domain is based on the definition of the user-defined data types and operations within object-relational DBMS and appropriate mobile extension of OGC Simple Features for SQL specification ([8], [11]). If the LBS server is based on a relational DBMS, the support for mobile object data management is integrated in the LBS application components. The user-defined data types and user-defined functions are defined in terms of the SQL DDL statement CREATE TYPE ([12]) as follows: CREATE TYPE MotionSlice AS OBJECT (slice# NUMBER, geometry Point, timeinst DATE, mt MotionType); CREATE TYPE Motion AS TABLE MotionSlice; CREATE TYPE MobilePoint AS OBJECT (GID NUMBER, speed NUMBER, direction NUMBER, motion Motion, MEMBER FUNCTION GeometryAt(t TimeInstant) RETURN Point …); CREATE TYPE Ambulance AS OBJECT (ID NUMBER, name CHAR(64), driver CHAR(64), type CHAR(256), locations MobilePoint); CREATE TYPE Taxicab AS OBJECT (ID NUMBER, company CHAR(64), driver CHAR(64), type CHAR(256), locations MobilePoint); CREATE TYPE Street AS OBJECT (ID NUMBER, name CHAR(64), centerLineOf LineString); CREATE TYPE Municipality AS OBJECT (ID NUMBER, name CHAR(64), area Polygon);

11

The operations defined for those types are implemented as the user-defined functions that can be applied to the user-defined data types. The query facility of SQL is provided by the well-known SELECT-FROMWHERE clause. The user-defined operations on the user-defined data types can also be included as the predicates and the functions within the SELECT and WHERE clause and embedded in the SQL statement. Thus, the mobile spatio-temporal queries can be specified and processed, like: 1. Select ambulances that are within 2 km around of my current address: select amb.id, amb.name, amb.driver from Ambulance amb where (amb.locations.GeometryAt(Now)).distance(Point(xref,yref))