A Web Service for Managing Spatial Context Dedicated to Serious Games on and for Smartphones Elodie

The GeoEduc3D project aims to provide educational games for smartphones based on Geomatics and use augmented reality techniques in order to make these games more immersive. To improve the immersive and interactive aspects of those games, we focused on the exploitation of spatial context in this particular application framework (serious games, augmented reality, smart phones, and multi-users environment). Our work has thus led to the design of a solution dedicated to the management of spatial context in a multi-players environment on and for smartphones. Several contributions have been made: modeling spatial context, proposing a service-oriented architecture to manage this context, defining a Web Service Spatial Context (WSCS) and implementation of a WSCS prototype and a mobile client according to an environment exploiting FourSquare, a geo-social application.


Introduction
In recent years, technological advances have caused a growing interest in mobile solutions among educational games designers.The mobile platforms, especially smartphones, technical and technological characteristics are becoming more mature, and the deployment of mobile and interactive games on such platforms is now possible and increasingly accessible.The GeoEduc3D project, funded by the Network of Centres of Excellence GEOIDE, which our work is part of, aims to take advantage of these advances to offer interactive games whose primary goal would be to present the young audience with climate change issues and sustainable development in an entertaining form.To do so, we would rely on geospatial technologies and augmented reality techniques to design and implement a set of innovative learning tools that would enriched-"augment"-the player's experience by making the game more immersive, reactive and interactive.Note that these games have an educational vocation (serious games) and they are intended for platforms like smartphones, in a multiuser environment where multiple players can interact to accomplish the proposed activities in the game, while moving in a real environment.
The GeoEduc3D 1 project is therefore a privileged and unique application framework where interactions are multiple and of various kinds such as: interactions between the player and augmented reality objects, interactions between the players themselves, and interactions between the player and the game in general.In regards to these interactions, several questions remain, among others:  How to know when the player is in the correct location relative to an augmented reality (AR) object that allows him to see the object from a particular viewpoint? How to show other players' location to the player in the game, or who they are (opponents or teammates) taking into account the real time aspect?
These first questions open doors to several other questions related to smart phones, gaming and player's profiles that will help qualify or define the interactivity of the serious games to be designed in the GeoEduc3D project.Finally, all these questions and information could form the knowledge base on the ambient environment related to the player's location.This knowledge base could perfectly be comparable to the real time spatial context of a player that a game application must be able to acquire in order to exploit it in a smart way.
During the previous decade, context-aware applications and systems have been explored in the computer world [1][2][3][4][5][6].The possibility of exploiting the actual dynamic context of the user in order to offer him services and contents totally adapted to his needs in real time has taken a great interest in a large number of areas such as tourism or health [5][6][7][8].Recently, many efforts have been made to define platforms able to effectively support the acquisition and dissemination of context.However, the provided solutions donot allow the spatial context management in a multi-player environment as wanted by the games set in the GeoEduc3D project.The proposed context models [9][10][11][12][13][14][15][16][17][18][19][20][21] are not applicable to serious interactive games with use of smartphones in a multi-player environment.In addition, there is no remote and interoperable system for data exchange between mobile platforms (sensors and client applications) in such an environment.This raises a fundamental question: how to make available the spatial context data to any application, anywhere, anytime, taking into account the augmented reality, educational game, mobility and multi-players aspects proper to our specific applicative framework?
To answer this crucial question, we have set as general objective of our work "the design and implementation of a solution dedicated to the acquisition and dissemination of spatial context in a multi-player educational game environment on and for smartphones".
To achieve our goal, we chose to move towards service-oriented architectures (SOA) and web services in particular, which allow us to make available data and/or information in an independent and distributed way through a simple query language,.
Therefore our research focused on three specific sub-objectives, which are:  The definition and modeling of spatial context (AR, mobile, games);  The development of an architecture for managing spatial context;  The design and implementation of a web spatial context service prototype taking into account the specific aspects of the project.
In the rest of this article, general definitions of context and spatial context notions are presented (Section 2), together with the spatial context model that we have adopted and adapted to our needs with respect to our application framework.Then, Section 3 will show the technical features identified for taking charge of the acquisition and dissemination of context by the oriented service followed by the system architecture and its operation.A design of a Web Spatial Context Service (WSCS) is then suggested in Section 4, where the service contract and the proposed data exchange formalism will be presented.In Section 5, we describe a game test scenario called EcoSquare, based on the Foursquare API2 that will allow us to test and validate our web service in real gaming conditions.A description of the implementa-tion environment and the testing and results obtained by putting into action our client and our WSCS will be given.We conclude this article (Section 6) by presenting the contributions and limitations of our current solution and our future work.

