adding programspecificid to station search response JSON

[tomkralidis]

cc @ejwelton

When requesting https://oscardepl.wmo.int/surface/rest/api/search/station?programAffiliation=GAW, it would be valuable to have returned the programSpecificId to the response. While this information is available on a single station report endpoint (https://oscardepl.wmo.int/surface/rest/api/stations/station/161/stationReport), it would be valuable to have this on station search as well, to minimize numerous HTTP request/response back/forth.

Having said this, are there any API endpoints (or strategies) which provide search and response against full JSON station representations?

[joergklausen]

No such plans or strategies at present. In theory, the TT-OD should advise on such. I will pass this on to the OSCAR/Surface Application Board.

[joergklausen]

Endpoint https://oscardevt.meteoswiss.ch/surface/rest/api/search/wigos?WIGOSStationIdentifier={WSI} provides at least the mapping of a given WSI with any other dentifiers, e.g.,
https://oscardevt.meteoswiss.ch/surface/rest/api/search/wigos?WIGOSStationIdentifier=0-20008-0-JFJ.

[tomkralidis]

Thanks @joergklausen .

@ejwelton : I can add capability to pyoscar to add programSpecficId output, which would involve (under the hood) issuing an HTTP request for the result set, and then foreach station issue another query as per @joergklausen 's suggestions, then adding to the result set in pyoscar back to the user.

From initial testing, this capability takes an exhorbitant amount of time (minutes to complete a CLI call), so I'm hesitant. I could add a flag for the user to ask this from the CLI (given they are prepared to wait) if it's valuable to you?

[ejwelton]

This proposal does not address the original problem. The original problem referred to a program search not a station search. When a user does a program search with the API, a json is returned with a listing of sites affiliated with that program. Here is an example for MPLNET:
https://oscar.wmo.int/surface/rest/api/search/station?programAffiliation=MPLNET
Here is the json element for NASA Goddard as an example:
{
"id":161,
"name":"Goddard (MD)",
"region":"North America, Central America and the Caribbean",
"territory":"United States (the)",
"declaredStatus":"Operational",
"latitude":38.9900016785,
"longitude":-76.8300018311,
"elevation":100,
"stationTypeName":"Land (fixed)",
"wigosStationIdentifiers":[
{
"wigosStationIdentifier":"0-20008-0-GSF",
"primary":true
}
],
"stationTypeId":1,
"dateEstablished":"2000-11-13T23:00:00.000+0000",
"stationStatusCode":"operational",
"stationTypeCode":"landOceanSurface",
"stationProgramsDeclaredStatuses":"AERONET:Operational, GAW Regional:Operational, MPLNET:Operational"
}
This json contains almost all information necessary for a successful cross reference of OSCAR and Program information. However its missing the programSpecificId for the OSCAR station, this is program name for the site (which is often different than the WIGOS name, especially for contributing networks). I was asking to have the programSpecificId added to the program search json. Instead, the proposed solution simply creates another search option that returns even less useful cross reference between OSCAR and Program. For my own application for GALION search tool, I am saving an OSCAR station search json file for all sites (excluding ships,subsurface, etc), as well as saving the program search json file for all contributing networks. Then cross-referencing them in post processing, adding the programSpecificIds to all sites in the program json file. @tomkralidis, yes this adds CPU time and complexity, though not as slow as your approach with pyoscar since the station file is pre-downloaded. However, the added complexity and CPU cost is why I requested to add the programSpecificId to the program search results.

[tomkralidis]

@ejwelton thanks for the feedback. Note that https://oscar.wmo.int/surface/rest/api/search/station is the station search endpoint, to which programAffiliation is a search parameter. Having said this, I think best approach given the separation of concerns is for the OSCAR API to provide this information as part of the response.

[joergklausen]

@fstuerzl Can you have a look at this with Lucia and comment on any plans (if there are)?

[fstuerzl]

@tomkralidis, @ejwelton, we are considering this improvement for a new release or the next generation of OSCAR!

Please submit new requirements for OSCAR or GAWSIS (that are no WMDR issues) directly via the support form (https://oscar.wmo.int/surface/#/support or https://gawsis.meteoswiss.ch/GAWSIS/#/support) instead of the WMDR GitHub forum.

[joergklausen]

Issue expected to be handled by OSCAR team.