AEGIS

AEGISA state-of-the art component based spatio-temporalframework for education and research

by Roberto Giachetta

Department of Software Technology and Methodol-ogy, Eötvös Loránd University, Budapest, Hungary.groberto@inf.elte.hu

Abstract

In past years, geoinformation has gained a signifi-cant role in information technology due to the spreadof GPS localization, navigation systems and the pub-lication of geographical data via Internet. The in-clusion of semantic information and temporal alter-ation has also become increasingly important in GIS.The overwhelming amount of spatial and spatio-temporal data resulted in increased research efforton processing algorithms and efficient data manage-ment solutions.

This article presents the AEGIS framework, a cur-rently developed spatio-temporal data managementsystem at the Eötvös Loránd University, Faculty ofInformatics (ELTE IK). This framework will serve asthe future platform of GIS education and research atELTE IK. It aims to introduce a data model for theuniform representation of raster and vector data withtemporal references; to enable efficient data manage-ment using specialized indexing; and to support in-ternal revision control management of editing op-erations. The framework offers a data processingengine that automatically transforms operations fordistributed execution using GPGPUs, allows fast op-erations even with large datasets and high scalabilitywith regard to new methods.

To demonstrate the usage of the system two pro-totype applications – segment-based image classifi-cation and agent-based traffic simulation – are alsopresented.

Keywords: Geospatial Information Systems,spatio-temporal data, indexing data structures, GPUbased data processing, revision controls of data, re-motely sensed image classification, agent based traf-fic simulation.

1 Introduction

Geographical information systems (GIS) have under-gone a spectacular development in the past years.Beside traditional areas of GIS applications a rapid

development has taken place in the world of naviga-tion systems as well. Google Maps and NASA WorldWind, together with their Application ProgrammingInterface (API), are common tools in the global han-dling of spatial data. The world of open source soft-ware has also evolved a lot. There is a rising need forprofessionals whose practice cover both informationtechnology and geography. This paradigm shift hasto be taken into account both by professionals and byacademic people.

At the Eötvös Loránd University, Faculty of In-formatics (ELTE IK) the informal association, calledCreative University GIS Workshop (TEAM) dealswith several related research topics, e.g. IntelligentRaster image Interpretation System (IRIS), Univer-sity Digital Map Library (EDIT), Virtual Globes Mu-seum (VGM) and segment-based analysis of remotesensing images. An important collaboration takesplace both in education and research with the Insti-tute of Geodesy, Cartography and Remote Sensing(FÖMI). This governmental institution is responsiblefor the research, development and application of re-mote sensing in Hungary, mainly in the areas of agri-culture and environmental protection.

