+ All Categories
Home > Documents > Paper Title (use style: paper title) - users.dcc.uchile.clnbaloian/alex/CSCWDFrezFormato.docx  ·...

Paper Title (use style: paper title) - users.dcc.uchile.clnbaloian/alex/CSCWDFrezFormato.docx  ·...

Date post: 12-May-2019
Category:
Upload: dinhque
View: 215 times
Download: 0 times
Share this document with a friend
14
A Conceptual Model to Design Partially Virtual Communities Jonathan Frez Universidad Diego Portales Santiago, Chile Nelson Baloian Computer Science Department Universidad de Chile Santiago, Chile [email protected] Gustavo Zurita Management Control and Information Systems Department Universidad de Chile Santiago, Chile [email protected] AbstractSystems which include the collaborative georeferenciation of data and information as one of the fundamental activities are increasingly being used as support for various purposes like urban planning, risk management, geological prospection, etc. Consequently, they are being used by various user types like engineers, policemen, firefighters, geologists and architects. In general, these systems implement processes and functionalities supporting decision making as well as design and planning for various purposes. The various visualization metaphors which can be applied to data and information which is georeferenced on an interactive map allow their users to perform tasks and activities in an intuitive and efficient way. In order to help people designing and implementing this kind of applications we developed a platform implementing a core of common functionalities geocollaborative application share, supporting collaborative work over a shared workspace displaying a map. The application developer using this platform has to develop the needed elements which should be placed over the map in order to instantiate a particular application. These elements can be simple graphic labels up to complex agents implementing some behavior, generating data for a simulation and interacting with the user and other agents on the map. The paper describes this architecture and three examples of using it for the development of applications in field of 1) wireless network planning, 2) real time spatial data analysis, and 3) satellite image processing. Since planners must often work on the field the architecture allows the development of applications for using them in desktop as well as mobile computers. Keywords: geocollaboration and design, urban e- planning, mobile computing. I. INTRODUCTION The world population is growing faster, and cities vital services such as transportation, healthcare, police, and public safety are being stressed. Administrating cities’ vital services require processing a significant amount of data and information very often associated to specific geographic locations. In order to provide the necessary technology that generates the required data, cities have organized themselves in various subsystems [1]. Cooperation is also needed between various institutional entities in order to make decisions on designing solutions about the use of limited resources in the event of exceptional conditions. In order to manage the necessary resources to cope with events like heavy rain, fires, traffic accidents or people requesting assistance, a cross-domain collaboration among various entities providing vital services for a city, like police, ambulance, firefighters, etc. is needed. They have to make coordinated decisions on the basis of available data about where are the resources geographically located and
Transcript

A Conceptual Model to Design Partially Virtual Communities

Jonathan Frez

Universidad Diego Portales

Santiago, Chile

Nelson BaloianComputer Science Department

Universidad de ChileSantiago, Chile

[email protected]

Gustavo ZuritaManagement Control and

Information Systems DepartmentUniversidad de Chile

Santiago, [email protected]

Abstract— Systems which include the collaborative georeferenciation of data and information as one of the fundamental activities are increasingly being used as support for various purposes like urban planning, risk management, geological prospection, etc. Consequently, they are being used by various user types like engineers, policemen, firefighters, geologists and architects. In general, these systems implement processes and functionalities supporting decision making as well as design and planning for various purposes. The various visualization metaphors which can be applied to data and information which is georeferenced on an interactive map allow their users to perform tasks and activities in an intuitive and efficient way. In order to help people designing and implementing this kind of applications we developed a platform implementing a core of common functionalities geocollaborative application share, supporting collaborative work over a shared workspace displaying a map. The application developer using this platform has to develop the needed elements which should be placed over the map in order to instantiate a particular application. These elements can be simple graphic labels up to complex agents implementing some behavior, generating data for a simulation and interacting with the user and other agents on the map. The paper describes this architecture and three examples of using it for the development of applications in field of 1) wireless network planning, 2) real time spatial data analysis, and 3) satellite image processing. Since planners must often work on the field the architecture allows the development of applications for using them in desktop as well as mobile computers.