Spatial Context Model
In this section, we first suggest a review of context and spatial context notions, and then we present a spatial context model related to our application framework.This context modeling [22] was conducted in order to facilitate the design of a data structure for our web spatial context service and for contextual information exchange.This design is based on a categorization of all relevant information to the application framework and according to the definition adopted for the spatial context.

Context and Spatial Context Definition
Among the context definitions proposed in the literature [21,[23][24][25][26][27][28][29][30][31], the most used and relevant definition is the one proposed by Dey [32].According to him, the context is "any information that can be used to characterize the situation of an entity, an entity may be a person, place or object that is considered relevant in the interaction between an user and an application (both included)".Here, a "place" indicates geographies such as rooms, offices, buildings and streets; a "person" can be an individual or a group of individuals spatially gathered or spread; an "object" indicates either a physical object or a software component.
As presented in the introduction, our interest is on all the information that can characterize the gamers (person) with their smartphones (object) and the geographical area (place) in which they are moving and interacting with each other or with augmented reality objects.Then the context must be identified, not only for each entity (gamer + smartphone + geographic area) but also for the whole ensemble composed by all the gamers and their interactions in this multi-gamer environment.
In the literature, various studies exploit the user location aspect as an element or subset of context .However, this notion is more relevant in the geographical context concept proposed by [34].According to the author, the spatial context, which is not a simple current location, has all the information, geographical or not, distributed to static, dynamic and internal contexts.The static context corresponds to all stored geographical information that can affect the user's environment.Meanwhile, the dynamic context consists of any information, on the changeable aspects of the user's environment, obtained through real time sensors.Finally, the internal context includes information on the user and his preferences, location, speed and direction.
In our case, to meet the needs of our application framework, we propose a new definition based on the geographical context [22]: "The spatial context is identified by any information, spatial or related, characterizing the static, dynamic or internal context of an entity which can be a person, place or object considered relevant in the interaction between an user and an application, both included".Thus, in our application framework, the static context is fed by stored information (AR POI-Points of Interest, buildings, roads, etc.), the dynamic context by physical sensors (hardware as GPS, accelerometer, touch sensors, etc.) and logical (data derived from other types of sensors) and the internal context by virtual sensors (data from application or process: calendar entries, emails, form profile entries, etc.).We adopted this definition for the continuation of our work, especially for the spatial context modeling we will discover in the next section.

Spatial Context Modeling
One of our objectives is to propose a specific spatial context model tailored to the particularities (mobility, games, multiplayer, AR) of our application framework.This model should allow the identification of spatial context information in view of their exploitation to make gaming applications aware of the gamer's context, whatever the game, the mobile platform and the playing area.The existing models in the literature [9,10,13] are primarily adapted to the application framework in which they were designed.So none of them is usable as suchin our work.Based on our definition of spatial context, we developed a descriptive model of spatial context in eight (8) categories, with subcategories, including all background information related to our multi-player environment: Runtime environment, Player, Location, Game, Environment, Device, Network and Social [22].This model is presented in the following table (Table 1).
According to this table, several contextual data are categorized by properties, which may be included in subcategories.For example, for the category Player, we can find contextual data such as player's role or status in the game (subcategory Game aspect), his name or gender (sub-category Profile), or his study level (sub-category Education aspect).Another example is the Location category where one piece of information such as a player's punctual location or direction, the general location (city, country, etc.) or Points of Interest (POI) for the AR can be found under different subcategories.Finally, for the Mobile Device category, we can find the device capacities (battery level, storage memory) and functionalities (GPS, connectivity) within two distinct subcategories.
Such a model is flexible because it is always possible

Web Spatial Context Service Design (WSCS)
This section exclusively focuses on the design of the web spatial context service, which corresponds to our main goal and our application framework.We begin by presenting a functional analysis of the system to be implemented and thereafter, we propose an architecture that corresponds to our expectations, along with explanations on how it works.

Functional Analysis of the System
To manage contextual information, our solution must have main features, which are specific to the manipulation of contextual data.These features were defined after studying the existing [21,31,35] and according to the needs of our system.In the introduction we mentioned three important issues that have fuelled our thinking about the solution to offer.A return on these issues allows us to describe here the needs that our system should respond to.Indeed, to exploit the spatial context in our application framework by taking into account the multi-player environment, we mainly need: 1) to retrieve the contextual data, 2) to store them somewhere, and finally, 3) to share them among different platforms in real time.The features identified to specifically meet these needs are: 1) Contextual data acquisition: The data acquisition is to allow people to add, create, delete and update the contextual data, regardless of their origin, in the web spatial context service.In general, the acquisition of contextual data is essential for data knowledge and exchange (location, player profile, social, etc.) between the different game platforms.It is a mandatory passage for the context awareness (need 1) and an adaptation of the game application to actual spatial context of each player in this multi-player environment.How to retrieve information from the sensors (logical, physical and virtual) and how to understand them or make them understandable for any application are the questions we will ask ourselves in our later work.For example, if we want to display on a map the locations of all the players of a team as well as the locations of other players of an opposing team in a defined area, we need to have this location information for all players.Since we are in a multi-player environment, this information cannot be shared just between two players being at a certain distance from one another.It then becomes necessary to retrieve this information from any smartphone released into the game environment.This information should be accessible and regularly updated as the players move in real time in the playing area.
2) Contextual data storage: You cannot talk about data acquisition without mentioning the storage of such data.Indeed, we are now faced with a very large set of multi-source and multi-scale data that must be centralized (need 2) in the same structure to make them searchable at any time.It is therefore necessary to have a model of spatial context data storage.
3) Contextual data retrieval: The contextual data retrieval is to provide access to stored data for all mobile platforms.They must be able to request (need 3) all or part of contextual data to enable real time adaptation of the client application to the spatial context of the players.The main question arises: by what means (tools, query language, data format), the information could be accessed from any platform, anytime and at any time?The suggested solution must effectively address this question.
4) Query by spatial filters on the data: One of the most productive ways to recover data with a spatial dimension is to apply spatial filters.For example, it can be used to find the set of POI located at a distance "d" of a player, or to know the list of all the opponents located at a distance "d" of a player.Another example of use would be to retrieve all buildings located within a geographical area bounded by a known envelope.
5) Query by scalar filters on the data: These are expressions using logic comparators applied to attribute values to sort the data in order to target the desired responses to a query made on contextual data.These filters are useful, for example, if we were to recover the profiles of the player X and the player Y or the locations of the players whose age is between 10 and 15 years.It would be wise to have the opportunity to apply such filters on contextual data.This feature and the previous one complement the functionality 3 according to the need 3.
The identification and description of the desired functionalities of our system allow us to proceed with the design of an architecture supporting the establishment and operation of the appropriate application modules.We have focused our global solution to a service-oriented architecture with, as a central element, a web service of spatial context.This proposal has the advantage of providing acquisitions, distribution, and filters on contextual data operators, to and from all mobile platforms involved in an interoperable environment.

