Transcript Concurrent Web Map Cache Server A Vision for IndianaMap Zao Liu, Marlon Pierce, Geoffrey Fox Community Grids Laboratory Indiana University Neil Devadasan The Polis Center IUPUI October 27,

Concurrent Web Map Cache Server
A Vision for IndianaMap
Zao Liu, Marlon Pierce, Geoffrey Fox
Community Grids Laboratory
Indiana University
Neil Devadasan
The Polis Center
IUPUI
October 27, 2006
1-1
Where are we today?
 The current IndianaMap
http://129.79.145.5/arcims/igic/viewer.htm uses
data collected by the Indiana Geological Survey
(IGS)
 IGS periodically collects the best available State
and Federal data and authors the data on a central
web server
 The web service includes the 2005 Statewide
Orthophotography, INDOT and TIGER roads, USGS
10 foot contours, and Census boundaries
1-2
Where are we today?
 Most current detailed Geographic Information is
located with local government systems.
 Key data includes parcels, addresses, roads, and
infrastructure data
 This data is not readily available at a regional or
statewide level for decision making because of
technical limitations
1-3
Comparison of state and county data





10 foot contours (1990)
Missing local roads
No parcels
No point addresses
Jurisdictional boundaries (2001)
1 foot contours (2006)
Local roads (2006)
Parcels (2006)
Point addresses (2006)
Jurisdictional boundaries (2006)
1-4
The Polis Center Middleware Research
Neil Devadasan
The Polis Center
IUPUI
1-5
Many individual counties have web sites
When connecting to the service you receive all data not the
subset of data that you need (Indianapolis 100+ layers)
You have no control over the data that you retrieve and query
1-6
Combining data from multiple web sites
Depending on the characteristics of the web sites, combining
data may cause problems.
Leaking tanks (Indiana Geological
Survey Atlas of Indiana) overlaid
on Marion County Parcels
(Indianapolis GIS Web site)
Public Land Survey Sections (Indiana
Geological Survey Atlas of Indiana)
overlaid on Marion County Parcels
(Indianapolis GIS Web site)
Note: Parcels are obliterated
1-7
The Polis Center’s Distributed Web GIS
Middleware Research Strategy
.
To take advantage of this
highly accurate local data for
use statewide, a variety of
technical issues must be
overcome such as:
•Projecting the information to a
single coordinate system
•Standardizing symbology
•Retrieving individual Layers
1-8
Upper White River Watershed Alliance
http://www.whiteriveralliance.org/
1-9
IGIC IndianaMap Grant
1 - 10
Performance is an issue and thus
scalability may be limited
Performance is constrained by the performance of the
Individual servers
1 - 11
Federating, Tiling, and Caching Web
Map Servers
Zao Liu, Neil Devadasan, and Marlon
Pierce
1 - 12
Basic Problem: Data Federation
 Integrated GIS systems have obvious benefits but
inevitably systems are developed by various state
and local government agencies.
• Bottom up rather than top down
 This tends to give excellent local information but it
breaks down at the county boundary.
1 - 13
Considerations
 We assume heterogeneity in GIS map and feature servers.
• Must find a way to federate existing services
 We must reconcile ESRI, OGC, Google Map, and other technical
approaches.
• Make a clean distinction between clients and services
• Must try to take advantage of Google, ESRI, etc rather than compete.
 We must have good performance and interactivity.
• Servers must respond quickly--launching queries to 20 different map
servers is very inefficient.
• Clients should have simplicity and interactivity of Google Maps and similar
AJAX style applications.
1 - 14
Two Phase Approach: Caching and Tiling
 Federation through caching:
• WMS and WFS resources are queried and results are stored on the cache servers.
• WMS images are stored as tiles.
 These can be assembled into new images on demand (c. f. Google Maps).
 Projections and styling can be reconciled.
 We can store multiple layers this way.
• We build adapters that can work with ESRI and OGC products; tailor to specific
counties.
 Tiling:
• Client programs obtain images directly from our tile server.
 That is, don’t go back to the original WMS for every request.
• Similar approaches can be used to mediate WFS requests.
• The tile server can re-cache and tile on demand if tile sections are missing.
1 - 15
Some Technical Details
1 - 16
Storage of caching entire state
 Takes about 2.5-3 TB to store the entire state to zoom level 13 this way.
• There are 48410476 tiles for zoom levels 0-13, 162561384 tiles for 0-14
levels (nearly 12 TB).
• There are ~10 layers for each scale
 Aerial photo layer tiles take 25~30 KB
 Other layers (parcels, roads) are much smaller: 30~36 KB for all
remaining 9 layers per tile
 So we need almost 60KB * 48410476 tiles to store all map data
 Layers from Google (Hybrids, Street, Google Satellite) don’t need to
be cached.
• This is large but possible.
 We can easily spread our caching server over multiple hosts to store
even higher magnification scales.
 Efficient tiling storage can save disk space.
1 - 17
Current Progress
 Supports ESRI and OGC servers
• Now 17 counties is being cached. (Marion, Monroe are fully cached for 13
zoom levels)
 7 layers has been proved that they can be easily cached.
• Aerial photo layer, street , interstate layer, parcel, parcel ID, county
boundary, school).
• 3 more layers can be easily shown in client without caching. (Google Map,
Google Satellite, Hybrids).
 Querying parcel information across boundary. ( MARION-HANCOCK boundary)
 Support Geocode querying.
 Higher resolution than Google Satellite.
 Google Map-like interaction.
 Performance and Reliability.