Keywords: geocollaboration and design, urban e-planning, mobile computing.

I. INTRODUCTION

The world population is growing faster, and cities vital services such as transportation, healthcare, police, and public safety are being stressed. Administrating cities’ vital services require processing a significant amount of data and information very often associated to specific geographic locations. In order to provide the necessary technology that generates the required data, cities have organized themselves in various subsystems [1]. Cooperation is also needed between various institutional entities in order to make decisions on designing solutions about the use of limited resources in the event of exceptional conditions.

In order to manage the necessary resources to cope with events like heavy rain, fires, traffic accidents or people

requesting assistance, a cross-domain collaboration among various entities providing vital services for a city, like police, ambulance, firefighters, etc. is needed. They have to make coordinated decisions on the basis of available data about where are the resources geographically located and where are they needed, which in many cases may be incomplete and/or not valid any more. These situations can lead to a fragmented and unsynchronized decision-making process among the various entities. As an example of such a situation we can describe more closely the traffic accident scenario. When a traffic accident occurs, there are several entities working at same time on the same event but with different proposes: Police has to deal with the affected people, traffic conditions, etc; Health services have to take care of injured people; Public transportation entities must change routes. There are also a there are also tasks that are generated after the accident, like reparation of damaged infrastructure, vehicles removal, etc. As described, this process involves several roles and cross-sector entities at same time depending on the available data at the moment of the accident.

Coordination of the various city subsystems has similar characteristics to the cooperation between cross-domain entities. For example in a traffic accident event, the city hall must cooperate with health institution, police, transport area and external services. If each involved entities has its own administrative system, the collaboration is limited to phone calls or email exchange. According to [2] time and cost of responding to an emergence can be twelve time higher than using a centralized model of event administration. Computational tools with cross-domain data and models which allow the various entities involved in decision making and/or solution design processes to synchronize their work may be critical to help [3].

Some systems aimed at supporting these activities have already been developed for Wind Farm Sites [4], Water Resource management [5] and Urban Design [6]. However, these have been developed mostly to support specific applications. This work presents a spatial and collaborative decision making platform which serve as basis to develop a large variety of of application supporting design and decision making in collaborative scenarios, where physical

location is an important component of data and information being manipulated. This platform includes the basic common functionalities needed to support complex and specific systems and process.

The platform was designed with three main characteristics:

1. Decision support: The platform must provide the basic support for a decision making process providing the necessary tools and functionalities to successfully accomplish some basic characteristics of a decision making process [7]. This will be described with more detail in section III.

2. Support spatial planning: This means that the platform must provide appropriate interfaces for planning tools, or for in-build developments, and each interaction must be associated to a spatial event (like a traffic accident) and also the interaction results will be shared with other collaborators

3. Support mobile and collaborative work: Many situations where georeferenced information is required for designing, planning and decision making require synchronized on-on-the field work among persons. Therefore, the system

4. Compatibility: Since we want to support the development of tools for scenarios where people belong to various institutions and/or departments, so they may use diverse supporting applications using different formats for data they process. Therefore we consider the use of standards in data format and protocols so the application developed with the platform are able to interact with others system, in a natural and simple way time.

II. RELATED WORK

The established research areas providing insight to the development of this work are mainly Geo-collaboration, Collaborative Spatial Decision Making, and Cross-Domain Interaction.

A. Geo-CollaborationWe analyze the most recent and relevant investigations in

the field of geo-collaboration. Most of these works are aimed to support crisis management, come of them belong to case studies [26], while others propose prototypes including various geo-collaboration characteristics like geographical relationships, awareness, mediation and accessibility.

Half of the works adopt mobile devices to capture data on-the-field, while a central server receives processes and aggregates this information. On the other hand, half of the works describe a proposal rather than a concrete application [23, 25, 26]. Only one of the works describes an application

where users work in the same place, thus supporting co-located mediation. The works described in [25, 27], propose theoretical models where data is gathered in the field and synchronized in a central server. Most of the works are meant for people working in different places and only two of them use GPS to mark physical locations. Only one work considers social awareness. Regarding mediation and accessibility, two works consider virtual mediation, most of them synchronous.