Architecture and Operation
The main objective of our work is to offer a software solution able to handle the spatial context (AR, Mobile, Games) in a multi-player environment.This management takes into account the acquisition (feature 1), storage (feature 2) and querying (features 3, 4 and 5) of contextual data.Since we are dealing with a multi-player environment with various mobile platforms and contexts, the textual data exchange format.best approach to achieve our goal would be to implement a service-oriented architecture.This architecture can retrieve the context information scattered in the environment, centralize and distribute them to all gaming applications and services that need it (on request).Adopting such architecture would promote interoperability among mobile platforms and applications involved, independence of the latter regarding the context sensors access layer and an improved efficiency of the context provider due to the ability to make asynchronous invocations.

Service Contract
In this section we provide a description of our WSCS service contract, by presenting all the features published by the web service, the data structures, sent in request and response, description, as well as addressing information to join the service described.
We chose to define our WSCS as a "RESTful" service.It is thus invoked via HTTP (Hyper Text Transfer Protocol) by sending GET or POST requests.Each operation is located by a URL (Uniform Resource Locator), which is used to send the appropriate request parameters or queries encoded in the POST body of the document.
Our oriented-service context data management systemaims to acquire and make available context data according to our application framework.These data come from various sensors built into mobile devices or from external sensors like weather stations [36].Thus, they can be shared between different mobile game applications.Figure 1 shows the functional architecture of this system with a web service (WSCS-Web Spatial Context Service) as central element.This WSCS is based on recommendations of the OWS3 specification, which is a reference for the implementation of web services in the geospatial field.
Furthermore, regarding features identified as essential for our solution to meet the needs of the system, and by drawing operations offered by the OGC (Open Geospatial Consortium) spatial features service (WFS), namely Get Capabilities (to retrieve the metadata describing the service and the parameters accepted), Describe Feature Type (to retrieve the structure of each entity available at the server), Get Feature (used to retrieve entities (geometry and/or attributes) in GML), Lock Feature (used to block access to entities during a transaction) and transaction (used to create, update, or delete an entity), we developed a service contract that provides an interface with five (5) operations.

