ftiou, China 
ISPRS Workshop on Service and Application of Spatial Data Infrastructure, XXXVI(4/W6), Oct.14-16, Hangzhou, China 
37 
such as: route 
perhaps even 
ction between 
this kind of 
l portals. 
is emerging as 
itial data and 
is. Enterprise 
to help large 
sources. Such 
: automation, 
handling and, 
5 changing as 
data into the 
ewing data in 
le data within 
porate portal, 
urces into the 
iterprises are 
ommon field 
led. Valuable 
at - contract 
images, Web 
index spatial 
re now being 
:h electronic 
s to locations 
sers to search 
>n, regardless 
;ly important 
ils are: 
)f portals has 
evolution of 
1 functions to 
is a function 
leteness and 
jf the search 
ips the most 
f the catalog 
fte metadata 
the metadata 
his approach 
er field they 
5 is because 
:nt ways, and 
¡ness - some 
is. Catalog 
manner with 
As a result, 
i meant that 
iable results, 
retation and 
completeness of metadata records were perhaps feasible in 
strongly localised portals (say within a single organisation or 
department), but were unmanageable in larger regional, national 
or international infrastructure initiatives. 
In response, portal designers managers now often establish 
dedicated search indexes in addition to metadata catalogs. 
Tracking user behaviour on some of the larger portals shows 
that the majority of users search on relatively few metadata 
fields (ESRI, 2004). Portal managers can build consistent 
indexes that cater for the majority of users’ searches by strictly 
controlling the interpretation and quality of these relatively few, 
fields. Service providers may still submit full metadata records 
that can be used for reference. This approach makes it far easier 
for portal managers and service providers alike to maintain 
consistent catalog indexes. There is also increasing interest in 
adopting slim metadata standards such as Dublin Core (which 
has only 15 core elements in comparison to Federal Geographic 
Data Committee’s (FGDC’s) 334) for search purposes (e.g. 
CEN, 2003). In addition, update tools and procedures 
(automatic harvesting routines such as those based on the 
Z39.50 and Open Archive Initiative (OAI) protocols)) help 
service providers ensure that records are up-to-date and 
consistent. 
Another key consideration in the reliability (and speed) of 
search results is the flow of the query process. Another result of 
the adoption of distributed or federated catalog design used in 
early portals was that search requests had to be passed to 
multiple remote metadata index sites at the time of query. 
Though again elegant in theory, this proved difficult to 
implement in practice, as search speed and consistency were 
entirely dependent on the reliability of the networks connecting 
the metadata indexes. If a network or remote server had 
technical problems, search results would be incomplete. This is 
now changing, and most portals now store and process search 
request against centralised catalogs. This means that users’ 
searches can be processed within the portal architecture, and 
only when a user needs to access more detailed information 
about a search hit will an external request be sent to the service 
provider. This greatly reduced network traffic, and increases 
scalability, speed and reliability of portal searches. 
Finally, increasing attention is being paid to the search interface. 
Initial systems were strongly orientated towards the design and 
nomenclature of metadata schema. These often had little or no 
meaning for casual users. Defining search criteria could 
therefore be a confusing and frustrating process. Interface 
design techniques can help this. Portals now frequently include 
natural language search capability that hides technical jargon 
from the user, search parameters value domains, and combined 
spatial and textual search tools. In addition, channels help to 
identify and provide quick access to information on specific 
themes or topics. 
Speed: The ability of the portal to quickly retrieve and display 
search results and related information. For portals to be 
successful they typically must return search results within 2 to 5 
seconds. Achieving this relies on the shift to storing catalog 
indexes centrally within the portal infrastructure rather than in a 
distributed, federated model. A centralised model makes it far 
easier for portal managers to scale portals to accommodate 
growth in search requests and/or index size. Speed of display 
and operation may be enhanced by central storage of commonly 
referenced geospatial layers (such as those layers used in 
orientating users in the graphical search interface). 
Simplicity/Ease of use: The ability of the portal to support a 
wide range of users who are likely to have little or no specific 
training in GI or portal operations. Users must be encouraged 
to explore the portal through simple, powerful interface tools 
that guide users to the information they seek. Examples include: 
creating clear search flows as in Geospatial One-Stop’s “When, 
What, When” approach, and providing context sensitive 
dropdown boxes that are continually refined as the search 
progresses. Segregation of content into channels based on 
industry or theme also helps the user to rapidly navigate to data 
and information of relevance to them. Distributed management 
of portal information so that, for example focus groups manage 
channel design and content, help to ensure that channels are 
focused on requirements of the users they serve (note the 
management of information is distributed not the information 
itself). Intensive testing of portal design and continued 
monitoring of user navigation through the portal pages also help 
refine design. 
Application portals are becoming more and more powerful (and 
common), and help users to easily move from finding 
information to using it either within the portal itself or in the 
user’s own mapping clients. Application portals now now 
provide powerful mapping functions that range from relatively 
simple pan, zoom and identify functionality, to highly 
customized mapping interfaces that permit focused query and 
analysis. If service providers charge for the information services 
they offer, portals may also provide e-commerce and accounting 
functions that allow users to pay for services. 
Interoperability: The ability of the portal to retrieve and 
present services in different formats and integrate them directly 
with 3 rd party solutions. This includes being able to bring 
together data and functionality that may be hosted on 
completely different systems into a single application or map 
window. It also involves the ability to embed portal elements 
within 3 rd party software solutions, a development that has the 
potential to bring the power of spatial searches to a much wider 
audience. Many portals now provide map visualization tools 
that permit integration of live map services from multiple 
remote service providers. User can access services discovered 
through the portal either through light Web-based mapping 
clients provided by the portal, or (increasingly) directly from 
their own desktop applications. Such tools allow users to 
combine, view and work with multiple remote services - pulling 
a GeoMedia Web service from one site, base mapping stored in 
ESRI, ORACLE and Maplnfo formats from others. Different 
services can either be developed to conform with a single 
standard format (such as the Open Geospatial Consortium’s 
WMS or WFS formats), or increasingly use automatic server- 
side translation applications (for example those from SAFE 
software) that allow on-demand translation between numerous 
different formats. 
Industry standards such as extensible Markup Language 
(XML), Simple Object Access Protocol (SOAP) and Web 
Services Description Language (WSDL) underpin these 
developments and portals’ ability to integrate not only different 
geospatial technologies, but between spatial technology and 
wider IT systems.