1. Introduction

assistantashamedΔιαχείριση Δεδομένων

29 Νοε 2012 (πριν από 4 χρόνια και 6 μήνες)

218 εμφανίσεις

Making GIS closer to end users of urban environment data

Andrea Aime
1
,
Silvia Ascari
1
, Flavio Bonfatti
2

and Paola Daniela Monari
2

1
Department of Environmental Control & Urban Planning, Municipality of Modena

2
Department of Engineering Sciences, University
of Modena and Reggio Emilia

Via Campi 213/B, 41100 Modena, Italy


tel. +39 059 376732

email: bonfatti@unimo.it


1.

Introduction

The ISOLA European project is aimed at studying a unified way to organise and analyse urban environmental data,
developing a sound

methodology to face environmental problems, and provide analysis tools that enable domain experts
to take full advantage of GIS capabilities.

From the technological point of view, the ISOLA project develops an Environmental Information System (EIS), named

ISOLA in turn, that supports the proposed methodology with strong focus on exportability among different GIS systems
and different analysis needs. In fact, public administrations differ in two fundamental aspects:



environmental issues, since these are rel
ated to the peculiar features of the local environment, even if there is
an obvious set of issues directly related to human activities that does non change from place to place;



GIS tool available (GIS engine, visualizer, data base management system), which

differ according to the needs
already faced with GIS technology, financial capabilities and knowledge.

The first problem is addressed by avoiding any hard
-
coding of analysis or presentation logic, letting the user define and
store it for later use. The se
cond problem is addressed by developing a system that is independent of the GIS engine and
visualiser, and using for the prototype well established software, that is likely to be found in European public
administrations, and freeware, so enabling also smal
l administrations to gain benefits from our approach. ISOLA will be
composed of:



a graphic user interface to define and execute spatial analysis, that we call the process editor



a graphic user interface to define thematic maps, the thematic map editor



a ce
ntralised repository in which data, analysis and thematic maps definition are stored



a set of drivers (virtual machines) that are able to execute the desired analysis procedures over different GIS
engines and realise thematic map in collaboration with a pa
rticular visualization tool.

Since virtual machines are the only modules highly coupled with external tools we expect the porting to other GIS
platform to be easy and cheap. The prototype is based on the GRASS GIS as a raster engine, on PostgreSQL as objec
t
-
relational DMBS with spatial data extensions, and on Autocad Map 2000 for map production and analysis, a very
popular Autodesk product at European public administrations.

In this paper we focus on the ISOLA analysis tool, the heart of the approach, that
enables users to carry out
environmental studies leveraging the development of new analysis, and the sharing of analysis knowledge. More details
about the ISOLA approach and the process model can be found in [UMDS99] and [ACM99]. Section 2 introduces the
p
rocess model, a graphical method to define spatial analysis, which is supported by the process editor presented in
Section 3. Since we have found other products based on the idea of process model, in Section 4 we compare our
approach with the others. Final
ly, Section 5 describes process execution over a GIS engine through a virtual machine,
and Section 6 draws conclusive remarks.

2.

The process model

A process is intended as an ordered sequence of operations aimed at manipulating spatial data with the purpose
of
extracting additional meaning as a result. Data and operations, and the links that establish the operation execution order,
are the basic process concepts:



Data are spatial information manipulated by the process, each one associated with a type, compose
d of a
geometric characterization (point, line, polygon and raster) and a set of attributes (only one for raster data, zero
or more for vector data). Each data can be persistent (an input or and output of the process) or intermediate, a
semi
-
finished that
will be thrown away as the process terminates its execution.



Operators represent the spatial operation performed on available data in order to get new information. Each
operator has a set of input roles, each one with a specific meaning, that will be linke
d to data, a set of
parameters, that affect how the operators computes output data, and of course a set of output data.



Links represent input/output relations between data and operators, in other word they connect operators to their
input and output data.

The process can be imagined as an oriented, acyclic digraph whose nodes are, alternatively, spatial data and operations.
The graph extreme nodes are spatial data, in that every process starts from its input data and reaches the resulting output
data.

