Title: Concurrent Web Map Cache Server A Vision for IndianaMap
1Concurrent 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
2Where 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
3Where 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
4Comparison of state and county data
- 10 foot contours (1990) 1 foot contours (2006)
- Missing local roads Local roads (2006)
- No parcels Parcels (2006)
- No point addresses Point addresses (2006)
- Jurisdictional boundaries (2001) Jurisdictional
boundaries (2006)
5The Polis Center Middleware Research
- Neil Devadasan
- The Polis Center
- IUPUI
6Many 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
7Combining 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
8The Polis Centers 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
.
9Upper White River Watershed Alliance
http//www.whiteriveralliance.org/
10IGIC IndianaMap Grant
11Performance is an issue and thus scalability may
be limited
- Performance is constrained by the performance of
the Individual servers
12Federating, Tiling, and Caching Web Map Servers
- Zao Liu, Neil Devadasan, and Marlon Pierce
13Basic 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.
14Considerations
- 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.
15Two 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, dont 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.
16Some Technical Details
17Storage 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 2530 KB
- Other layers (parcels, roads) are much smaller
3036 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) dont 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.
18Current 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
doesnt work. - Much faster response to the client.
19Tradeoffs of Caching
- Cached images must be store somewhere.
- More zoom levels, much more disk space is needed.
- For 12 layers, 500-600 GB.
- For 13 layers, 2.5-3 TB.
- For 14 layers, 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.
20Next 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 dont 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).
21Concurrent Web Map Cache Server
- Zao Liu, Marlon Pierce, Geoffrey Fox
- Community Grids Laboratory
- Indiana University
22Introduction
- 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
23Map 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
24Agent Server Architecture
County Server
Agent server
25Caching 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-threa
ded for greater performance. - Potentially takes advantage of new multi-core
server architectures from Sun, Intel, and AMD.
26Tiling Example
Agent server requests entire county maps for a
particular zoom level and then breaks up into
tiles.
27Tiling and Caching at County Boundaries
Bounding box requests across boundaries have many
empty tiles.
Hancock County
Marion County
Removing these empty tiles decreases storage
requirements and increases cache server
performance
28The combined map
29Caching 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
30Tradeoffs 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 100s-1000s GB of storage
31Caching 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.
32Summary 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
- Dont have to go to source map servers for every
request. - Will enable more interactive clients
- Google Map-like interaction
33Demonstration
34Next Steps
- University-private sector partnership
- MOUs 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