Most works stress the importance of designing simple human-computer interfaces and some of them suggest including speech recognition [28]. Most works adopt gestures to control the system functionality, including marking locations on the map, identifying and associating users’ comments and building awareness [25].

Other works describe the advantages of using synchronously connected mobile computing devices with other physically or virtually distributed located systems. a) eMapBoard [24], is a geo-collaboration tool for disaster management. It offers real-time analysis components. It implements a client/server architecture and is intended to be used in control centers. Hence, it lacks the support for mobile devices. b) GeoMAC (Geospatial Multi-Agency Coordination Group) is a web-based tool originally designed for fire managers accessing online maps of current fire locations and perimeters [29]. Detailed real-time information cannot be provided and it does not allow distributed collaboration. c) Toucan Navigate (http:www.infopatterns.com) is a P2P-based collaborative geographic information system allowing whole teams to concurrently interact with a map regardless of the physical location of its members. The annotations over the map are shared and updated automatically. However, it does not support mobile on-field operators. d) GeoConference allows exploiting geographic data using standard services. In a geo-conference, participants share information in a synchronized geo-referenced workspace [30]. The GeoConference system includes tools to manage users, workgroups and geo-data access. It is mainly used in control centers and no real support for mobility is provided. e) ArcPAD is a mobile client/server GIS product developed by ESRI4. ArcPAD uses handheld and mobile devices, and provides field operators with the ability to capture, analyze, and display geographic information [31]. It cannot be used for ad-hoc and on-field collaboration.

B. Collaborative Spatial Decision Making (CSDM)The integration of spatial data with decision has lead to an emerging category of GIS designated Collaborative Spatial Decision Making (CSDM) [8], [9]. CSDM may also be regarded as a combination of GIS with Decision Support Systems (DSS) and Group Support Systems (GSS) [10], [11]. The CSDM systems support the following functionalities [12]:

Collecting spatially-related data Identifying locations according to a set

of criteria Exploring relationships Displaying and analyzing data Exporting data to other systems and

tools.

Also these functionalities support 3 types of beneficiaries at different levels [12]: a) Managerial level, b) Operational level and c) Individual (user) level

If a CSDM is designed to increase only the individual level we can assume that the decision making aspect will be improved, in this case we will be talking about a DSS rather than a CSDM. A traditional DSS must allow decision makers collect and compile the information needed from databases, models, personal knowledge, etc.

CSDM aims to allow multiple users working together in order to accomplish a single objective, in this case the objective is associated to a spatial environment, and the problematic is described in a geo-referenced context. A CSDM is like a DSS with the information related to a single geo-spatial event and each event has its own context. The context can determine the final decision making, because two different contexts can interfere each other according to their location, time, and involved resources If the collaboration involves a real-time activity, a data-sharing platform is needed [13]. The data can be provided by users, institution, real time sensors, etc. Data must be geo-referenced allowing the platform integrate external spatial databases. For example [14] propose an approach for design Web-GIS collaboration systems using the transport planning in China. This kind of collaborative systems considerer one single information source and one planning objective. This system can be cataloged in an individual level or a DSS. The resulting indicators extracted from this software can support decision making process.

In order to support higher levels it is necessary to build platforms based on existing DSS models. If we assume that the operational level requires some kind of cooperation we can associate it to collaborative or group support systems.

We represent of the mentioned level with the described dependencies using fig 1 has technology organization guide.

Fig. 1. Levels representation and relations with technologies described in [12].

C. Cross-Domain Interaction (CDI)Organizations are usually conducted using workflows

applications, automating the management; however when the process requires the interaction among entities from different areas, the access or integration of different entities systems involves the semantic differences management and security aspect like information access levels.

A significant amount of technologies has been already developed in the areas of user identification and access rights management. We are going to focus in XACML [15]. XACML defines policy decision points (PDPs) and policy enforcement points (PEPs). In order to describe for describe access control rules XACML defines a XML-based policy language. XACML based on a service-oriented architecture.

