Accessing to Spatial Data in Mobile Environment Arunas Stockus, Alain Bouju, Fr´ed´eric Bertrand and Patrice Boursier University of La Rochelle Laboratoire d’Informatique et d’Imagerie Industrielle (L3i) Avenue Michel Cr´epeau, 17042 La Rochelle, France farunas.stockus,. . .
[email protected] Abstract We describe in this paper the data management principles on which data processing is based in an embedded navigation system. We study this management in the framework of a Web-based navigation and spatial data visualization system. We use an Internet-based connection to download the data located on a distant data server and a Web browser interface to process and to visualize them locally. All data are transferred as the result of spatial queries defined on the client side and executed on the data server. The data management on the client side uses a data cache and takes into account spatial aspect of data. It performs a test for semantic inclusion of results of spatial queries and reuses already available data. We also introduce spatial query restrictions in order to reduce the selected data only to the data set relevant to the actual location of mobile user. Restriction and semantic caching of spatial queries enable us to reduce the amount of data transferred between a mobile client and a data server.
1. Introduction The current development of mobile communications and mobile devices lets us believe that the access to Internet will be one of the main features of future mobile computing. The possibility to take into account the location of a mobile user is another important new feature. The integration of position in the management of data can help the user to search and access data related to his location. In this paper, we present principles of data management in an embedded navigation and spatial information visualization system. The positioning of mobile clients is one of its main functions. The visualization of the position involves the use of digital maps and their integration with other data sets. Thus, we consider the navigation system also as a geo-referenced data visualization system. The presented system is a Web-based navigation system
developed on a client-server model. Data visualization uses Web browser interface and it access to distant data sources through the Internet-based connection. The communication with centralized data and application servers enables the mobile user to update data and applications in real time, depending on his location. We consider two main issues. The former concerns the diversity of data sources (locally connected positioning devices, distant servers, etc.). We define a modular software architecture, where software components manage the access to those various data sources. The latter is related to the management of data exchange between the mobile client and data servers. We adopt an approach where the client is able to perform a part of data processing without connection to the server. All data are transferred as result of spatial queries set out on the client side and executed on the data server. The client manages a data cache which takes into consideration the actual location of the user. It performs the validation of cached data entities and tests whether the result of a spatial query is semantically included within the results of previously executed queries (named, semantic inclusion of spatial queries). We also introduce the restriction of user queries. It reduces the selected data only to the data set related to the actual position of mobile user. Such data management is appropriate to mobile environment with limited calculation power and data transfer rate of wireless communications. We start with a review of related works. Then we briefly present the architecture of the system. We continue by giving a formal description of data management principles: execution of queries, test for semantic inclusion of spatial queries, validation of data and management of client-server communication. We give some remarks on results of practical application of presented principles, before concluding.
2. Related works Some work have been led on the development of vehicle navigation systems integrating Web, GPS (Global Position-
ing System) and GIS technologies [9, 16, 10]. They are often considered as Wed-based systems. The presentation of spatial data through the Web browser interface is one of their functionality. At this point they are related to another domain: Web-based access, integration and visualization of spatial data [18]. Two main approaches are used to access to spatial data through the Web: server-side and client-side oriented methods. In the first case, all processing of user requests is done on the server side, and the client (Web browser) only visualizes the resulting image of a map [17]. This image is created by special programs executed on the server and managing the access to data sources: CGI scripts (Common Gateway Interface), ASP (Active Server Pages), Java Servlets and others similar methods. This approach does not allow the permanent connection from the clients to the data servers. It also leaks the autonomy of the client, because any modification of data visualisation parameters needs a connection to the server to execute a new query and to generate a new image of a map. In the client-side oriented approach, some processing of data is done by the client. It is typically performed by software components executed in the Web browser: Java applets, ActiveX components or browser’s plug-ins [11, 12]. They allow to process data independently of the server and propose more advanced interactivity with the user. In all cases spatial data sets are reached directly from the client or through some middleware components. The management of data communication can also follow various approaches. The amount of transferred data can be decreased by introducing methods and protocols for their reduction, simplification and/or compression. When applied to spatial data, the reduction of resolution of raster images or the progressive loading of the vector maps can be used [5, 1]. This reduction can also be based on use of protocols, which are better adopted to wireless communications and mobile devices [19]. Another type of methods could be based on the reuse of data. The data cache on the client is built and reused every time user access to previously retrieved data. It can be a simple validation and reuse of cached data entities [21], similarly to functionality of proxy servers widely used on the Web [20]. Data caching can also be based on more advanced data management as a semantic caching of queries’ results. It consists in deducing the possible semantic of a query (the answer) from its syntax (its symbolic description). The deduced semantic is then used to test whether the answer of a query can be computed from the set of already available answers. Such semantic query caching is frequently used in database management systems for optimization of query execution and for management of database views [13, 8, 6]. At present, the methods based on the semantic of queries are also adapted in Web-oriented applica-
tions, as for example Web search engines [3]. The application of data caching for mobile clients has one particularity: its management can take into account the location of the mobile. The selection of transferred data sets and strategies of data replacement can use the knowledge of user’s actual and future position [14, 15]. Our work is based on the combined use of similar techniques. We use Web-based data access with client side data processing. The test for semantic inclusion of spatial queries and positioning of a mobile user is the base of management of data cache. Caching and restriction of spatial queries was studied in the GeoLib library [12], but applied to one-to-one matching of queries. We extend this approach to a set of previously executed queries.
3. Architecture The system organization is based on a client-server model. We consider that data are centralized on a data source represented by a server. Data transfer from the server to the client is performed as answer to a client requests.
3.1. Software components The software components are separated in two parts: data visualization and data servers (figure 1). Data visualization is dedicated to interaction with user. It manages data visualization, user requests and communication with data servers. The server defines a uniform data representation. It manages direct access to data sources (files, databases or other servers) and hides it from the visualization part.
Visualization
Local
Distant
Files Databases
Server Data sources (GPS)
Server
Data servers Devices Data sources
Figure 1. System architecture.
The visualization makes part of software used at the client side. It is implemented as a Java application or a Java applet, which can be executed by a Java-enabled Web browser. Typically, data server is a distant server. An additional server can also be needed locally. Like the distant one, it manages the access to such data as local data sources: connected devices or local data copies.
Servers act similarly to Web proxy servers. They receive the client’s requests and answer them by accessing local data sources or redirecting the request to other servers.
3.2. Data sources Data processed by the system can vary in different forms. From the client point of view, they can be local or stored on a distant server. Physically they can be held in a database or files, sent by devices or transferred from other servers. Data can also have different types and formats. These differences are managed by data servers. Another important point is the data updating. We distinguish static and dynamic data. Static data are not frequently updated and the client does not need to perform frequent check for its update. Digital map is an example of such data. Dynamic data are updated frequently. The client must manage them in a way to always present an up to date information to the user. The vehicle’s position sent by the GPS is an example of such data. The navigation system is also a spatial information management system and a visualization system. Its internal data organization is similar to that used in geographic information systems: all data entities are grouped into layers. Every data source is mapped to at least one layer.
4. Principles of data management 4.1. Data model The formal data model can be represented as an objectoriented model. We model real world entities as objects, but we keep some concepts used in digital maps. The data model used for implementation follows closely the given formal definitions. Maps and objects The map M presented to a user is a sequence of layers (l1 ; : : : ; ln ). We associate to each layer a set of attributes and their domains: (a 1 : d1 ; : : : ; am : dm ). This definition describes the structure of each object stored in a layer. It defines the schema of a layer (syntax), while concrete objects stored in the layer composes its instance (semantic). Formally the instance of a layer should be defined by introducing the mapping from layers to the objects and from attributes of objects to their values. To simplify this presentation, we define the instance in a less formal way. Every object owns a unique identifier o. An object stored in a layer comprises some alphanumeric information, that we call the value v (v = (v1 ; : : : ; vn )). It can be accessed through the set of object’s attributes a = (a 1 ; : : : ; an ). The structure of a is determined by the layer’s schema. Every object has associated a time value and a geographical position. The time value t keeps its last modification time.
The geographical position g is modeled by one among three two-dimensional geographical objects: point, line or region. The quadruple (o; v; g; t) defines the whole object entity. However, sometimes we will manipulate only a part of this object (for example, only object identifier o and its modification time t). There is no common object in the instances of different layers. The union of instances of all layers composes an instance of whole map M , that we note by I . Queries We consider in our system only the visualization of data retrieved from data servers. We retrieve data using the criteria expressed in a query. No data are supposed to be created or modified locally. For this reason we define our queries with a restriction: the set of selected objects always belongs to the instance of one layer. The definition of query follows conventional OQL [2] notations: SELECT
o
FROM
1
l ;:::;l
n
WHERE
C
where o is an object from the layer l. Formally, we note such a query as q = (l; L; C ), where l is the layer to which belongs the set of selected objects, C is the selection condition defined over the objects from the layers in L = fl 1 ; : : : ; ln g (l 2 L). We note by q (I ) the result of query q executed on the instance I of a map. This formal query notation is similar to that used in [13]. We consider a query q standing for a spatial query in the sense that the condition C may contain spatial predicates or functions and the result of q holds objects located within some spatial area. In particular, we consider two spatial predicates: intersects and contains. The predicate intersects(o1 ; o2 ) indicates if an object o 1 intersects with o2 . The predicate contains(o 1 ; o2 ) tests whether an object is contained o1 is contained within an other object o 2 .
4.2. Data management parts From the client point of view, we divide the process of data management in several parts (figure 2):
Restriction Query
Validation
Data management Inclusion / cache
Response
Communication
Figure 2. Data management parts.
Query restriction. This is the modification of the new query of the user in a way that it selects only a minimum necessary data subset. Semantic caching of queries. We test if is possible to construct the complete and correct answer to the new query using locally available answers to previous queries. This construction should be performed without connection to data server. Validation. We validate the client data against its “original” copy on the server. Communication. It manages the actual exchange of data between the server and the client.
4.3 Query restriction When a user requests objects, thay must be transferred from the server to the client. However, not all requested data may be used at some time. For example, the user can request the whole map of city streets, but only a part of this map can be actually processed, and in particular, the part relevant to its actual position and visible on the screen. In order to restrict the query q = (l; L; C ) to a part of the map, we add a restriction C r on the condition C . The condition C r is defined over the objects in the layer l. This condition can be considered as a filter which reduces the number of selected objects. The query q r = (l; L; C ^ C r ) is the actually executed query. The data presentation conditions on the client may change over time. The restriction C r must also be modified r and a new query q new r = (l; L; C ^ Cnew r ) must to Cnew be re-executed. So, for a query q we associate a sequence of its restrictions (C1r ; : : : ; Cnr ) which defines a sequence of restricted queries (q 1r ; : : : ; qnr ). Each of them is added and the result of the new query q ir (I ) is obtained at time ti (0 i n). We call this sequence the history of q . If for a given query q = (l; L; C ) one of layers in L is modified on the server, then the result of query q (or a part of its history) available on the client may become invalid. We suppose that if a layer l from L is modified at the moment 0 r t then the result q i (I ) from the history of q is invalid when 0 ti < t . All invalid answers (and restrictions) are removed from the history of a query. The objects that belong to those answers may be deleted from the client’s memory. They can also be reused to construct answers of further queries after a validation of objects (section 4.5). In a practical application we use a particular case of restriction similar to that used in the GeoLib library [12]: the restriction to the visible zone of the map. We suppose that the user is interested only in the part of data visible on the screen of its application. So, the selected objects
must satisfy the condition of intersection with the rectangular area B representing this visible zone. So for a new query q = (l; L; C ) the restricted query is: q
r = (l; L; C ^ intersects(o; B ))
where o is the object of layer l. This restriction mechanism is useful for mobile systems and in particular for navigation systems. The actual position of mobile is used to establish the visible area B . The motion of vehicle is used to create new restricted queries and to download only the parts of map that will be reached soon. Note that the restiction of query q and re-execution of new query q r is implicit (the user asks no new query execution). This functioning is similar to continuous and persistent queries defined in the MOST (Moving Objects Spatio-Temporal) data model [15].
4.4. Semantic caching of queries As a result of many query execution, the client collects a copy of data available on the server. After execution of several queries Q = fq1 ; : : : ; qn g, a copy of the server map instance I available at the client is:
c
=
I
[n
i=1
i (I )
q
We suppose at the beginning, that all data in I c are static, i.e. objects are not modified in I . When a new query q is given, it is possible that the client already contains the answer q (I ). Several cases are possible: 1. None or not all objects of the answer q (I ) are available at the client. 2. The client owns all objects of the answer, but the result of the query cannot be calculated locally. That means that the local instance I c contains all objects from q (I ), but some objects of other layers in L are missing in I c to correctly evaluate C . 3. All objects are locally available to calculate the correct answer q (I ) without connection to the server. The selection condition C of query q = (l; L; C ) can be considered as a description of its result. For a set of queries Q, the general condition:
c=
C
_n
i=1
C
i
describes the result of all previously executed queries. In some cases it is possible to compare the semantic of queries
by comparing this description without actually calculating their result. We note by C (I ) the fact that the condition C is satisfied in the instance I . Note by Q l a set of all queries from Q selecting objects in the layer l:
l = fq
Q
0
j
q
0
= (l
0
0
0
;L ;C
)
2
Q
and l 0
=
l
3
q
2
q
q
g
1
q
The following statement can be proved: Given a query q , a sequence of queries Q and a local copy of instance Ic , the result q (I ) is present in Ic if for each map instance I : C (I ) ) ( Cl )(I ) (1)
Figure 3. Reusing query answers.
_
4
q
of
q Q l2
l
If this condition is not satisfied, then we obtain the case 1 of matching between the client’s q (I c ) and the server’s q (I ) answers. If this condition is satisfied, then at least the case 2 is valid (all objects are available locally). Instead, the case 3 requires some additional conditions to be satisfied: the implication 1 must be verified for every layer from L. We can prove the following statment: Given a query q , a sequence of queries Q and a local copy of instance Ic , the result q (Ic ) = q (I ) if for each map instance I and for every layer l 2 L: C (I )
_
)(
l )(I )
C
q Q l2
(2)
l
The test for validity of implication (1) is an NP-hard problem in general case [4]. Some algorithms exist for testing satisfiability and validity of special cases of conditions, as for example the conjunctions of arithmetical inequalities defined over numeric values [7]. In our application we consider a special case of such test. Given the query q and its history (q 1r ; : : : ; qnr ), the part r C of the condition is identical for each query q i and the r restriction condition C i is the only part changed. So, the result of the new restricted query q nr +1 is already present in the history if for each map instance I the following condition is satisfied:
_n
r n+1 (I ) ) (
C
i=1
r i )(I )
C
(3)
If the inclusion 3 holds, then the local query execution can be reduced to the evaluation of the simpler query 0 r q = (l; fl g; Cn+1 ) over the history of q . We use this condition in the management of cache of spatial queries. It is based on the following dependencies between spatial operators:
for two objects o1 and o2 : contains(o1 ; o2 ) ) intersects(o1 ; o2 )
if for any objects o 1 , o2 and o3 , contains(o1 ; o2 ) is true, then: contains(o2 ; o3 ) ) contains(o1 ; o3 )
The application of condition 3 to the restriction on visible zones means testing inclusion of new visible area within the union of already visited areas (figure 3). The execution of a new query q with this restriction can be reduced to selection of objects from the history of q intersecting the new visible area. Above presented principles defines the following approaches for execution of a new query for any instance I and its partial copy on the client I c :
Direct evaluation. The query q can be evaluated directly on Ic : q (Ic ) = q (I ). The condition 2 is a sufficient condition for this evaluation. Reduction of queries. There can be found a “simpler” query q 0 whose local execution produces the correct answer: q 0 (Ic ) = q (I ). The condition 3 is one of sufficient conditions to construct a query q 0 . Reconstruction of instance. There can exist a procedure P , that takes I c with the sequence of queries 0 Q and produces a new local instance I c such that: q (P (Ic ; Q)) = q (I ). This approach is studied in [13]. Its application was limited to the reconstruction of numeric values of attributes of missing objects.
We apply the same reasoning to queries defined over dynamic data with the difference that we eliminate the answers (and corresponding conditions) of queries that are no longer valid (see the definition and validation of history of queries).
4.5. Data validation Dynamic data collected at the client side must be validated before use. This validation is performed for the whole layer and for each individual object. At the layer level, we test the equality of the layer’s modification time known on the client and on the server. If this time is equal, all client’s objects are considered to be valid and can be used for construction of new answer. If not, every individual object must be validated. The validation process of objects is similar: the data modification time on the client must be equal to the time available on the server. We consider two data sets: Is (the original data set on the server) and I c (the copy of original data set on the client). The validation process then can produce three subsets:
we send object identifier and modification time ((o; t)) and we note T ;
we send only object identifier ((o)) and we note O.
Client time
New: objects that are present in I s , but not yet in I c .
Server
V
(a)
Present: objects that are present in both I s and Ic . Obsolete: objects that are present in I c , but do not exist in Is any more.
q
Client time
If we test the modification time of objects, then the set Present can be subdivided into two subsets:
q T O V
Server
(b)
Valid: objects that are not modified on the server. Client
Updated: objects that are modified on the server and that must be updated on the client. The validation of object sets can occur on the client and on the server. When validating the objects on the client at some moment of time, we validate the whole local instance (an instance Ic ) against an answer of a query executed on the server (a set Is ). We keep Valid, update Updated and add New objects. We do not modify the Obsolete objects, because the server’s answer I s has no information on their validity. When validating the objects on the server, we compare the client’s answer to a query (I c ) with the answer of the server (Is ). In this case, we delete Obsolete, keep Valid, update Updated and add New objects. Updating and adding new objects means their transfer from the server to the client.
4.6. Data transfer When transferring data, we send either the whole object or only a part of it. We distinguish three cases in our application:
we send the whole object (i.e. all the packet (o; t; v; g )) and we note this set V ;
time
q+T
Server
V+O
(c)
We consider three schemas of data transfer between client and server. The communication can be direct (figure 4(a)). A client sends a query q to the server and directly receives a set of whole result q (I ) = V . For the second schema, the server first sends the set T of identifiers and modification time of objects from the result q (I ) (figure 4(b)). The client validates them locally by choosing objects O that are missing or updated. The client then requests the objects O from the server and receives them as the answer V . Data transfert can also use the client side answer version (figure 4(c)). The client sends a query q with the description T of possible answer on the client side. Data are validated on the server side and the server sends objects that must be created or updated V and identifiers O of objects that must be deleted (Obsolete).
Figure 4. Data transfer schemes.
Each communication schema has preferred use case. We use the first schema when no data of the answer to a new query are available at the client. It may occur when the query is executed for the first time or when the test for semantic inclusion shows that no objects in the answer could be covered by previous queries. The second schema is used when a part of data is already available on the client (it can be detected after the test for semantic inclusion). Note that this schema gives a possibility to download missing objects (New and Updated) but has no information on Obsolete. So it is limited to static data. The third schema is more appropriate to manage dynamic data: objects that are often created, updated and deleted. The validation of objects on the server enables to send the most recent version of objects to the client.
4.7. Data replacement In the formal definition we did not limit the size of the query’s history. However, the resources of mobile devices are limited and an application needs to perform the replacement of cached objects in order to reclaim space for answers of new queries. We consider two strategies for cache replacement: Replacement of the oldest answer. This is also called the LRU strategy (Last Recently Used). Replacement of farthest answer. In this case we delete answers whose visible zone is farthest from the actual position of mobile user. The replacement of objects can be explicit and the removing of objects occurs when an application misses free memory. It can also be implicit. In this case we fix a limit to the number of answers in the history of a query. The cache replacement occurs when this limit is reached.
5. Implementation and simulation results We have developed a prototype of vehicle navigation system based on the concepts previously described. It is implemented as Java applets and applications. Namely, the data visualization part is a Java applet which visualizes digital maps and incorporates some associated information (figure 5): position of vehicle, multimedia links, etc. The access to locally connected GPS device is managed by local server (figure 1).
tion. The data set was composed of three layers of a digital map covering La Rochelle city: Important points. This layer contains 280 objects of type point. The whole layer should take 87 KB in application’s memory. Streets. This layer contains 1609 objects of type line. The size of layer is 625 KB. Buildings. This layer contains 280 objects regions and its total size is 539 KB. The GPS was used to establish the position of the mobile client. The trajectory of this trip was about 33 km length. If we consider the communication with the data transfer rate of 1.5 KB/sec (for example, the rate of communication using a cellular GSM phone), then the initialisation of map and the transfer of whole map should take approximately 15 minutes. We should need about 1.2 MB of memory to store this data set. Note that we have used a handheld-PC with 16 MB of memory for some experiments. It was sufficient to execute a Java applet and to load the whole map in the memory. Further presented results address the data transfer issues.
5.1. Restriction to visible area The restriction to visible area commonly used with the data caching can considerably reduce the amount of data to be transferred from the server to the client. Tables 1 and 2 present some results of experiments. The column Area shows the size of visible area. For example, 500 m corresponds to the area of 500500 meters. Note that the area 1000 m corresponds to a commonly used visible zone of the map. The columns Points, Lines and Regions shows the results for corresponding layers. The column Nb. q contains the number of queries sent to the server. Area 500 m 1000 m
Figure 5. The applet of data visualisation with the interface for a HandheldPC.
1500 m 2000 m
We present the results of some experiments and simulations. They show the effectiveness of data caching in mobile environment. In experiments we have applied the restriction to the visible area: the client requested the part of data near its posi-
Points 2 KB (4) 5 KB (14) 10 KB (30) 15 KB (45)
Lines 10 KB (24) 29 KB (72) 57 KB (145) 87 KB (221)
Regions 15 KB (17) 35 KB (49) 63 KB (96) 94 KB (145)
Nb. q 117 54 31 20
Table 1. Data transfer without a cache. The table 1 shows the average size of answers to be transferred when the restriction to visible area is applied. In
500 m 1000 m 1500 m 2000 m
Points 1 KB (1) 1 KB (2) 2 KB (5) 3 KB (8)
Lines 2 KB (4) 6 KB (13) 11 KB (28) 18 KB (46)
Regions 2 KB (3) 6 KB (8) 11 KB (18) 18 KB (29)
Nb. q 55
52
31
50
Regions Lignes Points
Number of queries
Area
48
18
46
11
44 42
Table 2. Data transfer using a cache.
40 2
6
8
10
12
14
(a)
Regions Lignes Points
12 10
Size in KB
parenthesis we give the average number of objects in an answer. No cache is used in this case and the result of every query must be entirely transferred from the server. The table 2 presents the similar results when using the cached objects. The average number of objects transferred from the client is smaller, because a part of objects where already present in the cache. Approximately, only 15% to 25% of requested objects must be effectively transferred (75% to 85% of them are already available in the cache. The total size of transferred data can be reduced 65% to 85%. The number of queries and the number of objects in the answer to each query depend on the size of visible area. For smaller area, the number of objects in the answer is smaller and the total number of executed queries is higher.
4
Limit of anwers in history
8 6 4 2
5.2. Limitation of history Results presented in table 2 correspond to the case when no cache limit is fixed and all answers are keept in the cache. The figure 6 presents the results when history size was limited (the visible area was fixed to 1000 m). We should notice, that the “recent” cache forms the biggest part of reused data (7-8 answers for given configuration). The increase of history size has no sensitive influence to the reuse of the cache. This is due to the specific usage of cache in a navigation system: usually a vehicle moves away from already visited area. For the same reason the motion of the vehicle can be used in a way to anticipate future queries and to avoid to slow down the data transfer. For example, if the visible area is fixed to 1000 m and the size of history is 10, then the average total size of queries’ answers is 20 KB. The transfer of such amount of data through the communication of 1.5 KB/sec should take 10 seconds aproximatevly. This time is sufficient to prefetch the data covered by the next visited area. We should also notice, that we have considered the slowest case of wireless communications. The development of new widely available wireless comminication services and
2
4
6
8
10
12
14
Limit of anwers in history (b)
Figure 6. Influence of history on the number of queries (a) and the size of answers (b).
protocols, as for exemple GPRS (General Packet Radio Service), should increase the performance of data transfer.
6. Conclusion and future works The presented embedded navigation system is based on a client-server architecture. It combines a set of distributed data management techniques: the local data caching, the validation of spatio-temporal data, tests of semantic inclusion of spatial queries. A combined use of these methods helps to reduce the amount of data transferred between the client and the server. The proposed semantic caching of spatial queries uses the restriction to the visible area. The analysis of complex
and more general selection conditions is one of directions for our future works. The studied data caching is applied to a fixed data set. This study can be extended to the management of multiscale data, vhere the scale of transfered data can be shoosen dynamicly. It can be cosen based on available ressources of mobile device, communication speed or map’s zoom level. We also plan to include the management of spatial indexes in the presented framework. The index can be considered as a part of data downloaded by the client. In this case the methods similar to data caching can be applied for its transfer and its management.
Acknowledgements This research has been partially founded by the PoitouCharentes region and the Communit´e d’Agglim´eration of the city of La Rochelle, France.
References [1] M. Bertolotto and M. J. Egenhofer. Progressive Vector Transmission. In 7th international symposium on Advances in geographic information systems, pages 152–157, November 1999. [2] R. Cattell, D. Barry, M. Berler, J. Eastman, D. Jordan, C. Russell, O. Schadow, T. Stanienda, and F. Velez. The Object Data Standard: ODMG 3.0. Morgan Kaufmann, 2000. [3] B. Chidlovskii and U. M. Borghoff. Semantic Caching of Web Queries. The VLDB Journal, 9(1):2–17, 2000. [4] S. Cook. The complexity of theorem-proving procedures. In Proceedings of the Third Annual ACM Symposium on the Theory of Computing, pages 151–158. ACM Press, 1971. [5] X. Delord, S. Perret, and A. Duda. Efficient Mobile Access to the WWW over GSM. In SIGOPS European Workshop, Sintra, Portugal, September 1998. [6] P. Godfrey and J. Gryz. Answering Queries by Semantic Caches. In 10th International Conference Database and Expert Systems Applications, (DEXA’99), pages 485–498, August/September 1999. [7] S. Guo, W. Sun, and M. A. Weiss. Solving Stasfiability and Implication Problems in Database Systems. ACM Transactions on Database Systems, 21(2):270–297, June 1996. [8] A. M. Keller and J. Basu. A Predicate-based Caching Scheme for Client-Server Database Architectures. The VLDB Journal, 5(1):35–47, 1996. [9] K. S. Kim, M. S. Kim, K. Lee, and J. H. Lee. The Development of GIS-based AVL System: Large GIS Database Handling Perspectives. In IEEE International Conference on Intelligent Vehicles, Stuttgart, Germany, pages 235–239, October 1998. [10] E. Kotsakis, A. Caignault, W. Woehler, and M. Ketselidis. Integrating Differential GPS data into an Embedded GIS and its Application to Infomobility and Navigation. In 7th ECGI and GIS Workshop, June 2001.
[11] D. Kotzinos and P. Prastacos. GAEA, a Java-based Map Applet. In TELE-GEO’99, May 1999. [12] D. Kvedarauskas, P. Boursier, X. Culos, T. Deltheil, and S. Iris. GEOLIB: A Software Component for Making GIS Tools Interoperable. In International Conference on Interoperating Geographic Information Systems, Santa Barbara, California, December 1997. ˚ Larson and H. Z. Yang. Computing Queries from [13] P.-A. Derived Relations. In A. Pirotte and Y. Vassiliou, editors, VLDB’85, Proceedings of 11th International Conference on Very Large Data Bases, Stockholm, Sweden, pages 259–269. Morgan Kaufmann, August 1985. [14] Q. Ren and M. Dunham. Using Semantic Caching to Manage Location Dependent Data in Mobile Computing. In Sixth International conference on Mobile Computing and Networking (MOBICOM2000), pages 210–221, August 2000. [15] A. Sistla, O. Wolfson, S. Chamberlain, and S. Dao. Editors O. Etzion, S. Jajodia and S. Sripada, Temporal Databases: Research and Practice, chapter Querying the Uncertain Position of Moving Objects, pages 310–337. Springer, 1998. [16] A. Stockus, A. Bouju, F. Bertrand, and P. Boursier. Webbased Vehicle Location. In IEEE Intelligent Vehicles Symposium, Dearborn, USA, pages 436–441, October 2000. [17] M. Szmurlo, M. Gaio, and J. Madelaine. The Geographical Anteserver: a Client/Server Architecture for GIS. In J. Strobel and C. Best, editors, Proceedings of the Earth Observation & Geo-Spatial Web and Internet Workshop in ”Salzburger Geographische Materialien”, volume 27. Instituts f¨ur Geographie der Universit¨at Salzburg, 1998. [18] F. J. Wang and S. Jusoh. Integrating Multiple Web-based Geographic Information Systems. IEEE MultiMedia, 6(1):49– 61, January-March 1999. [19] Wireless Application Protocol Architecture Specification, April 1998. http://www.wapforum.org. [20] D. Wessels and K. Claffy. ICP and the Squid Web Cache. IEEE Journal on Selected Areas in Communications, 16(3):345–356, April 1998. [21] K.-L. Wu, P. Yu, and M.-S. Chen. Energy-Efficient Mobile Cache Invalidation. Distributed and Parallel Databases, 6(4):351–372, October 1998.