Web Spatial Context Service (WSCS)
According to the suggested architecture and the different features, identified in our functional analysis, we presentin this section a complete description of our web spatial context service through a service contract and a con-These five (5) WSCS operations are:  GetCapabilities Operation: it gives clients information on the identification of the service (version, type, name, title and summary description) as well as on its capacities namely the supported operations and filters.This operation is essential because it allows the client to discover the service and get the necessary elements for its optimal exploitation.Here is an example of a GetCapabilities request: http://localhost:8080/testwscs/wscs? request=GetCapabilities  GetContextFeature Operation: the presence of this operation in our contract is justified by the need 3 (cf.Section 2.3).In order to retrieve previously stored contextual data, it is important to provide clients with an operation that offers them, whatever their location or technical environment, the ability to access them through well-parameterized queries.Following our spatial context model presented in Section 2.2, a given context is characterized by a certain type (or category).To be more specific in the choice of the terms used relatively to the WSCS implementation, we denote by the term "element" a contextual data (e.g.latitude, longitude, address) in the following of this paper.Moreover all the contextual elements provided as results are objects ("feature").Thus, this operation takes as input the name of the request (Request), the desired output format (Output Format), the name of the contextual data type (Type Name), the names of desired elements (Element Names), with the latitude/longitude of a point for defining buffer zones (Coords), the maximum number of features expected (max Features), the level of depth that is desired for the returned data (Level) and finally the definition of the filter we want to apply to the data (Filter).It returns the information requested in the mentioned format (by default JSON).The encodings are described in Section 4.1.2with supporting examples.It supports navigation through a hierarchy of elements (in order to obtainthe elements of a level, or children of an element) and spatial or scalar filter operations through the Filter parameter that receives the expression of a Filter Encoding (OGC standard).This option allows us to meet needs 4 and 5 (Section 2.3).
Here 3) relative to data acquisition and storage.This operation needs as input the transaction to do, that is to say, inserts, updates or suppressions (Transaction), the identifiers of locked objects (lock ID) and how locked features are processed after a transaction is completed.
In the next section, we suggest an encoding for the response returned by the client service, by using the example of the GetContextFeature operator.

Response Encoding
Our web service is designed to acquire and disseminate context elements on smartphones and for mobile clients.One existing description approach for this data type is to represent them by attribute-value pairs [36].We choose this approach because it has the advantage, among others, to offer a partial support of semantics (contained in the attribute).According to this technique, the context of a gamer would be a set of attribute-value pairs at any given time.Thus, when the client sends a GetContextFeature request to the service, he receives in return a set of attributes-values organized in category or context type.The user can also choose to have a representation of the response (or format) in JSON or XML.In general, the elements in the structure of the response are:  A root element, feature collection: a collection of contextfeatures. One or more features, contextfeature: a context entity of a certain type or category (location, player etc.), composed by the context elements requested. An identifier ID to identify a contextfeature. The type: each contextfeature type (category) appears in the answer. One or more contextelements contain all the elements, which compose a context contextfeature.These contextual elements are then expressed as attribute-value.Table 2 provides an example of responses according to a JSON or XML format.
In order to have a generic format, the elements must be described as attribute-value pairs.Whatever the provided data, their origin or feature relatively to the application framework, the returned format is still valid.Moreover, with such writing, you can include the entire context elements presented in our model (or added in the categories or subcategories if needed).

