Transcript ([email protected]) Outline • Motivations • Research Issues • Architecture: Federated Service-Oriented Geographic Information System • Performance enhancing designs measurements and analysis • Conclusions.

([email protected])
1
Outline
• Motivations
• Research Issues
• Architecture: Federated Service-Oriented
Geographic Information System
• Performance enhancing designs measurements and analysis
• Conclusions
2
Geographic Information Systems (GIS)
• GIS is a system for creating, storing,
sharing, analyzing, manipulating and
displaying geo-data and associated
attributes.
• Inherently requires federation (see
the figure)
– Autonomy for scalability, flexibility
and extensibility
• Distributed data access for geo-data
resources (databases, digital libraries
etc.)
• Utilizing remote analysis, simulation
or visualization tools.
• Open Standards
– OGC and ISO/TC-211
3
Motivations
• Requirements for –
o Interoperable Service-oriented Geographic
Information Systems
– Necessity for sharing and integrating heterogeneous data
and computation resources to produce knowledge.
o Uniform data access/query, display and analysis
from a single access point
o Responsive and interactive information systems
– GIS applications require quick response
• Emergency early warning systems
• Home-land security and natural disasters.
4
Research Issues
• Interoperability
– Defining component based Service-oriented GIS data Grid
framework
– Adoption of Open Geographic Standards -data model and services
– Applying Web Service principles to GIS data services
– Integrating Web Service and Open Geographic Standards
• Federation
– Capability-based federation of GIS Web Service components
– Unified data access/query, display from a single access point
through integrated data-views
• Addressing high-performance support for responsiveness
– Streaming GIS Web Services and Pre-fetching framework
– Client-based caching
– Parallel processing through attribute based query decomposition
5
Web Service components and data-flow
Service-oriented GIS
• • WMS
are
data rendering services providing human comprehensible data
Built
over:
(binary map images)
– are
Web
Services
and
• WFS
data
servicesstandards
providing (WS-I+)
data in common
data model GML – Geographic
Markup
Language
– Open
Geographic Standards (OGC and ISO/TC-211)
behavingofastwo
mediator
and
services.
• •Consists
types
ofannotation
online services
• WMS
and WFS
have
their own
typeand
of capability
metadata
defined
by Open
–
Web
Map
Services
(WMS)
Web
Feature
Services
(WFS)
Geographic specs.
And two types
of data:is done through “getCapability” service interface.
• • Inter-service
communication
– Binary
data –map
images (provided by WMS),
• UDDI
based registry
services.
• Components
are Web Services
all control
through
SOAP messages
– Structured-data
–GML :and
content
(coregoes
data)
and presentation
(attribute
geometry
elements)
(provided by WFS)
• XML-based
queryand
language
(standard
schema)
Relation of the components and data flow:
Binary
data
w
s
d
l
getCapability
getMap
getFeatureInfo
WMS
GML
rendering
GIS
GML
w
s
d
l
WFS
(mediator)
getCapability
getFeature
DescribeFeatureType
6
Capability-based Federation of Standard GIS
Web Service Components
WSDL
Aggregating
WMS
(Federator)
Web Map
Client
Interactive
map tools
Stubs
Stubs
HTTP
SOAP
WSDL
Capability.xml
WSDL
Capability.xml
WFS
+
Seismic Rec.
WFS
+
State Bounds
“REST”
Capability.xml
WMS
…
+
OnEarth
Google Maps
• Built over the proposed standard
Web Service components and
common data models
– MMS, WFS, and GML
• Federation is done by aggregating
GIS Web Services’ capabilities
metadata
– Inspired from OGC’s cascading
WMS
• Unified data access/query/display
from a single access point
• Providing application-based
hierarchical data definitions
– layer based data and service
(WMS and WFS) compositions
• Capability is basically a metadata
about data+service:
– Server’s information content and
acceptable request parameter
values
7
Unified Data query and display over integrated data-views
•• Step-2:
time
– green
and display
Step-1: (Run
(Before
run
time –lines)
blueUsers
lines access/query
in the figure)Federator
data
sources
from a single
access point(WMS
(federator)
overproviding
search
for standard
WS components
or WFS)
required
layers and
organize them
one aggregated
integrateddata
data-views
(multi-layered
mapinimages).
capability
file.
• Some layers
are provided in binary map images (layers from WMS), and some
– According
layers are rendered
to the from
standard
GML which
WMSis capability
provided by schema
WFS.
definition
• Capability
Users interact
with the system
through generic
Interactive Map
Tools. service
–
metadata
are collected
by getCapability
standard
• interface
Enables users to query the map images based on their attributes and features
–
MapAccess:
Tools There
gets the
from
• Interactive
On Demand Data
is noaggregated
copying of thecapability
data at anymetadata
intermediary
Federator
interface
(1) Consistency and autonomy.
places. Datathrough
are kept atservice
their originating
sources.
Aggregated Capability
WMS
Integrated data-view: b over a
Browser
Browser
Events:
- Move,
- Zooming in/out
- Panning (drag-drop)
- Rectangular region
- Distance calc.
- Attribute querying
Event-based
Interactive
Map-Tools
b
a
JPL at California
1
WFS
Federator
2
3
a. NASA satellite layer
b
a
WFS
b. Earthquake-seismic data
CGL at Indiana
1. GetCapability (metadata data+service)
2. GetMap (get map data in set of layer(s))
3. GetFeatureInfo (query the attributes of data)
8
Why Capability metadata
• Web Services provide key low level capability but
do not define an information or data architecture
• These are left to domain specific capabilities
metadata and data description language (GML).
• Machine and human readable information
– Enables easy integration and federation
• Enables developing application based standard
interactive re-usable tools
– for data query display and analysis
– Seamless data/access/query
9
Designs, measurements and
analysis
10
Performance Investigation
• Interoperability requirements bring up some compliance
costs:
– Common data model (GML)
– Web Services (SOAP protocol for communication)
• Approaches: Enhancing the GIS systems’ responsiveness
– Data transfer and rendering
• Streaming GIS Web Services (1)
• Structured/annotated GML data rendering (2)
– Federator-oriented approaches
• Pre-fetching (3)
• Client-based caching (4)
• Query decomposition and parallel processing (5)
• Testing with large scale Geo-science applications
– Earthquake forecasting (PI),
– Virtual California (VC)
• Aim: Turning compliance requirements into competitiveness
11
(1) Streaming Data Flow Extension to
GIS Web-Services
• Concern is large-sized XMLstructured data transfer
• Approach is that responses are
chunked into parts and streamed to
client as the answer comes.
registry
UDDI
w s d l
Web Services’
publish-find-bind
triangle
2
Subscriber
client
GML
6,000
getFeature
35,000
(topic, IP, port)
Time - msecs
(A)WMS
Average Response Times
• Enables
client to
Streaming vs.DB
Non-Streaming
GML Data Capturing
1
4,000
4
w
s WFS
d
l
Publisher
server
GML
3,000
topic,ip,port
Measured Avg.
Response time
2,000
Narada
Brokering
Server
1,000
0
0
200
400
•
render map images
with partially returned data – no
need to wait for whole data to be
returned.
Provides better performance results
• Uses topic-based publish-subscribe
messaging systems for exchanging
SOAP messages and data payloads.
• SOAP is used
for negotiation (line-3)
Streaming
with standard
“getFeature” request
Non-Streaming
– Publisher information in triple (topic,
is1000
returned.
600 IP, port)
800
1200
• Data transfer is done between
publisher and subscriber 12
GML Data Size -KB
(2) GML Data Processing
• Processing XML data: Parsing and rendering to create map images.
• Two well-known approaches are document models (DOM) and push models
(SAX).
•
We use pull approach for XML processing:
– Parses only what is asked for
– No support for document validation (major gains of performance)
• Structural correctness of XML document
– Doesn’t build complete object model in memory (unlike DOM)
– Contents are returned directly to application from calls to parser (unlike SAX)
Time - msecs
[GML]  [Parsing / Validation]  [Geo-data extraction]  [Plotting]
GML rendering
by using DOM vs. Xpp
5,000
4,500
4,000
3,500
3,000
2,500
2,000
1,500
1,000
500
0
(1GB allocated VM)
DOM (dom4j)
dom4j
Data Size
Xpp
0
2000
(KB)
4000
6000
8000
GML Data Size -KB
10000
12000
Parsing +
Total
pull (Xpp)
Data
Total
Validation Rendering extraction Rendering
1
469.22
469.22
15.59
15.59
10
494.06
497.06
72.81
75.81
100
625.54
640.87
183.06
198.39
1,000
760.20
843.31
270.47
353.58
5,000
1,422.91
1,576.58
671.74
825.41
10,000
3,557.44
4,385.94 1,025.67
1,854.17
100,000
-- Out of Memory --
7,059.72 10,797.97
Analyzing Conventional OGC-GIS systems
and Baseline Performance Test
• Common/straightforward approaches are characterized as
– Stateless services
– On-demand data access/rendering,
– Single-threaded and no-caching
• Systems developed with Open Geographic Standards have:
– High degree of interoperability but poor performance results
Sample data:
Earthquake
seismic data
served in GML
Test Setup:
70
Thousands
(b). Map Rendering time
60
50
(a). Average Response time
40
(c). GML data capture time
Time - msecs
(d). Map images transfer time -Avg value is 48.53msec
Avg Resp Time (a)
30
(c)
map-rendering (b)
data capture
20
10
0
0
2000
4000
6000
8000
GML Data Size -KB
10000
12000
a= b+c+d
The performance cumbersome is -c> Query and data conversions and large
size XML data transfer.
(3) Pre-fetching
• Performance bottleneck:
– On-demand access to originating databases through WFS,
– Transmitting XML-encoded GML representation of data
• Solution:
– Periodically fetching the whole data before it is needed (so called pre-fetching).
– Databases are mapped to GML files and stored locally in the federator
– Successive on-demand queries are served by using pre-fetched data (red-curve)
• Pros/Cons:
– Removes the repeated resource consuming query/data conversions at WFS and
associated Databases.
– Gives the best performance outcomes for the in-frequently changing archived data,
– But, might cause consistency problem depending on the fetching periodicity and
data update periodicity
Users’ on demand access/query
Event-based
Interactive
Map Tools
Federator
or WMS
GML
Represents all the data
at the database and their
associated attributes
WFS
Any-data
GetData in GML
FETCH
Federator Local
File System
Temp
Storage
NB
Periodically runs and
maps databases into
GMLs , and stores locally
15
Performance Comparison :
Pre-fetching vs. Straightforward On-demand Fetching
Map rendering over pre-fetched data at run-time:
•
48.53msec (included into the table values)
Time for rendering map from
pre-fetched data -GML
•
Performance tests are done with
earthquake seismic data records
Pre-fetching (independent of runtime):
– Earthquake data in Database is routinely
Federator
mapped to GML and kept at federator
or WMS
– Pre-fetched GML size is 127MB.
Comparison of the Average Response Times
Event-based
Interactive
Map Tools
Pre-fetching systems vs. On-demand fetching
systems
• The
response
70,000
Avg Response time 60,000
Time - msecs
50,000
GML
Pre-fetched GML -in
federator’s disk space
Requested Avg. Resp.40,000
Time with Avg. Resp. Time with
GML MB
On-demand
Pre-fetched data
30,000
0.01
1,808.13
7,576.46
•
20,000
0.1
2,635.46
7,426.86
•
0.5
5,001.29
7,537.04
10,000
1
8,225.73
7,742.04
0
5
33,419.31
8,460.56
•
0
2
4
6
8
10
64,506.78
8,480.46
GML Data Size -MB
50
316,906.00
11,197.08
100
643,344.00
12,304.99
Details for the on-demand performance
analysis are given in Slide-14
times seem very close
in case of pre-fetching
– No matter how much the requested
data sizes, Every time request comes,
map is rendered from the same size of
pre-fetched GML data stored at
federator
Pre-fetching
– Dominating performance bottleneck is
On-demand
removed.
No need to go through the
WFS to get the data from database.
Threshold value: 500KB of data
For 100MB, pre-fetching is about 50
times faster.
The larger the data size the higher
12
the 10
performance
gains.
Enhancements over
On-demand Fetching and Rendering
• Pre-fetching is very fast and a straightforward approach, BUT
– Might cause inconsistency
• Intermediary storage of data’s copies at federator,
• On-demand (just in time) fetching enables
– Keeping the data at their originating sources all the time
– Scalability, autonomy and easy data maintenance.
• It has performance bottleneck to access/query the federated
heterogeneous data sources through WFS-based mediation.
– Time consuming request/response conversion
• (Request): GetFeature request to SQL,
• (Response): Relational tables to GML
– Transferring XML-encoded GML data
• Enhancement Approaches:
– Client-based caching
– Parallel processing through attribute-based query decomposition.
17
(4) Client-based Caching
• Makes stateless GIS Web Services stateful
• Removes repeated time and resource consuming processes
• Helps sharing the workload as equal as possible for the most
efficient parallel processing
• Each client has different interest of regions of data sets
(formulated-queried as bbox), and separate caching area allocated.
• Application of working-window and locality principles into map
images rendering
• Clients are differentiated according to the client assigned session-id
parameter in the header of queries.
• Federator always keeps the least recently-used data sets for each
client separately.
• Brings up some overhead to keep up working-window and for each
client.
18
Brief Architecture
Server-side Create identity card. Update at every request from the client
• FormerRequest Class
String uuid;
/*unique-user-id*/
String bbox;
/*bounding box of the user’s last request*/
Double density;
/*data size falling into per unit square*/
Vector [] feature_data;
/*geometry elements of the last request*/
Register to client table
Client-side
uuid-1
uuid-2
…..
FormerRequest-1
FormerRequest-2
……
Set identity to message header
ClientWSStub binding;
binding = (ClientWSStub ) new ServiceLocator().WMSServices( servaddress));
String sessionID = session.getid(); //uuid-1
String channel_name = “getMapChannel”;
/*Add SessionID to the SOAP message’s header*/
binding.setHeader(service_address, channel_name, sessionID);
19
Map mymap = binding.getMap(request);
Comparing with Google’s Caching
and Map Rendering Approach
• Google-like map servers are fast because
– They replace computation with storage.
– Pre-making all images and cut up into tiles
– They formalize the accepted requests in terms of parameters, and responses in
terms of the tile compositions.
• Google’s approach is good for only the client-server based applications
–
–
–
–
Their approach is static and central.
In large scale applications it is impossible to cache whole data
There is always a limit on storage and computation capabilities
It can’t be applied to distributed dynamic data rendering and extensible
applications.
• We do fine-grained dynamic information presentation enabling attributebased data querying and interaction from a single access point over
integrated data-views in multi-layered map images.
• Client-based caching enables
– Dynamic and flexible map rendering based on layer specific attribute-based
querying/rendering of data(such as magnitude values of earthquake seismic data)
– It enables autonomy of data sources and easy data maintenance
20
(5) Parallel Processing through attribute based
query decomposition
Attribute is BBOX defining the
ranges for the requested data
in the main query getMap
DB
DB
WFS
WFS
4 possible positions of main
query to the cache:
Step-4: Worker threads capturing
the GML data in parallel
GetFeature1
. . . .
Step-3: Main thread distribute
GetFeature-n the GteFeature requests to the
worker threads
1
R1
R3
R2
R1
2
R4
bbox1 bbox2
. . . .
bboxn
Main query BBOX =
bbox1+bbox2+…+bboxn
Step-2: Bbox is an attribute
defining range queries
3
Step-1: Cached data extraction and
partitioning of the main query bbox
Questions:
1. How to find best efficient partition-number
2. How to assign the partitions to worker nodes
Cached
Data
Main
Query
R1
R2
4
Sample GetFeature
request to get
feature data (GML)
from WFS.
-110,35,-100,36
GFeature-1
-110,36,-100,37
GFeature-2
-110,37,-100,38
GFeature-3
-110,38,-100,39
GFeature-4
-110,39,-100,40
GFeature-5
Partition list as bbox values for
sample case :
- Pn=5
- Main query getMap bbox
110,35 -100,40
22
Challenge: Geo-Data Characteristic
• Geo-data is characterized as
un-evenly distributed and
variable sized according to
(c, (b+d)/2)
their locations attributes.
(c,d)
R3
(c,d)
R2
(c, (b+d)/2)
R1
(a,b)
R4
((a+c)/2, b)
(1)
(a,b)
– Ex. Human population
((a+c)/2, b)
(2)
• A point data is described
with location attribute
– (x, y) coordinates.
• Need for advanced techniques for
parallel processing and workload
sharing !
• Linestrings, polylines,
polygons etc are defined as
set of points.
• Data sets falling into a
queried region is formulated
as bounding box (bbox)
– Coordinates of a rectangle
(a, b, c, d)
23
Partitioning techniques for Query Decomposition
• 1. Blind partitioning
–
–
–
–
For the first time queries
Uses static/default partitioning number
Costs un-necessary partitioning overheads
Not efficient
• 2. Smart partitioning (next-slide)
–
–
–
–
As a solution to the sharing of unpredictable workload
Utilize client-based caching and
FormerRequest Object giving session information
Utilize locality principles and working-window to find out the best efficient
partition number
• Partitions’ assignment: Threads are assigned in round-robin fashion
– Initially every worker node (WN) is assigned equal #of partition (share)
– If partition number (PN) can not be divided evenly then the remaining
partitions (rmg) are re-distributed to the worker nodes
24
Smart Partitioning through Client-based Caching
• Aim: Determining the most efficient partition number to get best
performance result from parallel processing
• Based-on the locality principles.
– Assumption: successive requests have similar data density
– Data’s density is measure of data size falling into per unit square.
– Example: Human population data : no population on the ocean, and urban
areas have higher population than the rural areas.
• Brief algorithm:
– Each layer on which partitioning will be done has a threshold value predefined.
– Threshold value helps finding the largest area in bbox to be assigned.
– Largest area changes depending on the density of the data last time
requested
• Density is obtained from the FormerRequest object for that client
Static – pre-defined
From Client-based caching
FormerRequest object
If >= 2, then partition
25
Performance Test Setup
• NASA Satellite maps are provided by WMS from NASA’s OnEarth project.
• WFS servers, federator server and event-based interactive map tools are in
Indiana University Community Grids Labs.
• Tests are done in Local Area Network (LAN) by using grid-farm machines;
gf12,15,16,17,18,19.ucs.indiana.edu.
• Grid-farm machines have 2 Quad-core Intel Xeon processors running at
2.33 GHz with 8 GB of memory and operating Red Hat Enterprise Linux ES
release.
Binary map
image
1
JPL
California
GetMap
Binary
map
image
Federator
GML
2
1
1: NASA satellite
map images
2: Earthquakeseismic records
WFS-1
2
GetFeature
Browser
Eventbased
dynamic
map
tools
WMS
NASA Satellite
Map Images
WFS-2
2
.
.
WFS-6
2
DB1
DB2
Earthquake
Seismic records
DB6
CGL
Indiana
26
Parallel & On-demand
Time - msecs
Thousands
With Blind Partitioning
Comparisons of response times based on
On-demand approach
70
• The larger the data size the
higher the performance
gains
single-thread/mainquery
2-partitions
10-partitions
20-partitions
60
50
– As the data size falling in
a specific range query
increase, the possibility of
equal sharing increases.
40
30
• From the figure it seems
partitioning into 10 or 20
give the best results, but
20
10
0
0
2
4
6
8
GML Data Size -MB
See next slide as an
illustration of need of
using smart partitioning
The number of worker WFS : 6
10
12
– What about relatively
small sized data rendering
– What partition number
gives the best result for a
specific range and data
sizes
Partition Numbers : 2, 10, 20
27
Parallel & On-demand
Response times
with blind partitioning
9
Response times
with smart partitioning
9
8
7
6
5
4
3
2
7
6
3
0
1.00
1.20
2 2
2
0
0.40
0.60
0.80
GML Data Size -MB
no-cache
10
4
1
0.20
10
5
1
0.00
single-thread
smart-partitioning
processing from cache
8
single-thread/mainquery
2-partitions
10-partitions
20-partitions
Time - msecs Thousands
Time - msecs Thousands
With Smart Partitioning
full-cache
0.00
i
0.20
0.40
0.60
0.80
GML Data Size -MB
1.00
1.20
: Best partition/thread numbers
Actual performance results are much better, because of the client-based caching.
Depending on the cache and main query overlapping size, response times changes between
orange-line and brown-line in the second figure
 Brown-line shows the best case in which the whole main query range falls in cached data ranges.
