Framework and ongoing development for the SECOORA Data Portal

Design guidelines - apply across each subsection

  • Initial page in each section is cached/preset/report-based
    • fast to render
    • shorter dev time
  • Deeper pages are dynamic/query-based
    • slower, but more flexible
    • longer dev time
  • Ideally the elements herein will be:
    • Light - quick to load and easier to maintain/develop
    • Fast - optimize old code if reused or evaluate speed from the start
    • Flexible - modular, to reuse/bundle across the site


Data Portal entry page

1. Explore / Visualize section

2. Access / Download section

3. Monitor / Metadata section

Brainstorming

Perhaps a regional scale initially isn't the most useful scale? Good as a project overview/starting point, but most users want very localized information. So we need the ability to transition from the entire region to a single point or points of interest quickly. Easy to get to this level - imagemap down to station level in a single click? (NDBC model - image map driven with large well labeled symbols). Once scale and location of interest are reached -> bundle data: RSS, WFS, WMS

Scale transition also enables a data richness transition from a "by-variable" presentation (single variable layers across the entire region) to a "by-station" presentation (distinct stations and all data measured there)? And a corresponding change in temporal depth readily available: larger spatial scales = deeper temporal aggregations. Balance the richness of the 3 main data dimensions we offer control over - space, time, observed variable. How to hit that balance without overloading users or under-representing our data richness?

  • Large Scale (small area) = multiple vars, longer time
    • all vars and lots of timeslices and/or climatology
    • i.e. all conditions when I was there last week or before I go there tomorrow/next month
  • Small scale = single vars, thinner time slices.
    • what we do moderately well now

Paraphrasing some Jeremy big picture comments here: 

In general I'm trying to recycle development (Seacoos netCDF, ObsKML, Xenia, MapServer, WMS/GetFeatureInfo, Openlayers)
 
  I'm hoping that we'll be able to move more in a data content development direction with new data falling into the buckets of:
    * raster imagery (remote sensing)
    * shapefiles and/or netCDF for hourly gridded coverages (hourly model data, hf radar, etc?)
    * in-situ platforms (Seacoos netcdf and/or obskml -> xenia sqlite db -> outputs)