• Cache Server still work even the county server doesn’t work.
• Much faster response to the client.
1 - 18
Tradeoffs of Caching
 Cached images must be store somewhere.
 More zoom levels, much more disk space is needed.
• For 12 levels, 500-600 GB.
• For 13 levels, 2.5-3 TB.
• For 14 levels, about 12 TB. (It may be not necessary to cache this
zoom level for all counties. We can cache this level for the
requirement of some place.
 Difficulty of map re-projection.
 Latency of keeping update with county servers.
 Inconsistencies in available layers.
1 - 19
Next Steps
 Caching more counties
• If county uses ESRI or OGC map server, current agent plugins can be used.
• We believe we can do the entire state
• We just don’t have the data.
 Find a way to keep current with county servers, especially when the county
server change layer id.
• Recent Monroe county example
 Establish a standard for layers. (Different county server use different name for
the same layer)
 The tiling services should support multiple server styles
• URLs for REST/AJAX style clients
• WSDL and SOAP for formal Web Services
• Support OGC and ESRI clients.
 Collaborative clients, dynamic layers (i.e. weather is an obvious addition).
1 - 20
Concurrent Web Map Cache Server
Zao Liu, Marlon Pierce, Geoffrey Fox
Community Grids Laboratory
Indiana University
1 - 21
Introduction
Geographical Information Systems combine online
dynamic maps and databases.
Many GIS software packages exist
GIS servers around state of Indiana



•
•
•

ESRI ArcIMS and ArcMap Server (Marion, Vanderburgh,
Hancock, Kosciusco, Huntington, Tippecanoe)
Autodesk MapGuide (Hamilton, Hendricks, Monroe, Wayne)
WTH Mapserver™ Web Mapping Application (Fulton, Cass,
Daviess, City of Huntingburg) based on several Open Source
projects .
These are not compatible
1 - 22
Map Server Federation
 Integrating GIS map servers is not trivial
 Our solution: create a virtual map server to act as an agent server
• Translates map requests from generic format to the format expected by the specific
map server.
• Provides a common language and programming interface for constructing clients
 The agent server by itself will work but performance is not good
• Must wait for slowest server to respond
• Failure prone: a county server may not respond at all
• Adds additional overhead for combining images
 Combining the agent server with a caching server solves these problems.
• Caches images for greater performance
1 - 23
Agent Server Architecture
County Server
Agent server
1 - 24
Caching Server
 The agent server runs offline to harvest map images from county map servers.
• Images are stored as tiles.
• Tiles at county boundaries may be combined for greater storage and performance
efficiency.
 Clients connect to the cache server instead of the agent server.
 The cache server constructs the requested image from pre-fetched tiles.
• Inspired by Google Maps approach
• Will enable more interactive clients (so-called AJAX programming)
 Image construction may be parallelized/multi-threaded for greater performance.
• Potentially takes advantage of new multi-core server architectures from Sun, Intel,
and AMD.
1 - 25
Tiling Example
Agent server requests entire county
maps for a particular zoom level and
then breaks up into tiles.
1 - 26
Tiling and Caching at County Boundaries
Bounding box requests across boundaries have
many empty tiles.
Marion
County
Hancock
County
Removing these empty tiles decreases storage
requirements and increases cache server performance
1 - 27
The combined map
1 - 28
Caching and Tiling Layers
 Map servers typically contain
base maps and optional layers
• Parcel boundaries, roads, and
township boundaries are layers.
 We cache each layer separately.
 Layers and base maps are
combined dynamically using
Java Advanced Image libraries.
• Common techniques
1 - 29
Tradeoffs of Caching
 Cached images must be stored somewhere.
 Currently, three counties (Hancock, Marion, and
Cass) are cached at 11 different zoom levels.
• Photo images, layers
• Takes 100’s-1000’s GB of storage
1 - 30
Caching the Entire State
 Takes about 500-600 GB to store the entire state to zoom level 10 this
way.
• There are 6047804 tiles for zoom levels 0-10, 15131920 tiles for 0-11 levels
• There are ~10 layers for each scale
 Aerial photo layer tiles take 60 KB
 Other layers (parcels, roads) are much smaller: 36 KB for all remaining
9 layers per tile
 So we need 96KB * 6047804 tiles to store all map data
• This is large but possible.
• Current commercial servers hosts like Sun T2000 can have 1 TB external
(RAID) storage.
 We can easily spread our caching server over multiple hosts to store
even higher magnification scales.
 Efficient tiling storage can save disk space.
1 - 31
Summary of Contributions
 Development of agent server to pre-fetch map images from
county map servers.
• Stores images as tiles.
• Removes redundant/empty tiles.
• Supports ESRI and OGC servers
 Development of caching server
• Provides a uniform mechanism for clients to interact with different
map servers.
• Increases performance and reliability
 Don’t have to go to source map servers for every request.
• Will enable more interactive clients
 Google Map-like interaction
1 - 32
Demonstration
1 - 33
Next Steps
 University-private sector partnership
• MOU’s with local government to implement system for
emergency response
• University and private sector funding to implement ESRI
or OGC map server functionality
 Develop Full Implementation System
• Finalize requirements
• Formalize programming interface using Web Service
standards (WSDL and SOAP)
• Develop functionality
• Investigate scalability and performance issues
1 - 34