International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B2. Istanbul 2004 
3. IMPLEMENTATION 
3.1 The Development of Geospatial Web Services 
To build the prototype system, we need to have the geospatial 
data and services be available over the Web. With the OGC 
and W3C standards that define the interfaces for accessing the 
geospatial data and the method for constructing chainable 
geospatial Web services, we have implemented a limited 
number of interoperable services, including WCSPortral 
service, reprojection, visualization, classifications, reformatting, 
subsetting, and georectification. Those services are 
implemented with standard interfaces defined by OGC for 
taking coverage data from coverage servers or from the output 
of other services as the inputs. 
WCSPortal service has been built first because the OGC Web 
coverage service (WCS) [OGC, 2003] provides a way to access 
and fetch geospatial data online [ ]. This WCSPortal service is a 
wrapper of WCS. It uses the GET method of WCS to get a 
coverage, save it locally, and return a URL for next step. 
Some very useful geospatial Web services such as reformatting, 
re-projection, sub-setting, geo-rectification are also being 
implemented. We can envision that more and more services and 
data will be available on-line in the near future. Those services 
will be stand-alone applications that can be used independently 
as well as the components for chaining. And the availability of 
services on line will also save many data users significan time 
in preprocessing the data for their own use. 
Some image classification services are also implemented for 
demonstration, such as “WICS Grass Unsupervised” , a 
SOAP based Web service. It uses Geographic Resources 
Analysis Support System (GRASS), an open source GIS 
system, to do an unsupervised image classification. We use one 
of our image classification services as an example to represent 
our service model and structure in Figure 2. The bottom part is 
the Image Classification Core Class. The basic classification 
algorithm is written in C (or another computer language). A 
Java class — ImageClassifier — provides Java access to those 
methods through the Java Native Interface .The Image 
Classification Core Class provide the functions to be used in 
classification services, such as supervised classification, 
unsupervised classification, and training. This Core Class will 
be called by the Web Image Classification Service. 
The Web Image Classification Service consists of two different 
implementations, the HTTP GET & POST version and the 
SOAP version. Both versions provide four operations, 
GetCapability, ^ DescribeClassifier,  TrainClassifier, and 
GetClassifier. Both versions accept the same parameters. The 
only difference is the protocol of request and response. 
The WICS Web interface is a Web application, including a set 
of html pages and a Java servlet. To the Web 
Classification Service, this Web interface is a client. A user can 
use these Web pages to submit a WICS request to a Web Image 
Classification Service (HTTP version) and specify whether he 
wants the raw data back or a picture result. The Web interface 
will generate pictures for the user if requested. Also the user 
can use other client tools to connect to both versions of the 
service. 
Image 
220 
The details for those services and the WSDL documents 
describing those services can be accessed by visiting our 
Website http://ws.laits.gmu.edu. 
  
p^ User i 
| | 
  
ARLE EER E = 3 
WICS web interface | Client 
(A Wek Application halt wath HTML page & Java Servier) | Software 
| | 
| i 
* Ed. v 
  
  
Web Image Classification Service 
  
HTTP GET & POST 
(eva Serviet) 
  
  
  
  
  
  
  
| 
| 
| 
i 
Image Classification Core Class | 
e i 
| 
| 
ImageClassifier (Java Class) 
  
Java Native Interface 
  
  
  
  
  
Figure 1. The Web Image Classifcation Service 
Figure 2. The Web Image Classification Service Structure 
3.2 The Development of the Prototype System 
The real power of a geospatial Web service system relies on its 
ability to chain individual standards-based services. A service 
chain is a service composite. Built on XML, SOAP, and 
WSDL, and originated from XLANG and WSFL, the Business 
Process Execution Language for Web Service (BPELAWS) 
specification is positioned to become the Web service standard 
composition language over all others. It supports two distinct 
usage scenarios: one is used to describe an abstract process 
which is non-executable and the other is to define an executable 
process. We adopt BPELAWS in our geospatial Web service 
system. We use BPELAWS to define a new Web service by 
composing a set of existing services ( a service chain). The 
interface of the composite service is described as a collection of 
WSDL portTypes, just like other Web services. The chain is 
executed with the BPEL engine. Figure 3 is the current 
prototype system structure implementation flowchart. 
i 
  
| 
—m 
| 
  
AllsIdaw 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
Figure 3. The Implementation of the Prototype System 
Internatio 
DG iiia 
The core 
compone 
Catalogue 
process 
construct 
will prod 
the servic 
through ! 
document 
are coup 
discovery 
publishes 
services ( 
theBPEL 
service of 
for users | 
interests. 
3.3 Hlus 
For demc 
system w. 
Francisco 
ways. Foi 
service cl 
the availa 
data for 1 
user sear 
service to 
unsupervi 
services | 
image (Fi 
files are 
WCSPort 
WICS G 
services r 
as a new 
define the 
engine ta 
result of 
invisible 
without tl 
the existi: 
know, on 
service in 
a chain | 
testing an 
  
{i GEOSPATIAL Wi 
# wms_Bosto 
3E WCS Rasta 
35 WCSPortalS 
x WICS Grass 
X5 Reprojectior