[API] Support custom parameter aliases

[jo-asplin-met-no]

For relevant endpoints, we introduce a query parameter param-aliases defined like this (typically as serialized JSON):

"<alias 1>": "<param name 1>"
"<alias 2>": "<param name 2>"
...

The effect of this is that the real/underlying parameter names are no longer exposed at all to the client, neither in input (query parameters) nor in output (response).

The motivation is twofold for a given client application:

1. Favorite/alternative parameter names can be used.
2. Irrelevant parameters can be hidden.

A primary case could be the GeoWeb client where a major obstacle to making use of E-SOH is the sheer number of parameters. Ideally, a GeoWeb user should be presented with just a single parameter for air_temperature. E-SOH currently provides 14 combinations of parameter names with air_temperature as the standard name component.

NOTE: to make this feature more convenient for a specific client (such as GeoWeb), we could offer a separate collection (typically called geoweb for the GeoWeb case) where the parameter alias mapping is hard-coded. The client then simply points to that collection instead of the main collection.

[Teddy-1000]

This sounds like a nice addition for people that want to reuse the software for other applications as well. I think the mapping should be able to take a list to it is easier to map multiple parameters to one alias. The main issue with this fix is that a data supplier, at least in the case of observations.meteogate.eu, any one the data supplier can alter their parameter names at any time, and it will be very hard to map all of these before they appear.

{ 
    "<alias 1>": [ "<param name 1>", "<param name 2>"],
    "<alias 2>": [ "<param name 3>"]
}

I think a some more work is needed on the issue of offering multiple collections, and how we want to use them. There is also a real need to be able to deliver more collections based on the type of data, i.e for the IoT data, we would like to have multiple collections based on the supplier of the data.

The whole case with consolidating parameters could also be solved by some sort of proxy API as well, where its only job would be to consolidate and transform the output from OASIS.

[lukas-phaf]

I have several comments/questions:

• This needs to be done consistently in the /collections metadata endpoints, the query parameters and the data endpoints (like /collections/observations/cube).
• For a simple parameter like air_temperature to work, an alias will have to point to different underlying parameters (level=1.5 and level=2.0), but this is already addressed in the comment above.
• I agree with @Teddy-1000 that this will be hard to maintain.
• If we map two paramaters with different levels (say 1.5 and 2.0), what level do we report in the collection and CoverageJSON parameters metadata? The data is now a mix.