Methodology Comparisons in Progressive Transfer of Vector-Based Geographic Data

In this research we use the tGAP (Topological Generalized Area Partition) methodology to create and consume a variable-scale topological reactive data structure to progressively transfer vector-based GIS data in client/server architectures. Many researches has been carried out in the past in this subject and different approaches and variations of the tGAP data structure have been proposed, but the problem of how to effectively communicate and transfer the data between clients and servers in client/server architecture has not been the main focus of the previous works. We describe various tGAP data structures and implement an ameliorated version of the tGAP data structure using left-right topology without edge references that minimizes both usage of the network bandwidth and the amount of data stored in the database which in turn minimizes the execution time of attribute and spatial queries.We propose two different architectures and perform methodology comparisons. First, we design a client that progressively polls vector-based spatial data from a server. The client application initiates the requests based on its current map extent and keeps track of the features drawn on the map. Every time the user pans or zooms to a smaller/larger scale in the map the multi-threaded application will asynchronously request for the termination of the previous request (if it is still in progress) and polls the data for the new scale/extent. The advantage of multi-threaded architecture in the client is that the UI thread never gets blocked while the background thread is submitting the request and retrieving the spatial data from the server. On the other hand usage of the tGAP data structures will allow the server to transfer spatial data from higher importance levels down to the lower importance levels based upon the hierarchical information that has been stored for all the faces and the edges, i.e. generalized versions of the faces will be transferred first and the client will progressively update the content of its map view by retrieving lower important neighboring objects to obtain more details.In our second design the client submits a request for the geographical data in a given map extent and server fetches the data from a spatial database. The difference with the previous approach is that this time the server pushes the data to the client and keeps track of the objects submitted to each client (session). A background thread in each client retrieves objects from the server in the same fashion, i.e. objects with higher importance levels come and drawn first etc... Since the client benefits from multi-threaded mechanism users would be able to interact with the map while data are pushing from the server and no blockage in their UI thread will occur.In the end we will analyze and compare both methodologies and investigate the effectiveness of database indexes as well as spatial indexes in their performance and will show how both approaches could benefit from them