Here's the problem we are facing:

"Parameters" are the field names for data that comes in from sensors. For a very simplified example, imagine a buoy in the water that collects only one parameter: "temperature". The problem is that each of the sensors is made by a different manufacturer, and though multiple sensors might be measuring "temperature", one sensor calls it "temp", another calls it "Temperature" and another might call it "F" or "C". This data is then uploaded to the API using the parameter spelling that the manufacturer used.

In the long-term, we are planning to address the issue on the API side - ie, before data gets uploaded, we'll check to see if "temp" should line up to an existing parameter before we create a new one (see Issue GEO-270).

In the short term, we have collected each of the known parameters and have started to determine which ones belong in the same category, which should be visible, etc. (see Issue GEO-277). It also relates to GEO-265; once the categories are established, we hope to be able to group them in the UI.

—

To get this working for alpha2, I created a static list of parameters (/public/data/parameters.json) and these are added to a backbone collection of models (app.collection.parameters). For the parameters that we didn't want to show up on the UI, I simply don't have them in parameters.json. Then, when I'm getting the parameters from the API, only the parameters we want get wired in, unwanted parameters are ignored. So the functionality is there, but we'll want to iterate in a couple ways:

1. We need to convert from using the GeoStreamService to using app.collection.parameters anywhere in the UI that shows a parameter (DetailView, ExploreView popups).
2. We'll also want to consider including all the parameters, but adding another field to parameters.json (possibly using something like "visible: true"). This would allow all the data to be connected to the sensor, but the UI would control which are visible. (this will need to be its own task).