The
process model is a set of primitives that allows the user to express his/her intentions at the conceptual level, that is,
without being distracted by implementation issues.

The advantages of such an approach are several:



the user can specify a sequence of
operations without using a programming language, but still making a formal
and executable specification;



the user can work in an iterative fashion, modifying the process again and again in order to refine analysis and
obtain the desired results;



the proces
s enables the reuse of the same analysis on different input data, with the same meaning but coming
from different location (spatial reuse) or from the same location in different times (temporal reuse).



Figure
1
: Selection of can
didates for conservation areas


An example of process is depicted in
Figure
1
: we want to select some candidates for a new conservation area that will
protect wild animals, in particular we are interested in bears, mountain lions
and deer. We are looking for areas that fall
into wild animals habitats, that are not too close to roads and that are not already included into national parks.
Supposing to work with raster data (CL, cell layers), the desired information can be obtained by

performing the
following steps:



calculate a buffer around roads, maybe by using a different buffering distance according to road class



merge habitats by means of a reclassification of multiple data or by a Boolean expression, both supported by
the CMR ope
rator (raster compute, an operator which performs raster algebra, weighting and reclassification)



delete from the merged habitats road buffers and national parks, again with a multiple reclassification or by
using a Boolean expression.

In order to leverag
e the advantages of process modelling in spatial analysis, a process editor is realised, enabling the
user to interactively create, modify and save process diagrams, thus supporting both iterative definition of a process and
reuse. If a process represents
an operation that can be thought as a building block for more complex analysis, or if a
certain analysis is planned to be executed over and over with different data, the process editor allows to change the
process into an user defined operator that can be
used to build new processes.

3.

Process editor

Graphical processes are a useful working tool only when supported by an environment that allows interactive building,
validation ad execution. Construction and validation are delegated to the process editor, a gr
aphical and interactive tool
whose main features are:



immediacy, since it is based on the same use convections already adopted by most office automation tools



ease of use, as the user interface is based on a small set of commands, and, when the operator re
quires more
than one step and lots of choices, parameters are specified by simple dialogs boxes and wizards



control over process development, both from a graphical and from a semantic point of view.

Immediacy is obtained by means of features such as multip
le undo/redo, multiple selection by means of windows,
moving of objects based on drag&drop, multilevel zoom, ability to get a picture of a process and paste it in presentation
or reports being developed with an office automation tool. Obviously, moving ite
ms around does not change process
structure, every link between data and operator are moved consequently, keeping data hooked to operators that
uses/generates them.

In a near future a report function is going to be developed, able to generate a textual des
cription which complements
graphical form with the information that are not visible. These are typically operator parameters and comments that the
user can introduce to describe the process as a whole, a given operation or some intermediate data. Such a
do
cumentation is useful to share process knowledge, since it becomes a complete and unambiguous documentation of a
spatial analysis procedure.

Considering interactive use, there are some features that improve the ease of use and help to obtain a straightforw
ard
representation. First, the editor enforces the placement of items onto a predefined grid, helping the user to develop a
clear and well
-
organised layout. Second, if a link between data ad operators intersects other items, it is possible to use a
“place
card”, called reference, that allows getting a better representation (see
Figure
2
).




Figure
2
: Use of references

As already stated, the process editor is not a simple flowcharting tool, since it

assists the user in the creation of correct
and executable processes, by means of semantic control features. Controls are executed in real time, as the user creates
and modifies the process, allowing the immediate evaluation of the effect of a change on t
he whole process.

Considering the nature of a data flow structure and the broad possibilities of editing granted to the user, some errors are
underlined but allowed, while some others are forbidden. In particular, these operation are fully forbidden:



linki
ng two data to the same role (which is nonsense)



creating a loop in the graph (which would lead to an infinite loop during execution).

In addition it is pointed out, by colouring operators, every situation that could lead to a nonsense or dangerous process

execution. These situation are categorized into violation of completeness and correctness:



completeness violation: it exists at least one operator whose input roles are not linked to any data, or for which
parameters have not been specified;



correctness v
iolation: it exists at least one operator with wrong inputs (data types that do not conform with the
desired one).

