1 / 10

Polar Mapping Prototyping and the Lessons Learnt

Polar Mapping Prototyping and the Lessons Learnt. Shinobu Kawahito Remote Sensing Technology Center of Japan (RESTEC) in support of Japan Aerospace Exploration Agency (JAXA) WGISS-28 Pretoria. Overview of the Prototype. System Features.

manchu
Télécharger la présentation

Polar Mapping Prototyping and the Lessons Learnt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Polar Mapping Prototyping and the Lessons Learnt Shinobu Kawahito Remote Sensing Technology Center of Japan (RESTEC) in support of Japan Aerospace Exploration Agency (JAXA) WGISS-28 Pretoria

  2. Overview of the Prototype • System Features • OGC/WMS and other related standards based web mapping system • Interactive with distributed WMS servers • Serve images in polar specific projections • User Friendly • Easy to compare multiple images • Easy to view time dependent variations and to select a date of interest • Mapping Theme • The image applied in this prototype focuses on “temperature” • (to show Snow extent, Sea ice extent, etc)

  3. System Designing • User Friendly GUI design • (Requirements) • Multiple images be compared easily • (Solution) • Adjustable image transparency was introduced.Each of multiple images is sent independentlyfor GUI (not combined beforehand to one image) thereby allowing the GUI to change their respective transparency to answer the needs on the spot. • (Requirements) • Time sequential changes be shown easily and a date of interest be specified on the spot. • (Solution) • Added an indicator to “Date Control” for this purpose.

  4. Snapshot

  5. Snapshot

  6. Role of Tiers in producing an Overlaid Image GUI WMS Client WMS Servers Create One Final Overlaid Image Create Five Independent Images Overlay in GUI Overlay in WMS Client Maps Maps + AMSR Image (IC) AMSR Image (IC) + AMSR Image (SWE) AMSR Image (SWE) + AMSR Image (SST) AMSR Image (SST) + Others Others Transparency fot the three middle images is variable.

  7. Overlay in GUI - Five Map Layers and Data Categories Top Layer (Vector Maps) with transparent background 2nd Layer (Daily AMSR-E IC) with transparent background 3rd Layer (Daily AMSR-E SWE) with transparent background Overlaid Image 4th Layer (Daily AMSR-E SST) with transparent background 5th Layer (Other Images)

  8. Findings and Lessons Learnt • Better Portrayal with WMS + SLD • WMS servers which support OGC/SLD will change styles (width, color, symbol, etc) of features (points, lines, etc) dynamically answering user’s requests. Images from different resources can beharmonized by utilizing this ability. Original image provided by an NSIDC server Changes made on some features to follow SLD requests

  9. Findings and Lessons Learnt (cont’) • In which tier the portrayal be made • Evolved Web browsers and RIA allow various system configurations for performing interactive mapping and portrayal. • The portrayal includes : overlay images, draw lines, place marks, draw graphs .. • The tier to perform portrayal: • Server-sides are capable of complicated portrayal, but not so responsive to interactive manipulations as they should be. • GUI-sides provides a quick response once the required data are ingested, but may spend more time in retrieving the data. • Images containing a label • Projection conversion is a merit of WMS, but it may collapse some of the appearances; strings labeled to images in particular.

  10. Findings and Lessons Learnt (cont’) • “Capabilities Document” ( = WMS/GetCapabilities response in XML) • For time-series dataset such as AMSR-E daily data, a problem arises to decide which names shall be applied to <Layer>; dataset name or name of each data? • When dataset name is applied, GetMap requests will have a difficulty in identifying each of the data (such as partial scenes)unless vendor-specific parameters are used additionally. • When data name is applied, all the information must reside in a single document, which is not practical when a large number of data are applied in WMS servers. • In our prototype, AMSR-E IC (SWE, SST) has only one image per day. So, we have assigned dataset name to <Layer>, while Time parameter is used to identify each of the daily images in issuing/parsing a GetMap request. • Further, each <Layer> can contain items such as <MetadataURL>, <DataURL> which help in describing data and accessing real data. Dataset level or data level of these items should be consistent with the level of <Layer>.

More Related