Handle lat/long of dataset from fixed observatory

[rweigel]

We should have either a recommended or formal way of indicating this.

[jbfaden]

Is there a ticket on the metadata and metadataSchema? I can't remember if that was ever accepted.

[jbfaden]

See also #173

[jvandegriff]

For Earth science, this is such a common search constraint that we could consider adding it as a kind of optional standard constraint on the data query. There are several ways we could add ways to find data within a lat / lon region.

1. add a constraints item to the current capabilities/ endpoint and let servers indicate that they support (or require?) lat and non constraints when doing a data request: constraints: ['latLonRange'] (make it a list to allow for expansion?); then data queries can be(or must?) have a lat / lon box:
   hapi/data?dataset=global_ocean_temp&start=1970Z&stop=2025Z&latrange=-35,-20&lonrange=22,55
2. add a feature that lets users do a different kind of query just for time ranges; given a specific dataset, and a set of constraints (specified again in the constraints endpoint) this special query finds time ranges when the constraints are met; and example might be: hapi/constrainTime?dataset=global_ocean_temp&latrange=-35,-20&lonrange=22,55

Note too that most earth science apps (like Giovanni) now allow not just rectangular lat / non boxes, but more sophisticated shape types that have I think become standard..

[jbfaden]

A first step would be to standardize lat/lon for what we have. Right now you can have x_latitude and x_longitude in your info response, and just having "latitude" and "longitude" as official places to put this information would be useful.

I'd be nervous about adding lat/lon boxes to the search query, since there are other ways of requesting this that people use. For example, you might want to specify by radius from a point, or with more general polygons. I would wait until there is a specific server we are wrapping, so we have it (and maybe others) as examples of how this is constrained. Also I think we should consider allowing x_ request parameters, like .../catalog?x_latrange=-35,-20&x_lonrange=22,55.

[jbfaden]

For my Autoplot solstice release (https://autoplot.org/jnlp/20241221a/) I found a navy.mil server which returns sunrise and sunset for a given lat and lon, and I was planning on setting up a HAPI server for this. Is there a global_ocean_temp server? That would be a fun one too.

[rweigel]

Add

geoLocation = [long, lat, alt] see geoJSON (too domain specific?)

(could be two element if just lon and lat)

and

location: {

'point': [42.5, 140, 1000]
'components': ["long", "lat", "altitude (need to add as vector component)"]
'units': deg, deg, meters
'coordinateSystemName': 'wgs84',  // Is there a schema with this name?

or

'parameters': "param name" or array of parameter names

}

[rweigel]

What about the case where each parameter has a different location? Could allow at a parameter level. To consider.

[rweigel]

This addresses problem of serving simulation data.

parameter is data on 10x10x10 grid. Do we have 10x10x10 location objects?

Jon suggests adding pointList, grid2D, and grid3D. See also https://stevage.github.io/geojson-spec/

[rweigel]

location: {

'point': [42.5, 140, 1000]
'components': ["long", "lat", "altitude (need to add as vector component)"]
'units': deg, deg, meters
'coordinateSystemName': 'wgs84', // Is there a schema with this name?

or (if the location varies with time, i.e., you want a different location for each record)

location: {
'parameters': [ ["LocationGEO"], ["locationGSE"] ] # each of these has a set of vectorComponents
}
(note: 'parameters' is an array to be able to list the one location in different coordinateSystems

location: {
'parameters': [ ["LocationGEOX", "LocationGEOY"], ["locationGSEX", "locationGSEY"] ] # location parameters each contain one scalar element of a vectorComponents
}

These still assume one location per record, just different coordinateSystem representations for the location.

If you have multiple locations per record (example: 3 ground mag stations all in the same file), then this location block could be moved into the parameter level info, instead of the top level dataset level. That way the location (either fixed or time varying) is associated with the correct, specific parameters.

BUT: why not just require servers to separate these into different datasets (like we do for multiple time columns in a CDF)

So for now, we decided to not have the per-parameter location, while recognizing that if enough actual use cases / requests show up for it that we could easily add it later. The benefit is that for now, HAPi sticks with a simpler definition of dataset (measurements at one location), and this makes clients simpler.

[rweigel]

See #232 for altitude