Based upon the experience gained with researchand education, the plan of a standalone geographicframework, called AEGIS has been outlined. It isdesigned for broad functionality, efficiency, and al-lowing students to skip the learning curve and con-centrate on their main tasks in lab projects and the-sis works without the need of building up auxiliaryfunctionality from scratch. The system is based onstandards of the Open Geospatial Consortium (OGC– http://www.opengeospatial.org), and is not in-tended to be a competitor of current industrial GISsolutions or GIS toolkits such as GeoTools (http://www.geotools.org), but rather to be a prototypeand sandbox for experimental research and educa-tion.

Students are offered step-by-step learning of stan-dards, algorithms and solutions, easy to understand,documented source code, and well structured com-ponents that can be used for many types of GISprojects, including thesis works. Researchers mayalso find many possibilities in this flexible, yet stableenvironment to test results and compare them withexisting solutions. Even the framework itself has sev-eral experimental features that are research topics,including multi-level spatio-temporal indexing solu-tions, revision control of spatial data and automated

OSGEO Journal Volume 13 Page 68 of 114

AEGIS

GPU based data processing.The AEGIS concept has been introduced in Gia-

chetta et al. (2012), and is currently under develop-ment. Some features are only outlined in the paperto be implemented in the future. The framework isto be released as open-source project in the future.

The rest of the paper is arranged as follows. InSection 2 we will outline the concept and architectureof our system. Section 3 explains details of the AEGISdata management model. Section 4 presents the dataprocessing capabilities and solutions. Section 5 de-scribes the first applications of the system, namelysegment based image classification and agent-basedtraffic simulation. Section 6 concludes the paper.

2 System architecture

AEGIS has component based architecture in order tobe as adaptable and customizable as possible. Sev-eral class libraries are stacked together to build upsystem functionality and relevant libraries can bechosen for any application ranging from desktop edi-tors through mobile viewers to server services. Theselibraries also provide API functionality for buildingcustom applications. The AEGIS framework stackcontains the following components (see Figure 1).

Figure 1: AEGIS framework stack.

• Core is the heart of the framework contain-ing the OGC and ISO compliant 2D/3D spa-tial data model and reference model includingseveral utility classes (e.g. indexing structures).This component is designed not to contain anytemporal references as not all GIS applicationsrequire it. However base interfaces are pro-vided for time management.

• Core.Temporal is the extension of the data modelwith temporal properties, reference model and

spatio-temporal indexing structures support-ing multiple time measurement solutions. Oursolution focuses less on moving objects and tra-jectory and more on modeling stationary spa-tial features with limited temporal validity, forinstance, road sections closed due to construc-tions and remote sensing image series of cropgrowth. Details of the model can be read in Sec-tion 3.

• IO contains the import/export possibilities forGIS file formats and network services. Severalstandard spatial formats are supported. Themodule allows the consumption of OGC webservices including WMS and WFS. Support forfurther services is planned.

• Data component is responsible for databasemanagement. All spatio-temporal data im-ported into the system can be stored in adatabase. AEGIS is designed to handle spa-tial and spatio-temporal information (includ-ing indexing, revision control, etc.) entirelywithin the system, hence no spatial features ofthe database system are required. It is clear thatthis solutions lacks the effectiveness and po-tential offered by most database managementsystems. However it provides researches a sta-ble high level environment to work in. Basedon our earlier experience, MongoDB (http://www.mongodb.org) has been chosen as the pri-mary database backend.

• Processing offers spatio-temporal vector/rasterprocessing operations. For both the Process-ing and the IO components functions are de-fined using a meta descriptor system to sup-port runtime management and extension. Pro-cessing services also offer an internal program-ming scheme based on expression trees. By us-ing this scheme the processing instructions caneasily be transformed to low level GPU instruc-tions and automatically distributed. An inter-nal processing engine is responsible for thispurpose. Details of processing can be read inSection 4.

• Application layer is responsible for user authen-tification, editing, processing and import/ex-port management including the runtime han-dling of available IO and Processing functions.During feature editing changes are overseenand logged to enable revision control of thedata. The layer also contains a scripting en-gine using a dedicated high level domain spe-

OSGEO Journal Volume 13 Page 69 of 114

AEGIS

cific language to enable the creation of customprocessing operations and batch processing ofdata even from multiple sources and formats.

• Communication layer contains services for inter-nal communication between application fron-tend (User Interface and Services) and back-end (Application layer). The primary objec-tive of the layer is to enable the separation ofthese two layers and the creation of thin clientsthat can execute operations on remote servers.Communication uses a service oriented archi-tecture with encryption and user authentifica-tion.

• Services is responsible for providing web ser-vices, mainly in OGC standard formats (WMS,WPS, etc.). This server side module is not tobe confused with the client side IO componentwhich offers OGC service clients to enable im-port of data into the system.

• UI provides graphical user interface compo-nents and 2D/3D data visualization methodsfor multiple platforms including desktop andmobile environments. There are also plans forextending visualization using augmented real-ity on mobile devices.

Using the component based design, the structureof the system can be configured with each install-ment. For instance, a thin client installation of AEGISmay only require Core, UI and Communication com-ponents as data storage, processing, import and ex-port are performed by the server which is connectedto the client via Communication layer. In contrastthe server does not require UI and IO modules, butshould include Services to enable access to data forother applications. A thick client may contain allcomponents except Services and can support local orremote execution of processes. Figure 2 shows thislayout possibility.

The implementation is carried out using the Mi-crosoft .NET Framework, because of the wide pos-sibilities and the simple usage of this develop-ment platform, the strong .NET education carriedout at ELTE and also the success of .NET basedGIS software products such as DotSpatial (http://dotspatial.codeplex.com) and SharpMap (http://sharpmap.codeplex.com).

In the current phase of development the higherlayers (Application, Communication, Services andUI) are only partially complete. Additional research,design and testing will follow before these compo-nents are implemented.

3 Spatio-temporal data manage-ment

Modeling and indexing of spatio-temporal objectshas been a frequent topic among researchers sincethe 90s, and many data models have been intro-duced (Abraham & Roddick 1999, Nguyen-Dinh etal. 2010). However for spatio-temporal data neithercommon solutions have arisen, nor standards havebeen developed so far. In contrast, spatial data haswell known standards maintained by OGC.

Figure 2: Example layout of AEGIS components withthin and thick clients.

As explained in Section 2 the AEGIS data modelis implemented in two components.

• Core holds the spatial model including rasterand vector data representation, spatial index-ing structures and reference system manage-ment. Basic interfaces are defined for tempo-ral relations but are not implemented in thecomponent. The usage of Core components isrecommended in applications where no tempo-ral properties are needed. For all spatial vec-tor features the representation is a direct map-ping of the OGC Simple Feature Access stan-dard (Herring, J. R., ed. 2011). However thestandard has been extended with several newtypes, including raster support. Detailed de-scription of this model follows in Section 3.1.The reference model is an implementation ofthe OGC Spatial Referencing by Coordinatesspecification (Cooper, P., ed. 2010) using EPSGguidelines (http://www.epsg.org/guides/).

OSGEO Journal Volume 13 Page 70 of 114

AEGIS

• Core.Temporal extends the core model with tem-poral properties and references. Hence baseclasses and interfaces are imported from theCore package, the spatio-temporal model canfunction as strictly spatial if needed.

Besides adding temporal properties to featuresspatio-temporal indexing is introduced. Temporalreferences are managed with multiple temporal ref-erence systems (e.g. Clocks, Calendars). The ref-erence model is a partial implementation of ISO19108:2002 Geographic information – Temporal schema(2002).

3.1 Unified vector and raster data represen-tation

In the OGC SFA data model the central item is the Ge-ometry class, which has several specialized versions(including collections) in object inheritance taxon-omy. Geometry defines the interface for spatial prop-erties and operations among any spatial objects. Themodel focuses on two and three dimensional vectordata without any temporal references. In our imple-mentation of this standard, multiple extensions havebeen introduced to enable flexible and effective im-plementation of features (see Figure 3).

Vector and raster data are required to be handledin the same manner so that operations work uni-formly on them. In current geospatial systems therepresentation and operations of raster and vectordata are usually independent of each other. In oursystem, raster data is introduced as descendand ofGeometry. All spatial operations, which are definedon vector objects (e.g. intersection, translation, pro-jection etc.), can also be performed on raster data (forexample the ability to intersect an orthophoto with aland parcel polygon). By using the meta descriptorsystem restrictions can be applied to any processingoperation to prevent raster functions (e.g., intensitytransformations, image filtering) working on vectordata.

For raster data the Raster and RasterBand classesare introduced. RasterBand is a descendant of Rect-angle and contains one band of a raster image, whileRaster is a collection of multiple bands of an im-age. These classes are enhanced with operations andproperties related to raster imagery. Images can bestored in several radiometric resolutions (from 8 bitto 64 bit for every band), may contain pyramid lay-ers, and image masks (to indicate actual image pix-els).

Vector geometries can be transformed to graphrepresentation using the GeometryGraph class thatcontains points as edges and paths as vertices. Thisrepresentation enables merging multiple geometriesto form a single network. Equivalently the Raster-Graph class is the graph representation of raster datawhere vertices contain intensity informations of pix-els. Graphs may include a multi-level structure,where a single high level vertex contains multiplelow level vertices. This is useful for example, man-aging road hierarchies or raster image segments.

New collections, called maps have been in-troduced primary for efficiently managing largeamount of objects. Map classes are build up us-ing R-tree based indexing structures for fast spatio-temporal query of objects, as described in Section3.3.

All geometries have been extended by the possi-bility of storing the time instant or time interval inwhich they are considered to be valid. Generally,items in a collection do not need to exist in the sametime interval, but restrictions can be made to forcetemporal equality among all items of the collection.The reference system of these temporal geometriesis usually a compound reference system containinga temporal system to manage calendar or clock as-pects.

All features may contain any number of descrip-tive data (metadata) stored as key/value pairs. Allgeometries within a collection require to have thesame metadata schema. The metadata is also time-dependent and is only valid when the feature isvalid, but values can change multiple times withinthe validity. These changes may or may not dependon the change of the feature’s spatial properties.

It must be noted that in the current phase ofdevelopment not all operations work as efficientlyas other implementations of the SFA standard (e.g.,GeoTools, DotSpatial) as clarity, readability and stuc-ture of the source code is among top priorities, butsteady progress is expected also in this factor.

3.2 Data storage

The data model has been specifically designed tohandle all spatial and temporal properties of the dataat system level without requiring any spatial supportfrom the database system. Hence the database back-end has been chosen based on previous experimentalresults on performance of queries and modifications(Máriáas et al. 2012). Hence, currently MongoDBserves this purpose. In the future support is plannedfor PostGIS and other database systems as well.

OSGEO Journal Volume 13 Page 71 of 114

AEGIS

Figure 3: The data model based on Simple Feature Access.

OSGEO Journal Volume 13 Page 72 of 114

AEGIS

MongoDB is a document-oriented database man-agement system (DODBMS), which enables theschema-less storage of hierarchical data (Padhy et al.2011). Due to the large variety of spatio-temporaland descriptive data it has proven to be more ef-ficient in data querying than SQL based systems.MongoDB has only minimal spatial support for 2Dgeometry, but the structure of the stored items can beeasily customized, even to allow the storage of differ-ent types of geometries in a single collection. Thus,no spatial operations function for these geometries inthe DODBMS, but still, simple spatial and temporalqueries (such as bounding box based selection) areusable.

For storing raster data the internal GridFS con-vention is used that is specifically designed for stor-ing large amount of binary information linked to thedocument. Again it can be noted that no image oper-ations function directly at database level.

It can be clearly seen that out solutions lacks thespeed and potential of spatial database operations,but has multiple gains. The AEGIS data model canbe easily mapped to the document-based structureof MongoDB, even raster data by using GridFS. Ex-tending the database management system with newdata models and indexing solutions would be farmore complex than building the required infrastruc-ture at system level, so research in these areas canprogress quicker, whereas the results can be adoptedinto database systems in the future.

3.3 Spatio-temporal indexing of geome-tries and metadata

As described in Section 3.1, there are multiple tem-poral aspects treated in the data model.

• Features have limited temporal validity, a timeinterval in which they are considered to bevalid. This interval may be the same for theentire collection, but can be different for eachobject.

• Features may change spatial properties dur-ing their validity. In the case of moving ob-jects, the entire geometry is relocated, but isnot changed. However our model enables anychange in the geometry itself, even a singlepoint may alter within a polygon leaving therest in place.

• Metadata may change within the validity.Metadata keys and values can change indepen-dently from each other and from spatial alter-

ation. The values indentified by the same keybut with different timestamp can be indepen-dent or in relation to each other. For instancethe average travel speed of a road section for agiven timestamp can be expressed as a factor ofthe speed limit.

To support this broad spectrum of temporal man-agement, indexing has been introduced on multi-ple levels. For spatio-temporal indexing 3D/4D R-trees (Kolovson & Stonebraker 1991) and Multiversion3D/4D R-trees (MV3R-trees) are used (Tao & Papa-dias 2001). In both cases, time is the last (third orfourth) dimension. The former is efficient for times-tamp based queries, the letter has good performancein both timestamp and interval queries. Both treeshave spatial and temporal bounding boxes, and usemultiple heuristics to enhance the performance oftree updates. For temporal indexing of metadata,Multiversion B-trees (MVB-trees) are included (Kolov-son & Stonebraker 1991).

Using these structures the following multi-levelindexing solution was implemented, as illustrated inFigure 4).

• Map collections contain MV3R-trees to supportboth interval and timestamp queries.

• Features contain 3D/4D R-trees to access spa-tial properties at the specified timestamp.

• Metadata collections of the features use MVB-tree to query values at the specified timestamp.

Figure 4: The multi-level indexing solution.

In certain situations some features can belongto multiple collections, and have different temporalproperties in these collections. For example, a roadsection can belong to a collection containing dailytraffic information (where average travel speeds arecalculated for every hour), and also to a collectionwith yearly traffic information (where average travel

OSGEO Journal Volume 13 Page 73 of 114

AEGIS

speeds are calculated for every day). Different meta-data values are need to be calculated in the two col-lections. In the simplest solution this would requirethe duplication of the feature.

To prevent this duplication, additional B+-treeshave been included in collections and graphs. Thiscan be seen in Figure 5. The solution is specificallydesigned for situations where relations can be estab-lished between the altering metadata. The tree con-tains timestamps as keys, and for each timestamp,a collection of temporal variables. These variablescontain descriptive information that changes in time,and is not stored in the feature. Variables are formedby (key, modificiation, usage) triplets. These tripletsdefine metadata variability for any descriptive valueof the geometry. Key refers to property name, usagedefines application of the modification, such as over-ride, add, multiply, etc.

For instance, the speed limit may be stored asmetadata in the feature, whilst the tree contains theaverage travel speed for a given hour as a factor ofthe speed limit.

Figure 5: The MV3R-tree extended with B+-trees.

When querying the speed for a certain times-tamp, the speed limit is multiplied by the factor pro-viding the temporal variability.

The metadata variability is only reachablethrough the collection, and different collections pro-vide different alterations of the metadata values.However this solution is only effective when theamount of changes and therefore the space requiredby the B+-trees is less than the space required for thefeature duplication. Since collections may containother collections, this effectiveness can be raised bygrouping features into inner collections, where thevalue change factors are the same.

3.4 Revision control of data

Revision control is an essential part of modern ap-plication development. Hence it is also usable inany field where the modifications of documents

are needed to be tracked. In this regard spatio-temporal features may be considered as documentswhere editing operation cause changes in either spa-tial, temporal or metadata properties of the feature.In vector representation editing operations are re-stricted on spatial and temporal geometry propertiesbut in raster representation they may also be changesinvolving pixel data. Only a handful of studies dealwith revision control of images. Modern revisioncontrol solutions offer only limited possibilities formanaging binary data.

Our solution, based on Chen et al. (2011), is in-tegrated as a part of the framework. The core ideais the storage of image operations using a directedacyclic graph (DAG) where each vertex contains aperformed editing operation. This representation issuitable for nonlinear revision control and does notrequire the storing of the entire modified image.

In the AEGIS system, all editing operations ongeometries are executed as either vector based mod-ifications (including all raster image changes) or assimple variable changes (such as metadata modifica-tion). Therefore it is fully compliant with the graphbased storage. The method is also applicable for edit-ing vector features. However in our system a graphis maintained for the entire editing lifetime of a fea-ture, not just between two revisions. Therefore allprevious revisions are obtainable and the frameworkonly needs to store the original raster and the headrevision of each branch (if needed). Revisions mayalso be tagged. A tagged revision stores the entiregeometry, so it can be retrieved without any need ofreapplying editing operations.

The revision control process is fully automatedand reacts to all changes signaled by the feature thatreach the Application level.

4 Flexible data processing

Data processing, algorithmic capabilities and sup-ported import/export formats are the key questionsin most applications and services. Not only the num-ber and purpose of processing algorithms should betaken into account but also their performance is cru-cial. All these aspects were taken into account duringthe design of AEGIS with the inclusion of dynamicextendibility and GPGPU based distributed execu-tion.

Dynamic extension is supported by using reflec-tion capabilities of the .NET framework and the metadescriptor service, that is used by the Processingand IO packages. Algorithms may be implemented

OSGEO Journal Volume 13 Page 74 of 114

AEGIS

in any .NET language using the AEGIS API, whichoffers many base classes for file or remote serviceaccess and algorithm description. These compiledclass libraries can be simply added to the system dic-tionaries to be automatically recognized and usablethrough UI commands and the scripting engine.

The scripting engine offers an easy to learn highlevel procedural language, currently named AEGIS-cript. It is possible to create batch scripts on anyimport/export and geometry processing operation;to combine simple algorithms to form composite,reusable operations and to execute algorithms se-quentially and in parallel.

The efficient execution of processing algorithmsis another issue. It is widely known that interme-diate language programs executing on virtual ma-chines cannot match the speed of native applications.Relying strictly on .NET code in algorithm executionwould result to poor performance. Hence algorithmscan be written as expressions, which are dynamicallycompiled and transformed to either .NET intermedi-ate language (IL) or OpenCL language codes. In thelatter both CPU and GPU based executions are sup-ported to enhance processing speeds. Thus the pro-grammer may write the algorithm in simple .NETcode, which can be executed as low level code onparallel GPGPU architecture. The complete structureof the processing environment can be seen in Figure6.

Figure 6: Control flow of the processing services.

This compilation is performed by the processingengine. The solution is effective in handling of large

raster and vector data. However input data mustbe first converted to the specified simple format ofthe execution environment (e.g., simple one dimen-sional arrays for OpenCL) and back after the oper-ation. The transformation is automated, but can betime-consuming. After transformation, algorithmscan work either in place or out place on the data (asdefined by the meta descriptor of the process).

The processing engine is also extendible withnew execution environments including other GPUbased models (such as CUDA) or other platforms(e.g., database system). It must be noted that in thecurrent phase of development not all processing op-erations are supported by the transformation engine,these are executed as standard .NET code.

5 Applications

The first application, based on AEGIS architecture, isa simplified agent-based suburban traffic simulation.The simulation calculates and displays traffic infor-mation, mainly congestion levels for every time ofthe day within a year. The main goal of the applica-tion is the testing of the implemented indexing solu-tions with vector data. The application has been de-veloped using the Core, Core.Temporal and IO pack-ages of the AEGIS stack; separate operations and dis-play environment are built on top.

The second application is a segment based clas-sification library for remote sensing images. The al-gorithms have been previously implemented in bothC++ and C#. Hence, the goal of the application isthe comparision of performance and efficiency of theProcessing component and the OpenCL transforma-tion.

Both applications are under development, there-fore results are preliminary. Definitive results will bepublished in the future.

5.1 Agent based traffic simulation

In this simulation a number of independent agentsdrive on the road nework during the day. The agentshave multiple destination addresses to drive to. Twomain destinations are workplace and home; but mul-tiple random targets (like shopping centers or restau-rants) may also occur. Agents travel to all locationsby car. Locations are built up using metadata ofbuilding objects in the city map. Agents presentin this simulation are primitive; they use simpledistribution-based algorithms to make decisions. Forexample, an agent may have a working time from 8

OSGEO Journal Volume 13 Page 75 of 114

AEGIS

o’clock in the morning to 6 in the afternoon, and cango to multiple stores or other locations after work.

Figure 7 illustrates the visualization of the trafficsimulation on the map of Budapest, Hungary. In Fig-ure 7a agents traveling to destination are shown inred, agents travelling home in green. Figure 7b dis-plays the traffic congestion levels (yellow for smallcongestion, red for large congestion) for 9:00 AM ofa specified day.

Figure 7: Visualization of the agent based traffic sim-ulation: (a) Running agents; (b) Traffic congestionlevels.

Agents plan their routes using A*-algorithm work-ing on the GeometryGraph representation of the roadnetwork. Routing algorithm calculates the jour-ney based on road travel time, which is availableas metadata. The calculation is performed before-hand, based on historical traffic information com-bined from yearly and daily data including the lastresults prior to calculation. During travel the actual

driving speeds are calculated based on the numberof agents and the loadability of the road section. Thetraffic data is recalculated every 15 minutes. Due totraffic jams occuring, the agents speed can becometoo low or the travel time can become too high caus-ing the agent to perform one of multiple actions,including recalculation of the entire route avoidingnearby road sections, recalculation of partial route,or even altering the destination address.

To manage the traffic data, only a single copy ofevery road section is used for all calculations by mul-tiple graphs in combination with B+-trees for meta-data variability storage. This solution can be seen inFigure 8. Data is summarized and optimized (includ-ing rebuilding of B+-trees) after each day. Measure-ments show that although optimization of the col-lections is quite time consuming, the query of val-ues is only 15-20% less efficient than using multipleinstances of the road sections, causing 5-8% perfor-mance loss of the entire simulation, with the benefitof using only 55-60% of storage space compared tomultiple instances.

Figure 8: Temporal metadata indexing used by thetraffic simulation.

The application also served for inspecting the ef-ficiency of the MV3R-tree by blocking road sectionsand so limiting their temporal validity, but no signif-icant performance differences were measured in caseof acceptable amount of changes.

5.2 Segment based image classification

To achieve the proper detection of features in map-ping, image objects, that fit land cover objects, areneeded to be delineated and they must be classi-fied into predefined classes. However, traditionalpixel-based classification methods completely disre-gard spatial relations.

In recent years, scientists of ELTE and F ÖMIhave been jointly investigating efficient segmenta-tion methods of remote sensing images. Up to nowthe implementation and investigation of several al-

OSGEO Journal Volume 13 Page 76 of 114

AEGIS

gorithms have taken place, including the analysisof parameterization and accuracy (Dezso, Giachetta,László & Fekete 2012).

For testing and comparison purposes, severaldedicated applications and libraries have been devel-oped and some open-source and proprietary prod-ucts have been used including eCognition (Dezso,Giachetta, László & Fekete 2012). However thesesolutions lack of flexibility and customization pos-sibilities which are needed for accurate results. Asa result implementation of several segmentationmethods and segmentation based classification algo-rithms have begun recently in the AEGIS framework.

These approaches include both merge-based andcut-based methods, namely sequential linking, bestmerge and minimum mean cut. All algorithms workon the graph form of the image, represented bythe RasterGraph class, that can store either pixelor segment information in vertices. These graphsare easily convertible to arrays that can be handledby OpenCL. By defining the steps of the algorithmthrough expressions, the entire process can run onGPU after the transformation of the graph with thesame results as in previous implementations.

Initial results are promising regarding executiontime. Using OpenCL based processing, the perfor-mance increase is up to 70-75% compared to stan-dard .NET implementation and 30-40% compared toprevious C++ implementation. However, further in-vestigation and optimization will take place beforetrustworthy results can be presented.

6 Conclusion and future work

In the previous sections the concept of the AEGISspatio-temporal framework and the goals of the au-thors’ research have been introduced. Although de-velopment is still in early stage and several aims arestill in planning phase, some results have alreadybeen reached.

The system is based on the spatio-temporal datamodel as described in Section 3, which uses complexdata structures and multi-level indexing with tempo-ral variability to enable more efficient managementof data. Processing services allow flexible exten-sions and dynamic transformation of algorithms toGPGPU execution for improved performance. Pro-cessing capabilities are extended by the inclusion ofbatch scripting.

Further research includes the testing of other in-dexing structures and representation possibilities,and their performance measurement using more ap-

plications; the enhancement of algorithm transfor-mation for wider support on different operationtypes and the implementation of higher levels in theAEGIS infrastructure, namely UI, Communicationand Services.

ReferencesAbraham, T. & Roddick, J. F. (1999), ‘Survey of Spatio-Temporal

Databases’, GeoInformatica 3(1), 61–99.

Chen, H.-T., Wei, L.-Y. & Chang, C.-F. (2011), ‘Nonlinear revisioncontrol for images’, ACM Trans. Graph. 30(4), 105:1–105:10.

Cooper, P., ed. (2010), The OpenGIS Abstract Specification -Topic 2:Spatial referencing by coordinates, version 4.0, Open Geospa-tial Consortium.

Dezso, B., Fekete, I., Gera, D. A., Giachetta, R. & Laszló, I. (2012),‘Object-based image analysis in remote sensing applica-tions using various segmentation techniques’, Annales Uni-versitatis Scientiarum Budapestinensis de Rolando Eotvos Nom-inatae Sectio Computatorica 37, 103–120.

Dezso, B., Giachetta, R., László, I. & Fekete, I. (2012), Experi-mental study on graph-based image segmentation meth-ods in the classification of satellite images, in R. Vaughan,ed., ‘EARSel eProceedings’, Vol. 11, pp. 12–24.

Giachetta, R., László, I. & Bálint, C. L. (2012), Towards the newopen source GIS platform AEGIS, in A. Degbelo, J. Brink, C.Stasch, M. Chipofya, T. Gerkensmeyer, M. I. Humayun, J.Wang, K. Broelemann, D. Wang, M. Eppe & J. H. Lee, eds,‘GI Zeitgeist 2012 -Proceedings of the Young ResearchersForum on Geographic Information Science’, Heidelberg:Akademische Verlagsanstalt, pp. 11–22.

Herring, J. R., ed. (2011), OpenGIS Implementation Standard forGeographic Information: Simple Feature Access -Common Ar-chitecture, version 1.2.1, Open Geospatial Consortium. URL:http://www.opengeospatial.org/standards/sfa

ISO 19108:2002 Geographic information – Temporal schema(2002), International Organization for Standardization,Geneva, Switzerland. URL: http://www.isotc211.org/Outreach/ISO_TC_211_StandardsGuide.pdf

Kolovson, C. P. & Stonebraker, M. (1991), ‘Segment indexes: dy-namic indexing techniques for multi-dimensional intervaldata’, SIGMOD Rec. 20(2), 138–147.

Máriás, Z., Nikovits, T., Takács, T. & Giachetta, R. (2012), ‘Astudy of storing large amount of inhomogeneous data inworkflow management systems’, Annales Universitatis Sci-entiarum Budapestinensis de Rolando Eotvos Nominatae SectioComputatorica 37, 275–292.

Nguyen-Dinh, L.-V., Aref, W. G. & Mokbel, M. F. (2010), ‘Spatio-Temporal Access Methods: Part 2 (2003 -2010)’, IEEE DataEng. Bull. 33(2), 46–55.

Padhy, R. P., Patra, M. R. & Satapathy, S. C. (2011), ‘RDBMS toNoSQL: Reviewing Some Next-Generation Non-RelationalDatabase’s’, International Journal of Advanced EngineeringSciences and Technology 11(1), 15–30.

Tao, Y. & Papadias, D. (2001), MV3R-Tree: A Spatio-TemporalAccess Method for Timestamp and Interval Queries, in‘Proceedings of the 27th International Conference on VeryLarge Data Bases’, VLDB ’01, Morgan Kaufmann Publish-ers Inc., San Francisco, CA, USA, pp. 431–440.

OSGEO Journal Volume 13 Page 77 of 114