The number of worker WFS : 6
Partition Numbers : 2, 10, 20
28
Overhead Timings resulting from parallelization
3. Merging
1. Partitioning into 5:
0-2, 2-4, 4-6, 6-8, 8-10
Query for
Range:0-10
2. Query Creations for partitions:
Q1, Q2, Q3, Q4, Q5
Queries/responses for partitioned ranges
Time - msecs
Overhead Timings :
Range query:
Sample range: 0 to10
Parallalization overheads based on
different partitioning levels
2,000
1,800
1,600
1,400
1,200
1,000
800
600
400
200
0
1.
2.
3.
0
WFS
WFS
WFS
partitioning
subquery creation
merging
5
10
15
20
Partition Number
25
30
35
illustration of overheads
DB1
•
•
•
•
DB1DB1
Overheads: Query partitioning, sub-query creation, and merging results to sub-queries.
Partitioning: Defining the partition number and cutting the main query range into that
number of pieces in the form of bounding box (bbox) values (range query attribute)
Sub-query creation: Create corresponding XML-based query (getFeature) for each partition
in the partition list to fetch the remote GML data from WFS.
Merging: Aggregating the results to sub-queries and creating one complete map images 29
as
an answer to main query
Conclusions – Performance
• Streaming data transfer techniques allow data rendering even on partially
returned data.
• Pull parsing results in best outcomes for XML encoded GML data rendering Eliminating the requirement of data validation.
• Federator’s natural characteristic allowed us develop advanced caching and
parallel processing designs.
• Pre-fetching and parallel-processing techniques are mutually exclusive.
• Best performance outcomes are achieved through pre-fetching but can
cause data inconsistency.
– Triggering periodicity must be defined carefully.
• Parallel-processing techniques’ success is based on how well we share the
workload to worker nodes.
– Un-evenly distributed and variable sized geo-data characteristics.
• Client-based caching enables us efficient workload sharing for the best
efficient parallel processing
– Besides enabling removing time and resource consuming repeated jobs.
• We saw that
– Application of working-window and locality principles by means of client-based
caching, and
– Parallel processing through attribute-based query decomposition
30
Helped us increase the system responsiveness to a greater extent.
Conclusions – Framework
• Fine-grained dynamic information presentation through a federation
framework enabled us heterogeneous data sources to be queried as a
single resource over integrated data-view in multi-layered map images
– Autonomous local resources controlling definition of data
– Removing the burden of individually accessing each data source with ad-hoc
query languages.
• We showed that Open Geographic Standards (OGC) can be applied
together with Web Service standards.
– We converted HTTP/GET-POST based queries into XML-based queries by
developing standard schemas --compatible with the standards.
– We also extended the standard service definitions with streaming data transfer
capabilities by using publish-subscribe based messaging middle.
• Easy extension with new data and service resources
– Open Geographic and Web Service standards
• No physical data integration
– Just-in-time or late-binding federation
– Data always is kept at its originating resource
– This enables easy data-maintenance and high degree of autonomy
• Seamless interaction with the system through integrated data views in
multi-layered map images
– Enables interactive feature based querying besides displaying the data
31
Contributions
• A federated Service-oriented Geographic Information
Systems framework
– Integrating Web Services with Open Geographic Standards to
support interoperability at both data and service levels
– Production of knowledge from distributed data sources in multilayered map images.
• Hierarchical data definitions through capability metadata federations
• Fine-grained dynamic information presentation
• Enabling unified interactive data access/query and display from a single
access point through federator.
• Investigated performance efficient designs and did detailed
benchmarking
– Streaming GIS Web Services
– Federator-oriented high-performance design techniques
• Pre-fetching
• Client-based caching : Working-window and locality principles
• Parallel processing through attribute-based query decomposition over
un-predictable workload sharing
32
Acknowledgement
• The work described in this presentation is part
of the QuakeSim project which is supported
by the Advanced Information Systems
Technology Program of NASA's Earth-Sun
System Technology Office.
• Galip Aydin: Web Feature Server (WFS)
33
Thanks!....
34
BACK-UP SLIDES
35
•
Capability-based Federation of the standard Web
Service Components
Application-based
data:
Built over the
proposed standard hierarchical
Web Service components
and common
data models
[Application]- Pattern Informatics
• Unified data access/query/display
from a single
access
point
– [Layer-1] State-boundary
over
Satellite
• Providing application-based
• [Data-1] hierarchical data definitions
– layer based data and –service
(WMS and
WFS) compositions
State-boundary
(WFS-1)
• Federation is done•by[Data-2]
aggregating GIS Web Services’ capabilities metadata
Satellite-Image(WMS-2)
• Capability is basically a–metadata
about data+service:
– [Layer-2]
– Server’s information
content and acceptable request parameter values
• Google
map (WMS-1)
Capability Federation
a, b, c and d
Map Rendering
–User[Layer-3]Earthquake-Seismic
Portal
• [Data-1]
WMS
Federator
WMS
• Earthquake-Seismic(WFS-3)
c
2
Interactive
Map-Tools
Browser
2
1
a
1
3
2
1
WFS
WFS
d
WMS
1. GetCapability (metadata data+service)
Sample Layers for PI:
a.
GIS
Events:
- Move,
- Zooming in/out
- Panning (drag-drop)
- Rectangular region
- Distance calc.
- Attribute querying
WFS
b
b.
c.
d.
NASA satellite
layer
Earthquakeseismic layer
Google Map Layer
State-boundaries
Layer
2. GetMap (get map data in set of layer(s))
3. GetFeatureInfo (query the attributes of data)
36
Hierarchical data
Integrated data-view
1
2
3
1: Google map layer
2: States boundary
lines layer
3: seismic data layer
Event-based Interactive Tools :
Query and data analysis over integrated data views
37
38
Hierarchical data / Integrated data-view
For IEISS Geo-science Application
Application-based hierarchical data:
[Application]- IEISS
– [Layer-1] Gas-pipeline over Satellite
• [Data-1]
– Gas-pipeline (WFS-1)
• [Data-2]
– Satellite-Image(WMS-2)
– [Layer-2]
• Google map (WMS-1)
– [Layer-3]- Electric-power
• [Data-1]
• Electric-power(WFS-3)
39
GetCapabilities Schema and Sample Request Instance
40
GetMap Schema and Sample Request Instance
41
42
Event-based Interactive Map Tools
• <event_controller>
–
–
–
–
–
–
–
–
<event name="init" class="Path.InitListener" next="map.jsp"/>
<event name="REFRESH" class=" Path.InitListener " next="map.jsp"/>
<event name="ZOOMIN" class=" Path.InitListener " next="map.jsp"/>
<event name="ZOOMOUT" class="Path.InitListener" next="map.jsp"/>
<event name="RECENTER" class="Path.InitListener“next="map.jsp"/>
<event name="RESET" class=" Path.InitListener " next="map.jsp"/>
<event name="PAN" class=" Path.InitListener " next="map.jsp"/>
<event name="INFO" class=" Path.InitListener " next="map.jsp"/>
• </event_controller>
43
Sample GML document
44
Sample GetFeature Request Instance
45
A Template simple capabilities file for a WMS
46
Generalizing the Problem Domain
• Query heterogeneous data
sources as a single resource
Client/User-Query
– Heterogeneous: local
resource controls definition
of the data
– Single resource: remove the
burden of individually
accessing each data source
Integrated View
• Easy extension with new
data and service resources
• No real integration of data
Mediator
DB
Mediator
Files
Mediator
WWW
Data in files, HTML, XML/Relational Databases,
Spatial Sources/sensors
– Data always at local source
– Easy maintenance of data
• Seamless interaction with
the system
– Collaborative decision
makings
47
Generalization of the Proposed Architecture
•• GIS-style
information
can be redefined
We need
to definemodel
Application
Specific: in any application areas
such as Chemistry and Astronomy
• Federator federating the capabilities of distributed ASVS
– Application Specific Information Systems (ASIS).
and ASFS to create application-based hierarchy of
• We need
to definedata
Application
Specific
distributed
and service
resources.
– Language (ASL) -> GML :expressing domain specific features, semantic of
• Mediators:
Query and data format conversions
data
–• Feature
Service (ASFS)
-> WFStheir
:Serving
data in common
language (ASL)
Data sources
maintain
internal
structure
–• Visualization
Services
(ASVS) -> WMS : Visualizes information and provide
Large
degree
of
autonomy
a way of navigating ASFS compatible/mediated data resources
No actualmetadata
physicalfordata
–• Capabilities
ASVSintegration
and ASFS.
Such as filter, transformation, reasoning, data-mining,
analysis
Unified data
query/access/display
1
Federator
2
ASVS
3
Capability Federation
ASL-Rendering
Standard service API
4
Standard
service API
3
AS Services
(user defined)
Mediator
Messages using ASL
2
Standard
service API
AS
Repository
1
Mediator
ASAS
Sensor
Sensor
48
Contributions (Systems Software)
• Developing Web Map Server (WMS) in Open Geographic
Standards
– Extended with Web Service Standards and
– Streaming map creation capabilities
• Developing GIS Federator
– Extended from WMS
– Provides application specific layer-structured hierarchical data
as a composition of distributed standard GIS Web Service
components
– Enable uniform data access and query from a single access
point.
• Interactive map tools for data display, query and analysis.
– Browser and event-based.
– Extended with AJAX (Asynchronous Java and XML)
49