About semantics differences, there is the fact that cities are the more complex system created by humans [16], and the interrelations between its components difficult its understanding and the optimization of all the processes that occur inside [17]. These interrelations can be defined using an RDF as described in [18].

III. DESIGN PRINCIPLES

In a previous work [7] we analyzed the integration between spatial data and decision making models in Collaborative Spatial Decision Making systems (CSDM), characterizing conceptual views, models of the cognitive process, decision making process models, from this work we extracted the planning characteristics and we synthesize them into the following requirements:

R1)Perception support. Stimuli, disturbances,

events and ecological changes are necessary to stimulate perception. A planning tool should therefore associate changes in spatial data with adequate perceptual mechanisms, e.g., dynamic visualization of spatial data and associated events.

R2)Retention support. Retention is a fundamental driver of sensemaking. It

serves to construct personal and organizational memory and contributes to enact responses whenever recognizable situations emerge. The tool should maintain a repository of the interpretation mindsets and enacted responses in context with spatial data

R3)Externalization support. Externalization is essential to knowledge creation, since knowledge is constructed by articulating tacit knowledge into shared expectancies, cues, goals and actions. Providing support for integrating tacit knowledge with spatial data in a collaborative context.

R4)Divergent/convergent support. Planning seems to be organized according to inter-twined cycles of divergent and convergent activities, where divergent activities favor problem identification and information gath-ering, and convergent activities promote the negotiation and selection of alternatives. A gecollaborative planning should support these working modes.

In the next section we describe our proposed architecture which fulfills the presented requirements.

IV. THE PLATFORM ARCHITECTURE

From the revised literature, we can derive that most planning tools dealing with information highly related to a geographical location should have the following characteristics:

Mobile computing: Many of the planning activities we have seen would benefit from the possibility to work on the field, in order to check on site the characteristics of the place at which the work is targeted. Therefore users should have the opportunity to use mobile devices to interact with the application while visiting the site.

Collaborative and private workspaces: the application should private as well as collaborative work. For this a synchronization mechanism must be implemented, allowing users to share and merge their work using private as well as shared workspaces. This supports the requirements R3 and R4.

Online and Offline working modes: While working on site users might experience connectivity problems which may prevent them to synchronize their data with the rest. However, this should not prevent the user from continuing working. Therefore the application should allow working offline and synchronizing later the data with the rest. This feature fulfils R2.

Enable Spatial Workspaces: Data and information generated or required to perform geo-collaborative

planning activities is naturally related to a geographical location. Workspaces should provide this information in a spatial context. This also contributes to fulfill R1.

Provide action plan simulation:. The platform must be able to reproduce a sequence of steps and actions defined in the planning activity. Providing R1.

Since these are the common characteristics for most spatial related design and planning systems, a platform should provide these basic functionalities and leave to the user the development of the more specific application characteristics for the particular project being developed with the help of this platform development project. For example, in a transit planning system, these elements can be a collection of transit signs icons which should be placed in certain places over a street map. In other scenarios these elements can be software agents, with their own specific behavior and with capacity to generate and process data. These elements can also interact with each other, the map, and the user.

From the first and second requirement we infer that the platform must be implemented in HTML5. Using HTML5 implies cross platform applications this means that multiple kinds of possible client devices are supported, allowing client side features like WebDatabases, WebSockets and Tag Roles. For example the following devices support HTML5 at the required levels: Ipad’s, Android Tablets, Smartphone’s, Notebooks, etc. (see fig 2). In a technical view all clients runs a Javascript application on their browsers. The interactions between different clients are managed by a centralized database; witch contains all events generated by clients.

Fig. 2. Client-Server architecture and functions with HTML5 platform.

All the functionalities mentioned in Fig 2 are provided by specific components at the Client and Server application.

Clients:Local copy of data.

User interaction.

Data Visualization.

Map Interaction.

Execute Spatial Models

Server:Events Distribution.

Mantain a master copy of data.

Mantain a list with each one state.