User can reach correctness violation in various ways, for instance it can directly link a data to an operator unable to use
it, but it is als
o possible that a modification of a parameter or an input of an operator could change its output, making it
incompatible with the operators that use it as an input.

The last fundamental feature of the editor, still not available but planned to be developed

very soon, is the ability to
encapsulate a process into a user defined operator, what we call macro
-
operator. Translating a process into a macro
-
operator frees the process from its input, keeping only information about the needed input type. The translati
on in based
on the following considerations:



operators do not use, in general, every attribute associated with their inputs;



intermediate data attributes descend partly from input data, whereas partly are generated by the process
operators themselves.

Foll
owing these considerations we can outline a simple algorithm to calculate the needed input types: starting from
output and going backward, we exclude all the attributes that are generated by operators and the ones that flow
unaffected from input to output,

the remainder are the ones that the macro
-
operator needs to work.


R:
Vegetation
R2C:
Ras2cl01
IN
OUT
R2C:
Ras2cl01
IN
OUT
R2C:
Ras2cl01
IN
OUT
C:
CVegetation
C:
DEM
SLP:
Slope01
IN
OUT
SLP:
Slope01
IN
OUT
SLP:
Slope01
IN
OUT
C:
Slope
C:
Erodibility
CMP
: Comp01
A
OUT
CMP
: Comp01
A
OUT
CMP
: Comp01
A
OUT
CMP:
Comp02
A
OUT
CMP:
Comp02
A
OUT
CMP:
Comp02
A
OUT
CMP:
Comp3
A
OUT
CMP:
Comp3
A
OUT
CMP:
Comp3
A
OUT
C
C:
SlopeClass
C
CMP:
Comp04
A
B C
OUT
CMP:
Comp04
A
B C
OUT
CMP:
Comp04
A
B C
OUT
C:
SoilErosion
PotErod
:
PotentialErodib01
Vegetation
DEM
Erodibility
Erosion
PotErod
:
PotentialErodib01
Vegetation
DEM
Erodibility
Erosion
R
:
NewVeget
C:
DEM
C:
Erodibility
C:
SoilErosion

Figure
3
: Construction of a macro
-
operator


4.

Comparison with other experiences

The idea of analysis process is not new, references can be seen into several publi
cations on spatial data analysis. In
particular, it is common to see data derivation procedures in some kind of data flow diagrams, as an alternation of data
and operation.

The novelty and strength of process model is in that it formalises process diagrams

into an executable definition that can
be shared and modified by users. But even the idea of an executable process model is not new, we can find at least two
other examples that supports this idea:



Model Builder, a tool bundled with ArcView Spatial Analys
t 2.0 [ARC];



AMO [AMO], a process modeller that can be used to generate SPRING scripts (written in LEGAL);

It can be interesting to compare with ISOLA these process models, as they are presented in the documentation available
via Internet. First of all, we

can see substantial graphical differences:



ISOLA and Model Builder neatly separates data and operator, whereas AMO does not separate them much,
using symbols which are really similar



ISOLA and Model Builder identify data and operators by means of text, wh
ereas AMO uses colour, icon and
text



AMO does not separate in a visible manner input and output data, Model Builder distinguishes them by using
different symbols, while ISOLA considers input and output data, but also intermediate non persistent data, so it

is the only one that does not requires the user to give a name to each intermediate data



AMO and Model Builder do not use roles, links just point to the operator; this is not an issue when working
only with raster data, as usually input roles do not have
different meaning, but it can become annoying with
vector operators, in which different input play different roles to operators



Model Builder and AMO cannot generate used defined operators


Model Builder proposes a peculiar approach, in that it makes the
user define, in a single diagram, both analysis and
thematic mapping information: this allows the user to obtain thematic data in shot times, but it does not allow to
separate the data from its representation. We are convinced that thematic mapping should
be decoupled from analysis,
since the same data can be rendered in different ways, according to the use and the data characteristics that the user
wants to emphasise. Model Builder validation is done after process editing, while we do not know anything abo
ut AMO
validation procedures.