Prototyping
In order to test our web spatial context service and to show its feasibility and validity, we developed a prototype that implements the service contract presented in Section 4. As already stated on the architecture of our system, this web service is part of a service-oriented architecture where we have, on one hand, client applications that consume our service and, on the other hand, resources (services or databases) where the service stores and queries context data (see Figure 2).To demonstrate
Not implementing the contextual data acquisition feature in our prototype involves having a real data set tailored to the needs related to our GeoEduc3D project.This data set must take into account context aspects related to the categories we have previously defined (see Section 2.2).For this, we chose to exploit the Four-Square4 application, which offers many of these following aspects: mobility, location, game, social, player.This application has been very popular for the last years, since it provides access, through an API, to a large number of geospatial (or not) data created over months by citizens via the adding of visited venues through the mobile application.This application provides a RESTful interface presenting methods to access resources such as venues or users at defined URLs.
To retrieve information, the client simply sends a simple HTTP GET or POST request to the API, and responses are returned in JSON or JSONP format.To ensure the safety of this important volume of data, Four-Square API only allows access via OAuth 2.05 authentication standard.This choice implies that all requests must be secured by HTTPS.In addition to the access to these data, we also developed a database based on the structure of our spatial context model presented in Section 2.2.This database is populated by simulated data combined in part with data provided by FourSquare.
In the following section, we will explain the adopted game scenario, in order to facilitate understanding of the tests data and examples of submitted requests and their answers.

Game Scenario: EcoSquare
The suggested scenario was primarily designed to allow the validation of our spatial context model and our web spatial context service (WSCS).It fits in the expectations and objectives of the GeoEduc3D project with serious games, mobile devices, augmented reality and the environmental theme.We named the game EcoSquare.This game addresses a public of teenagers aged 12 to 18.As suggested by its name, it is based on the FourSquare application and applies some ecology concepts.To briefly describe the game, each player has the opportunity to visit a building, evaluate it, leave a comment or tip (eco-tip) and/or send a photo taken on site using his  smartphone.As all players can see all this information, we have a community of players who share their appreciations of the visited venues, while learning about a geographic area.Moreover, the ecological aspect concerns the provision of an assessment tool based on criteria to be met by buildings in order to be declared ecofriendly: cleanliness, accessibility, energy, heating, indoor air, recycling or green actions.These criteria are extracted from France's Housing and Environment (H & E 6 ) certifications and North America's LEED7 (Leadership in Energy and Environmental Design).Table 3 presents the actors, used cases and keywords associated with our game.In short, players are grouped in teams of two or more people.Each player belongs to one team at a time and he may be the team captain or an "Écobrigadier".The teams' main goal is to occupy the highest number of "Écolieux" to lead the overall standings of the teams.

Player
Game application user "Écobrigadier" A player, simple member of a team

Captain
The team creator and chief Actors "Écolieux" enemies that the player can occupy with just one more check in In addition, to further exploit the spatial dimension, the player can make use of filters, from the "ÉcoChamp" map (see Figure 3, right image), on the "Écolieux" he occupies, the opponents' "Écolieux", or his team's "écolieux".

Implementation Environment
According to our system architecture defined in Section 3.2, different technological choices have been made in relation with development frameworks, libraries for programming and deploying web services, web mobile application development, and the creation and manipulation of XML documents and JSON objects.In addition to the main features presented by the tools, we also privileged the open source and "freeware" as selection criteria, because it offers, among other things, characteristics of flexibility and accessibility.
For each tier (client, server, resources) of our architecture, we will see the tools used, explaining how and why they were chosen and what they have allowed us to implement.Results will be detailed later in Section 6 with examples and screenshots of client interfaces.