Provide Syncronizing features.

A. Client ApplicationThe client application contains almost all the components

needed to support the planning requirements previously described. These components are:

Discrete Event Simulator Engine [19]: This component consist of a list of events, each one associated to a discrete time starting in 0, each event is generated by s Simulation Object, event are actions and can affect other objects. Also an object can subscribe a type of event. When the simulation starts an initial event must affect an object and this object generates other event associated with a future time o clock tick. The context specific application can be build over this engine. For example for a traffic accident process simulation, an accident event must be introduced, this event can trigger health service assistance, or not. All events are organized and they can be evaluated. If the application generates automatically a health service requirement implies a divergent process, but if the police man role cancels that event according to his information, the process converge in real time. This component supports R1.

Squares: All events and information must be associated to a spatial context, and in our case this context is defined has geographical Squares (see Fig 3), another important role of square is provide a spatial workspace with the collaborative features previously described. Also in order to provide the data spatial environment we implement a spatial information layer associated to each square. This component supports R1 and R3.

Fig. 3. The blue square is the currently selected spatial segment, all and only the data related to this area is loaded at the selection event improving the persistent layer performance by doing small and indexed requests.

Spatial Information Layer: Each Square has variables:value pair associated with it and with the simulator tick number(time) (see figure 4). This information layer accept insert and request operations:

Insert: On insert of an existing variable, the new value is associated to the current tick.

Request: Access the value associated with the higher tick.

This component supports R1, R2 and R3.

Fig. 4. Square spatial data associated to simulator ticks can be displayed as time evolution indicators. In order evaluate a model performance across time, these feature can be used has a decision making tool by setting upper and lower bounds each metric and running a simulation over real spatial data.

Graphical Information Layer: Another important feature is the graphical layer generation, when data must be show in a spatial context an specific application can generate a layer using the OpenLayer library [20], and associate to this layer images, maps, point, geometrical figures, html, etc. see Fig 7. This component supports R1 and R3.

Fig. 7. On the left, a graphical layer selection tool of visual elements. This kind of user interface is commonly used on graphical editing software’s like Photoshop or Gimp. On the right, the spatial data associated to a square is displayed; this data can be loaded or generated by an ACE

Active Cartographic Elements (Agents): Almost any kind of model or process can be implemented with Discrete Event Simulation; in our case Simulation Objects are associated with the user interface, database interfaces, and other. These objects are normally called agents, but they runs in a spatial context, so we call them Active Cartographic Element (ACE). ACE’s has access to visual elements, user interfaces, AJAX calls, remotes REST interfaces, local JavaScript API’s, etc. They operate in several levels as show in Fig 5, and the user

interface is design to include them into the a spatial context by simple drag and drop (Fig 6), when an ACE is dropped into the map, a new ACE instance is created and the drop coordinates are associated to it. Depending on the implemented model an ACE can require more information for his own instance. This component supports R4.

Fig. 5. All layer are implemented on client side; ACE’s can access the spatial information layer, the map layer via OpenLayer API , Graphical elements over the maps, and listen directly user interface events via the UI and the map.

Fig. 6. ACE’s are called Agents on the user interface, they can be dropped in to the map or a square, and the Simulator will automatically execute the initialize method on it.

On implementation ACE’S are basically Simulation objects, and in order to run over an Event Simulator they have some basic methods:

Initialize

Listenevent Eventhandler Addevent Remoteaddevent

Using the Spatial Information Layer, Graphical Information Layer and the ACE basic methods as base object, A specific application can be developed with less resources (see next section).

B. Server ApplicationThe server provides a platform for distribution, synchronization and collaboration features. When a client event is generated at the Simulator, it will be sent to the server and distributed. The interactions between different clients are managed by a centralized database; witch contains all events generated by clients. This database also provides an historical register of user interaction for system analysis.

In this paper we proposed to tackle the problem of designing successful PVC. We proposed a conceptual model and tested through field research a participation strategy based on intrinsic motivation. We analyzed the interaction among users, as well as the contribution patterns they had through time, as well as analyzing the role of the community manager. We believe this study will bring ideas to designers on how to develop strong and sustainable PVC, as well as how community managers may maintain and evolve communities through time.