From execution and integration point of view, Model Builder is strictly integrated within ArcView, as AMO is based on
SPRING, whereas the ISOLA process model aims to be independent from the GIS engine, by using a common subset

of
operator and an abstraction layer that makes portability feasible. Being not based on a particular GIS, the ISOLA
process model provides also vector analysis operators, and can be used with a full fledged GIS engine (such as
ARC/INFO or TNTMips) or wit
h a couple of engines, one raster engine (GRASS, SPRING) and one vector engine
(Audodesk MAP 2000 could be a choice). On the contrary, being integrated in raster engines, ArcView and AMO do
not provide operators such as overlays, vector attribute calculati
on and so on.

Last, a difference can be found in the way process modellers execute their codes: Model Builder is the main Spatial
Analyst feature, so execution is direct and does not require user intervention, while in ISOLA the execution is made
over a vi
rtual machine, which calls the GIS engine, whereas AMO is a LEGAL code generator, which must then be
used directly by the user.




Figure
4
: The process model of
Figure
1
, in ArcView Model

Builder




Figure
5
: A sample process in AMO notation

5.

Process execution

In previous paragraphs we have stressed GIS engine independence of the adopted process model, editor and execution
environment that constitute the ISOLA plat
form. Here we provide details about how this independence is obtained and,
in some cases, leveraged to get better performance.

Process translation into engine calls is performed by two steps:



first, the execution environment translates (compiles) high leve
l operators into calls to a virtual machine,
whose interface is still independent of GIS engine



then, the virtual machine translates this intermediate language into specific GIS engine calls.

This architecture aims to minimize the quantity of code dependen
t on GIS engine, making porting activities simpler and
less expensive. Moreover, the execution environment and the virtual machine communicates through sockets, a quite
standard communication interface that enables to hide software distribution (software d
oes not need to be changed in
order to use a one
-
machine approach) and lets the VM programmer choose the implementation language that best suits
the GIS environment, server operating system and his particular programming skills.


R
:
TettoGhiai e
REC:
RECL01
IN
OUT
R
:
Li tolSuperf
OVR:
OVER01
IN RE
OUT
R
R
:
Li tology
R
:
TettoGhiai e
REC:
RECL01
IN
OUT
CreateVectLayer
OUT
Update
IN.
key
, RE.
key
, OUT.
key
AddCL
att1, IN.att1.
type
, OUT
Update
IN.att1, RE.att1, OUT.att1

AddCL attN
, IN.
attN
.
type
, OUT
Update
IN.
attN
, RE.
attN
, OUT.
attN
Select
IN,VAL1,”
Att
=Val1”

Select
IN,VALN,”
Att
=
ValN

‘ Operazioni di
buffering
Buffer VAL1,BVAL1,Dist1

Buffer VALN,BVALN,
DistN
‘Operazioni di
update
e
ricodifica
CreateVectLayer
OUT
CreateVectLayer
TEMP
Update
BVAL1.
Key
,BVAL2.
Key
,OUT.
Key
Copy OUT.
key
,TEMP.
key
Update
TEMP.
Key
,BVAL3.
Key
,OUT.
Key
Copy OUT.
key
,TEMP.
key
CreateVectLayer
OUT
Update
IN.
key
, RE.
key
, OUT.
key
AddCL
att1, IN.att1.
type
, OUT
Update
IN.att1, RE.att1, OUT.att1

AddCL attN
, IN.
attN
.
type
, OUT
Update
IN.
attN
, RE.
attN
, OUT.
attN
Select
IN,VAL1,”
Att
=Val1”

Select
IN,VALN,”
Att
=
ValN

‘ Operazioni di
buffering
Buffer VAL1,BVAL1,Dist1

Buffer VALN,BVALN,
DistN
‘Operazioni di
update
e
ricodifica
CreateVectLayer
OUT
CreateVectLayer
TEMP
Update
BVAL1.
Key
,BVAL2.
Key
,OUT.
Key
Copy OUT.
key
,TEMP.
key
Update
TEMP.
Key
,BVAL3.
Key
,OUT.
Key
Copy OUT.
key
,TEMP.
key
GRAPHICAL
VERSION
VM CALLS
EXECUTION
ENVIRONMENT
VIRTUAL
MACHINE
RASTER
ENGINE
VECTOR
ENGINE
LOCK
MANAGER
VIRTUAL
MACHINE
GEOGRAPHIC
DATA
PARALLEL EXECUTION

