Alexandria on the Web

Alexandria on the Web

A Distributed Library Service for Spatial Data

Web Library Components

• User interfaces
  • browsers
  • HTTP/HTML
• Catalogs
  • query engines: SQL, Z39.50
  • extensible schema
• Repositories (storage)
  • handles: UR?s, kwoids
  • Internet bitstream: FTP
• Suppliers (ingest)
  • create catalog entries
  • preprocess holdings

Web Library Components

User Interface Issues

• Spatial data vs. HTML
  • no vector data presentation
    • need something like <VECTOR>, analogous to <IMG>
  • poor spatial data entry
    • need multi-click imagemaps (raster)
    • need "scribble" entity (vector)

User Interface Issues

• Spatial data vs. HTTP
  • stateless
    • workaround: multi-page queries with hidden state
      • e.g. Xerox Map Browser
  • small, fast transactions
    • need progressive delivery of big stuff
    • generalization of interlaced GIF gimmick?

User Interface Issues

• Spatial data vs. Web browsers
  • helper apps are a short-term band-aid
    • only current way to handle vector data
  • extension mechanism 1: better browser-helper communication
    • Mosaic DTM extensions?
  • extension mechanism 2: programmable browsers
    • HTML + extension language: HotJava, Tecate, ...

User Interface Issues

• Alexandria November 1995 solution
  • HTML version of Rapid Prototype interface
    • forms
      • text queries
      • result selection: metadata records
    • imagemaps
      • spatial queries
      • result selection: thumbnails, footprints
  • Experiment with vector data presentation
    • rasterization
    • ArcView helper app

Catalog Background: Footprints

• Spatial projections
  • of library items
    • e.g. digitized map
  • of entities in world
    • e.g. river
• Indices into / transformations on
  • relevant library items
  • information about entities
• Representations
  • polygons
  • names
  • procedures

Catalog Background: Footprints

• Indexing
  • ?-trees
  • Full-text
• Creation / extraction
  • manual
  • digital data
  • ancillary information from gazetteer

Catalog Background: Gazetteer

• Mapping between authoritative place names and footprints
• Mapping is N:N
  • place name may have multiple footprints
    • e.g. discontiguous property
  • footprint may be associated with multiple places
    • e.g. bilingual names
• Standards
  • GNIS
  • BGN

Catalog Issues

• Query gazetteers
  • forward: where's place?
  • inverse: what's this?
• Query footprints
  • spatial indices
• URLs, URNs, handles, oids, ...
  • uniform IDs for remote holdings
• Multiple interfaces
  • HTTP
  • Z39.50
• Multiple catalogs

Catalog Issues

• Alexandria November 1995 solution
  • use current Sybase catalog
    • HTTP: CGI to SQL
    • Z39.50: (evaluating)
      • hook to National Spatial Data Clearinghouse
  • add a gazetteer
    • extend current schema
    • form (forward) and imagemap (reverse) queries
  • replace filenames with URLs
    • point to at least 1 significant remote collection
  • evaluate alternative DBMS
    • O2
    • Illustra

Storage Issues

• Spatial data are humongous
  • many satellite images >150 MBytes
  • 2M airphotos at ~25 MBytes == ~50 Terror-Bytes
• Alexandria November 1995 solution
  • distributed hierarchical storage
    • 150 GBytes disk (magnetic and optical) at UCSB
    • ~500 GBytes robotic tape at SDSC
  • simplified management
    • most data are write-once

NB: 1 TByte @ 1.54 Mbit/sec (DS-1) == ~2 months

System-Level Issues: Wavelets

• Reasons for use
  • progressive delivery and browsing
    • large image access
    • reconstruction of high resolution segments
  • content-based search
    • texture matching
  • (possible) compression

System-Level Issues: Wavelets

System-Level Issues: Wavelets

• User interface
  • deliver holdings at appropriate
    • resolution
    • size
  • rapid delivery of low resolution ("browse") images
  • image-match search
• Catalog
  • provides additional indexing method
  • managing / presenting wavelet-based metadata
    • e.g. texture "badges"

System-Level Issues: Wavelets

• Storage
  • hierarchical storage
    • low resolution -> fast
    • high resolution -> slow
• Ingest
  • processing requirements for initial wavelet decomposition

System-Level Issues: Wavelets

• Alexandria November 1995 solution
  • ingest some wavelet-encoded airphotos
    • big enough to be interesting
    • small enough to be tractable
  • metadata to describe wavelet encoding
  • helper app to display/save wavelet-encoded images