With the intention of evaluating one of the core components of the model we proposed, we focused on developing a partially virtual community where members could reply or post their own discussion topics, and analyzing the response on its lifecycle when affecting its members’ motivation and participation. The idea of working with these variables came from the need of quantifying the relative impact of a followed participation strategy within the validity of the proposed model. We put into practice two social functionalities in the community that seemed to work well, since they triggered participation with visible local peaks. Feedback proved also to be a plausible way to improve participation at certain periods of time.

Highly-active members acted as leaders who encouraged the whole group to participate, as well as proposing new discussion topics, being highly praised by the community.

The community decreased its level of participation when the community manager stopped to propose new discussion topics (passive stage). In other words, participation during these days went down, reaching a level that could not be sustainable for the community. Consequently, this led to a reduced number of logs into the system, and the community finally entered into an irreversible process causing its death. This can be explained because of not reaching the critical mass of logs and contributions to the community to ensure participation. When we introduced again the role of community manager proposing new discussion topics,

Event SimulatorSimulation Objects

OpenLayer - API

Spatial

Information

Layer

Graphical Information

Layer

UI - MAP

ACE

members did not react, even if we also sent them a feedback message telling them about these new messages. Only high-committed students kept logging and posting messages.

We consider that one of the fundamental issues to be taken into consideration when designing a PVC, is to define a strong participation strategy, adapting it to the current stages of the community lifecycle and to how members are reacting towards it.

As future work, we will be interested in studying community governance strategies and how they impact on the global design of the community. We believe that when there is a strong governance structure, communities will regulate themselves and they will be successful over time without external influence. Also, we will be interested in studying the applicability of this model in different kinds of contexts, as well as exploring different technical environments, such as mobile-based virtual communities, exploiting specific hardware capabilities and how they will eventually impact on participation.

V. APPLICATIONS DEVELOPED WITH THE PLATFORM

The concept of ACE’s can be applied on different solutions; on this section we describe three applications developed using this platform, describing what they used from the platform and what was necessary to develop in addition to achieve the desired goal with that application.

A. Wireless network planning: The objective of this application is providing a

collaborative wireless network planning tool for the television industry. This industry involves several entities that have to interact each other in order to manage the electromagnetic spectrum as a limited resource. This resource can develop different spatial characteristics according to the channel transmission frequency and the transmission antenna configuration. The key evaluation metric is the signal strength received at a certain location, using this metric the television signal assignment is ruled by the following characteristics: Several television channels can transmit at the same

location but their coverage area may vary according to the frequency and other configurations.

Two different transmission centers can use the same frequency only if they are at different locations.

The retrieved signal difference between co-channels (ex: 7 and 8) at the same location must be upper than a certain value.

Various antennas which should provide a certain coverage area with service using the minimum of resources.

The configuration parameters are the frequency, transmission power, antenna height, type and orientation.

The coverage area can be estimated by propagation

models [21].

In order to support all this variables and models, we convert an existing software of 2854 JavaScript lines into an ACE, adding/overwriting methods to the existing ones, the results is a 424 lines ACE. This ACE corresponds to a transmission antenna model that can be dropped into the map. When the antenna (ACE) is located the configuration parameters can be filled by clicking on it, after filling the required information the ACE will generate a full signal coverage analysis as show in Fig 7, and adding the signal strength metric value into the spatial information layer associated to each affected square in the coverage area.

Fig. 7. Two different transmission antennas located at 120km each other. TV signal coverage of Santiago and Valparaiso cities in Chile simulated using an ACE.

The developed application provides R1, R2 and R3 by using the spatial information layer, the signal strength is associated to squares providing R4 by allowing individual and collaborative workspaces, and also the simulation engine runs the propagation models providing R1.

B. Twitter real time spatial data analyzer: Several applications like Titanium-Geo[22] or