Figure
6
: Process execution

As already stated in [ACM99], ISOLA will adopt a client/server architecture: this means that several users can view,
analyse and modify the same data at the same time. This is a well known problem in computer science, and it i
s usually
solved by putting data into a data base management system, under transaction and lock management.

Unfortunately, most GIS engine still use files and file systems as preferred way to store information, moreover they
usually adopt a workstation app
roach, without considering multiple users for the same data. To enable user concurrency
we use a lightweight lock manager adopting a simple reader/writer policy on shared files, essentially preventing any
other access while a file is being modified.

Execut
ion parallelism in not only exploited by letting multiple users make analysis at same time, but also at a single
process level: looking at a process, it is easy to find out parallel execution flows that can be exploited to speed
-
up
execution on a multi
-
pro
cessor server without modifying the GIS engine. A great advantage could be obtained if every
single command could be implemented in a data parallel fashion, but this involves radical change in GIS engine, which
is beyond our control. By now, parallel execu
tion is made possible by creating more than one virtual machine per single
process, one for each independent execution flow. As a role of thumb, the server side creates one virtual machine for
each client, allowing for further virtual machines depending on

current load, and hardware characteristics, in order to
optimise overall execution time.

Since process execution can even take long times, depending on the number and nature of operators used, the execution
environment provides a visual feedback on the ex
ecution progress, highlighting operations that have already been done:
as a side effect, the user will be able to notice parallel execution, too.

6.

Conclusions

The Environmental Information System ISOLA enables the domain expert to model different kind of an
alysis on geo
-
referenced data, following a new approach, user oriented, based on conceptual modelling of analysis procedures.
Compared with similar environments, ISOLA presents some new features such as GIS engine independence, real time
model validation,
client/server and parallel execution model. The ISOLA platform is going to be experimented by the
Modena Municipality in the next few months.

The modular architecture, conceptual approach and client server nature allows a complete porting of ISOLA to an
In
ternet/Intranet approach, letting the user make not only visualization but also remote analysis, opening new
opportunities of spatial data use in big and small organisation. This is a new exploitation direction we are going to
undertake.

7.

References


[UDMS9
9]

F. Bonfatti, P. D. Monari,
C. A. Muratori

, “
Th攠f协䱁 prçj散琺⁡ nçv敬e慰prça捨 瑯 urb慮 敮v楲çnãen琠
data use”, UDMS 99, Venice, 1999

[䅃䴹V]

A. Aime, F. Bonfatti, P. D. Monari, “Making GIS closer to end users of urban environment data”, ACM
䝉匠pVI h
慮s慳⁃átyI NVVV

[䵁m]

䅵瑯捡d 䵁m 2MMMI Au瑯d敳kI
h瑴t㨯:睷w.au瑯d敳e.捯ã


[䝒A卓]

䝒Ap匠pçã攠p慧攬
h瑴t㨯L睷w.g敯g.uná
-
h慮nçv敲.d支gr慳a


[m卑p]

mçs瑧r敓兌

hçã攠pag攬
h瑴t㨯L睷w.pçs瑧r敳e氮lrg


[䅒C]


印慴楡氠慮慬ys琠fçr Ar捖楥wI bsr椬á
h瑴t㨯:睷w.esr椮áçãLsçftw慲支慲捶楥w⽥x瑥ts楯ns⽳p慴ax
琮ttãl


[卐o]

卐of乇khçã攠pag攬
h瑴t㨯:睷w.dp椮楮p攮br⽳pr楮g


[A䵏]

Lucena, Camara, Nascimento, “Um Ambiente de Geração de Programas de Análise Espacial

“,
h瑴t㨯:睷w.cnp瑩愮eãbr慰愮br⽾楶an⽤ç振慧p慥⽡Lp慥.htãl