The Client
To implement our client, we turned to a mobile web application development framework to give us independence from any smartphone native platform.Thus our game application can be deployed on any mobile platform (iOS, Android) without requiring major code changes or any change of programming environment.Moreover, the development framework must meet some criteria: no native language; portability; access to native API via an intermediate access layer; free; web-oriented for non-dependence to a mobile platform and data reading in XML or JSON format.
Today, several tools meet some of these criteria, free or commercial, open source or not.They are mainly based on the combination of HTML5, CSS3 and JavaScript technologies to address the multi-platforms issue: jQTouch8 , Phonegap 9 , Rhomobile Rhodes10 or Sencha Touch 11 .According to our criteria, we chose to use Sencha Touch, one of the most popular free tools, under GNU GPL v3 license.It helps to develop mobile web applications for iPhone, Android and BlackBerry.In addition, Sencha Touch enables rapid development of mobile web applications, with the possibility to request data via AJAX technology or JSONP.
Using this tool, we developed a mobile web version of our game, EcoSquare.The graphical user interface of this mobile application is divided into five tabs, written in French and briefly described in Table 4.
Moreover, the most interesting feature is the tab Eco-Champ that contains a Google Maps map displaying the "Écolieux" retrieved from our WSCS prototype.We also implemented filters on the "Écolieux" (see Figure 2, right image).

The Server
Four basic challenges must be addressed when a web service has to be implemented and deployed: 1) the service description, 2) the service implementation, 3) the publication, discovery and service binding and 4) the invocation and execution of the web service.PHP, NET and J2EE are existing platforms that offer the architectures and standards appropriate to the effective management of these different aspects.The choice of either of these platforms influences not only the complexity level and development time reduction but also the service performance and maintenance.In our case, we preferred to work with J2EE standards since there is a wide choice of development tools, application servers and Java Servlet implementation of open source libraries for XML or JSON, and also of geographic objects manipulation and spatial processing libraries in the Java world.Our implementation is based ultimately on the Java language, the Eclipse Galileo IDE and the open source Apache Tomcat as servlet container.These tools have allowed us to implement a part of our service contract (see Section 4.1.1)with the operator GetContextFeature (for proof of concept) and to query the database server and Four-Square.

Tabs Use Case Usability Me
Management of personal profile of player according to some attributes such as name, picture, last visited buildings, and so on.
Test to obtain information on a specific player from our web service WSCS.

Team
Management of a team.It is useful for a captain in order to create or modify a team, and to add members included in his friends list.
Test to send contextual information about team to our web service WSCS, through transaction operators (LockContextFeature and Transaction).

EcoChamp
Visualization of map about the play area with "Écolieux" elements (occupied, never visited, enemies).Player can choose some "Écolieux" elements to visit by clicking on the appropriated marker.An "eco-trick" or an evaluation can be added.
Test to retrieve close "Écolieux" elements by using filters, through the GetContextFeature operator.

Settings
Game settings.A player can retrieve his contacts from social networks (Facebook or Twitter) and from email accounts (Yahoo or Gmail), delete or modify his account (login and password).
Test to send contextual information about team to our web service WSCS, through transaction operators (LockContextFeature and Transaction).

Plus
All elements that could be necessary to the game, like visualization of team ranking.
Test to obtain information about team scores.
and will allow retrieving them through a query language like SQL.Given that we handle, here, both numerical and spatial data (essentially points), we need to adopt a DBMS that can manage spatial data.Different DBMS are today available on the market to support the geometries' storage: Oracle Spatial, ArcSDE, PostGIS/PostgreSQL being the most popular.Our choice fell on Post-greSQL/PostGIS because it is a powerful and free open source that corresponds to our needs.The database structure entirely respects the elements of the model described in Section 2.2.Through the FourSquare API, the web service has access to data on buildings and parks in the players' surroundings, their profiles, together with a list of their friends who use the FourSquare application and those within their group of friends from Facebook or Twitter, along with their profiles.So we have a database that respects the context model structure with some adjustments on the elements to be stored in order to take into account the external resource that is the FourSquare API.