nearbytweets.com has been developed with the objective of provide a visualization in real-time geo-tagged tweets related to certain words, sentiments or brands. For this case case we develop a Twitter information filter, using an ACE for information gathering and graphical layer generator (see Fig 8).

Fig. 8. The Twitter layer show centered circles, the number of circles represent the number of repeated keywords founds in the square.

This ACE use a list of keyword as input, when it is dropped into a square it will began to collect tweets from the square area using the Twitter REST API [23]. The output of the ACE is the keywords repetition counts in the square area (inner radius); this information is added to the information layer (see Fig 9) and to the graphical information layer as circle (Fig 8), this ACE has only 58 lines of standard JavaScript code.

Fig. 9. Twitter ACE output is accessible by the spatial information layer.

This application provides R1, R2 and R3 by using the spatial information layer, the graphical information layer provide R1 and R3 and squares provide R4.

C. Satellite image processing: A common tool for planning is the satellite image

processing, this tool can be used to detect some kind of vegetation or terrain. This is done by applying specific image processing algorithms that can filter and extract this data from the image.

We develop a basic color filter based ACE, with the specific objective of detect the proportion of the square with a certain color characteristic. For example, trees, road concrete, sand, etc. This ACE adds the filter results to the spatial information layer and the graphical information layer. When user clicks, the ACE picks the color of the clicked area and applies the filter. On Fig 10 the 28% of the square has a similar color characteristic. This ACE has 25 lines of code and uses the HTML5 Canvas features.

Fig. 10. On the left, square area image; on the right is the filtered square image generated in the graphical information layer. .

This application also provides R1, R2 and R3 by using the spatial information layer, R1 and R3 by using the graphical information layer and R4 by squares.

REFERENCES

[1] IBM Institute for Business Value, A Vision of Smart Cities:How Cities can Lead the Way into a Prosperous and Sustainable Future, 2009. [Online]. Last visited on December 2011. Available under: ftp://public.dhe.ibm.com/common/ssi/pm/xb/n/gbe03227usen/GBE03227USEN.PDF

[2] IBM Institute for Business Value, A Vision of Smart Cities:How Cities can Lead the Way into a Prosperous and Sustainable Future, 2009. [Online]. Last visited on December 2011. Available under: ftp://public.dhe.ibm.com/common/ssi/pm/xb/n/gbe03227usen/GBE03227USEN.PDF

[3] Besserud, K.; Hussey, T.; , "Urban design, urban simulation, and the need for computational tools," IBM Journal of Research and Development , vol.55, no.1.2, pp.2:1-2:17, Jan.-March 2011

[4] Simão, A., Densham, P., & Haklay, M. (2009). Web-based GIS for Collaborative Planning and Public Participation: An Application to the Strategic Planning of Wind Farm Sites. Journal of Environmental Management, 90(6), 2027-2040. ACADEMIC PRESS LTD Last visited on December 2011. Available under: from http://discovery.ucl.ac.uk/150494/

[5] Nyerges, Timothy and Jankowski, Piotr and Tuthill, David and Ramsey, Kevin, 2006, Collaborative Water Resource Decision Support: Results of a Field Experimen, Annals of the Association of American Geographers, volume 96, number 4, pages 699-725.

[6] Ligtenberg, A., de Vries, B., Vreenegoor, R.C.P. and Bulens, J.D. 2011. "SimLandScape, a sketching tool for collaborative spatial planning." Urban Design International. vol. 16. 7-18.

[7] Pedro Antunes, Cláudio Sapateiro, Gustavo Zurita, Nelson Baloian. “Integrating Spatial Data and Decision Models in an E-Planning Tool” CRIWG'2010. pp.97~112

[8] MacEachren, A., Brewer, I.: Developing a Conceptual Framework for Visually-Enabled Geocollaboration. International Journal of

Geographical Information Science 18, 1–34 (2004)[9] MacEachren, A.: Moving Geovisualization toward Support for Group

Work. In: Dykes, J.,et al. (eds.) Exploring Geovisualization, pp. 445–462. Elsevier, Amsterdam (2005)

