NB: Please identify yourself or your institution as the source of a requirement in parentheses for each entry.

General

• Support registration of new stations (issue of WIGOS IDs) and updating existing records (GC) of GAW Contributing and other networks of trans-boundary extent. (source: WDCA/WDCRG). Support registration work-flow for stations applying for GAW affiliation similar to the one that already exists (source: GAWSIS - can the Secretariat act as a source of this requirement?!).
• GAW program-specific 3-letter station identifiers are deeply engrained in the community. The current GAWSIS acts as a broker for these identifiers. The new application should continue to manage these, i.e., provide a list to select from for new GAW stations (program/network: GAW global, GAW regional, GAW local). (source: SSC-EPAC)
• GAW stations (program/network: GAW global, GAW regional, GAW local) and stations operated by associated programs with similar objectives (program/network: GAW contributing, GAW other) should be visualized on an interactive map with symbols that allow distinction of stations according to operating status and network affiliation. Such a map should use an elliptic projection (such as Mollweide) for global scale and support polar projection for polar regions, and it should support flexible viewing (show/hide stations of certain programs, operating status). Users should be able to export maps for use in presentations and publications. (source: SSC-EPAC)
• (source: NASA/Judd Welton) GAW contributing networks remain stuck in a catch-22 situation. Contributing network agreements between WMO and the network host organization stipulate that the contributing networks use "reasonable effort" to provide their metadata to OSCAR/GAWSIS. This requirement is from WMO. However, contributing networks are by definition not run by national met agencies/departments. Creation of new stations in OSCAR requires action and approval from the national focal points, which are from the national met agencies/departments. As a result, contributing networks can only easily provide metadata for stations that already exist in OSCAR (by requesting program affiliation, which itself must be approved). Contributing networks often have many stations globally, and it is impractical and unreasonable to ask them to go through the laborious process of contacting each national focal point, including contributing network local/regional partners, and ask them to approve new stations. The focal points often are not aware of contributing networks, especially in GAW. The requirement to upload metadata to OSCAR is coming from WMO, and they must provide an easy process to meet their own requirement. Contributing network PIs and staff are not funded by WMO and should not be subject to added work loads due to an internal WMO issue. If this problem persists, then WMO could be considered in violation of the agreements, as I do not believe they are fulfilling their requirements with "reasonable effort". Below are extractions from one such agreement:
  • Contributing network will use reasonable effort to carry out the following responsibilities:
    • Maintain metadata description in the GAW Station Information System (GAWSIS) of all stations listed as contributing stations
  • WMO/GAW will use reasonable effort to carry out the following responsibilities:
    • assign the stations of the contributing network listed in Annex 2 status of the GAW contributing stations
    • store information about these contributing stations in the GAWSIS
    • update list of stations in GAWSIS database by the request of the contributing network coordinator

API

• Change architecture for updating records in OSCAR from "push by data centre" to "harvest by OSCAR". OSCAR surface metadata records have been notoriously difficult to update and maintain for the WDC nodes due to the functions provided by the API. If the data WDC node provides exact identification of all datasets, it should be easier for OSCAR surface to scan for changes in WDC data holdings relative to its own records, and update these. (source: WDCA)
• Support event driven workflow to enable "push" based publishing to OSCAR by data centres, in alignment with WIS2 architecture (Pub/Sub) (MSC/Tom Kralidis)
  • Provide a Pub/Sub server in alignment with WIS2 architectute to enable subscriptions by users (MQTT) (MSC/Tom Kralidis)
• Support endpoints for accessing a FacilitySet. Use case: A WCMP2 record of Canadian surface weather observations based on 800 stations should be able to point to a single URL in OSCAR/Surface that encompasses all these stations. (MSC/Tom Kralidis)
• Support OpenAPI as the API description language (MSC/Tom Kralidis)
• Support OGC API standards for the API interface (OGC API - Features/OGC API - Records (MSC/Tom Kralidis)
• The application should support data discovery AND access of surface-based (and ideally, co-located space-based) observations. Data access should be supported by producing lists of data URLs in the GUI as well as via API. (source: SSC-EPAC)
• I support these recommendations, and also do not see a conflict between building a pull capability (harvest) in OSCAR, the current push option, nor the request for push support specific to WIS2. To me these are different API options that should be considered, vs only one currently difficult API. (NASA/Judd Welton)

Encoding

• Provide a stable GeoJSON representation of WMDR1 as a more stable and streamlined representation. This would facilitate easier updating and maintenance of station information. (MSC/Tom Kralidis, NASA/Judd Welton):
  • metadata updates
  • API search
  • API get station report

GUI

• Suggestion for changes to the GUI for GAWSIS/OSCAR. These are favorable for the atmospheric composition community (NASA/Judd Welton)
  • Search results table should display listing of programs at each station in a new column. Or at least option to view that column (default could be not shown). It would be very useful for users to see this information. Building upon that request, perhaps a column with a listing of data variables available? Again, viewing that additional column of information could be an option not default. The motivation for atmospheric composition users is to determine what other useful observations are being made at a site(s) they are searching.
  • The search menu should also have both "and" & "or" search capability, especially when selecting multiple variables. It is unclear now what type of result is returned if a user selects more than one variable. Does the return include only sites that have at least one of the variables? or sites that only have all variables selected? This is critical to searching for so called super-sites that have a wide variety of colocated observations and variables.
  • It would be extremely useful for atmospheric composition users to be able to upload air mass trajectory files, KML path files, or a simple lat/lon type ascii file and have GAWSIS/OSCAR be able to extract all sites that meet colocation criteria along the trajectories/paths. Constituent transport is a key factor for our research and application areas we serve. This type of search capability is currently functional on the new WMO GALION search tool, but not public. I have it running successfully on a dev version of our search tool on the web (needs auth to access, which I can provide). Users upload the file, then specify a distance from track/path (say 100km) and provide a path resolution (say 1 km). The latter is needed since typical trajectory files are too coarse to use to match with sites, and the input paths need to be interpolated to a higher res for matching. Example of this tool on GALION is below, showing results from an uploaded HYSPLIT back trajectory file starting at Arenosillo Spain (which observed smoke plumes from fires in Alberta Canada in May). The smoke plumes were observed by various lidars along the trajectories.