WSCS and EcoSquare in Action
In this section, we briefly present some of the tests we conducted on the web service prototype and EcoSquare.These tests serve to validate the effectiveness, relevance and feasibility of our solution.
First, the client interface shows tabs including the "EcoChamp" tab, which gives the player a map view of the game area.The player can see his current location as well as all the available "Écolieux" nearby as shown in the left image of Figure 2. By selecting an "Écolieu" from this interface, he may check in and leave comments or ratings.To display this data on the map and get contextual information such as the name of the place, the address, the player occupying the place or the distance between the placeand his own current location, we called our service by using the Get-ContextFeature operator.
To illustrate the use of our web service, we show, through Figure 3, an example of a GET request sent to the WSCS and the response in JSON format.This example demonstrates a strong utility to test the client's accessibility to spatial context information related to "Écolieux" elements to occupy.The following example asks to retrieve the first three contextfeatures of the "Écolieux" type from given coordinates.Here is the request URL: http://localhost:8080/testwscs/wscs?request= getContextFeature&typeName=ecolieux &maxFeatures=3&coords=46.78,-71.27 In Figure 3, we find the complete answer to this query in JSON format.Using the coordinates given as parameters, we are able to retrieve, among others, the "distance" information, which is calculated relatively to "Écolieux" elements.This information is later used to limit the returned data according to a buffer zone.To do this, the  client can use the Filter parameter to restrict the returned data to a certain buffer area of which the player would be the center.For now, by default, we return to the client the 10 "Écolieux" located at a distance of 500 m round.Note that it is the most popular "Écolieux" of the API that emerged as this may help to know quickly where the "enemies" are without having too much data to consult.
The following example shows the use of the GetCon-textFeature request with a Filter on the distance (DWithin).
We retrieve here the 10 "Écolieux" located within 1000 m of radius from the current location of a player (Figure 4).Unlike the previous example, these are not the popular ones but rather all those within the area bounded by the filter.Here the client accesses the data as needed.The URL is: With the distance information relative to the player's location, we applied a test on the data returned, by only keeping those found in the buffer zone requested.We note that actually more "Écolieux" are represented on the screen (Figure 5).When closely looking at the response, one can observe that the distance values are <1000 m.

Conclusions/Perspectives
In this paper, we outlined the proposal of a web service dedicated to the management of spatial context information as part of the GeoEduc3D project.We first made an overview of the context and spatial context notions, as well as of the spatial context model that we developed.Then we have identified the needs related to the application framework together with the functionalities that will meet such needs.These specifications in hand, we developed the architecture of our solution by focusing on the operation of various tiers (client, server, resource).This led us to a new contribution with the definition of our web spatial context service (WSCS) by offering a service contract tailored to our needs and based on the OGC WFS and Filter Encoding specifications, as well as an encoding, for responses returned by the service, in an XML and/or JSON format.Finally, we implemented a prototype of the WSCS and a game application client EcoSquare that help show the feasibility of our approach, as well as its usefulness.Thus, with our contributions, we believe it is now possible to make available the spatial context to client gaming applications in multi-player environments.Our solution has the advantage of being interoperable, flexible and independent of the client application and its features in terms of contextual data.The service contract is defined once, and its operators allow us to cover the needs of the system.A full operational implementation of this WSCS and real tests still need to be done, along with questionnaires to potential consumers of the context model to improve and validate our proposals.
To go further with our spatial context management solution (AR, Games, Mobile), it would be wise to build an ontology standard that would have the advantage of allowing the development of processes and intelligent aggregations with the data returned by the WSCS.Such ontology would probably lead to the replacement of the encoding with the name value pairs by encoding with a model based on ontology (OWL-Web Ontology Language and RDF-Resource Description Framework).

Figure 3 .
Figure 3. Example of a GetContextFeature request execution.

Figure 5 .
Figure 5. EcoSquare with an exploitation of the response to the GetContextFeature with Filter.

Table 1 . Spatial context descriptive model [22]. Categories Sub-categories Properties
to represent a new subcategory and/or contextual data.Moreover, this descriptive model is indispensable to design a contextual data structure associated with our WSCS, and also for the search of contextual data and the definition of spatial context acquisition and dissemination operators.