[10] Nyerges, T., Montejano, R., Oshiro, C., Dadswell, M.: Group-Based Geographic Information Systems for Transportation Site Selection. Transportation Research C 5, 349–369 (1997)

[11] 5. Armstrong, M.: Requirements for the Development of Gis-Based Group Decision Support Systems. Journal of the American Society for Information Science 45, 669–677 (1994)

[12] Crossland, M., Wynne, B., Perkins, W.: Spatial Decision Support Systems: An Overview of Technology and a Test of Efficacy. Decision Support Systems 14, 219–235 (1995)

[13] Hidaka, C. E.; Jasperse, J.; Kolar, H. R.; Williams, R. P.; , "Collaboration platforms in smarter water management," IBM Journal of Research and Development , vol.55, no.1.2, pp.14:1-14:11, Jan.-March 2011

[14] Xiaolin Lu; "A new approach for Web-GIS based collaborative transportation planning system design," Computer Supported Cooperative Work in Design, 2004. Proceedings. The 8th International Conference on , vol.2, no., pp. 637- 642 Vol.2, 26-28 May 2004.

[15] Tim Moses. (1 Feb 2005) eXtensible Access Control Markup Language (XACML) Version 2.0.

[16] M. Batty, Cities and Complexity. Cambridge, MA: MIT Press, 2005.[17] Fink, J. H.; , "Cross-sector integration of urban information to

enhance sustainable decision making," IBM Journal of Research and Development , vol.55, no.1.2, pp.12:1-12:8, Jan.-March 2011

[18] Rosario Uceda-Sosa, Biplav Srivastava, and Robert J. Schloss. 2011. Building a highly consumable semantic model for smarter cities. In Proceedings of the AI for an Intelligent Planet(AIIP '11). ACM, New York, NY, USA, , Article 3 , 8 pages. DOI=10.1145/2018316.2018319 http://doi.acm.org/10.1145/2018316.2018319

[19] libro oficina nelson[20] OpenLayers http://www.openlayers.org/[21] M. Hata, "Empirical Formula for Propagation Loss in Land Mobile

Radio Services", IEEE Transaction on Vehicular Technology, Vol.VT-29, No.3, pp 317-325, 1980.

[22] Titanium-Geo http://www.appcelerator.com/products/titaniumgeo/[23] Cai, G.: Extending Distributed GIS to Support Geo-

Collaborative Crisis Management. Progress in Human Geography 25 (2001).

[24] MacEachren, A., Guoray, C., Brewer, I., Chen, J.: Visually Enabled Geocollaboration to Support Data Exploration & Decision Making. Procs. of the 21st International Cartographic Conference, Durban, South Africa (2003) 10-16.

[25] Capata, A., Marella, A., Russo, R.: A Geo-Based Application for the Managemnt of Mobile Actors During Crisis Situations. Proceedings of the 5th International ISCRAM Conference, Washington DC, US (2008).

[26] Schafer, W., Ganoe, C., Caroll, C.: Supporting Community Emergency Management Planning through a Geocollaboration Software Architecture. Computer Supported Cooperative Work 16 (2007) 501-537.

[27] Bortenschlager, M., Leitinger, S., Rieser, H., Steinmann, R.: Towards a P2P-Based Geocollaboration System for Disaster Management. GI-Days 2007 - Young Researchers Forum (2007).

[28] Fuhrmann, S., MacEachren, A., Dou, J., Wang, K., Cox, A.: Gesture and Speech- Based Maps to Support Use of GIS for Crisis Management: A User Study. AutoCarto 2005, Las Vegas, US (2005).

[29] Wagtendon, J., Zhu, Z., Lile, E.: Appendix E - White Paper on Pre-Fire Risk Assessment and Fuels Mapping. (2004).

[30] Siegel, C., Fortin, D., Pellerin, E.: Bringing Geospatial Expertise to Emergency Operations Management with Geoconferencing. Proceedings of the 98th Conference of the Canadian Institute of Geomatics, Ottawa, Canada (2005).

30. ESRI: Arcgis 9, Arcpad Reference Guide. USA (2005).


Recommended