move standard mapping names to client

[brandonmayer-zz]

For the testbed project, we were mapping cf-standard names to aliases for client applications.For sci-wms to be extensible, we need to only communicate cf-compliant names to clients whom can map and display whatever they like.

@cgalvarino we need to communicate this shift on the comt-ui. I can provide you with the mapping we currently use and you can incorporate that into your client.

@brianmckenna @kknee

[cgalvarino]

I'm not sure how that impacts the client. You're talking about a variety of new layer names? The only exception I make when reading through var names is when I look for var1,var2. That tells me that GFI's make up a component so that I will compute the dir and mag locally.

[brandonmayer-zz]

We're just looking to standardize communication between sci-wms and the outside world. On the backend, we were maintaining a mapping between CF-Standard names and the simple strings that were returned to the client for display. We want to modify the json thats returned to you on landing at the site such that only CF-Standard names are returned and when you issue a request, only CF-Standard names are used.

For example, where u,v was once returned by the initial json object, we'll return the CF-Standard names: eastward_water_velocity, northward_water_velocity. Then on the client side, if you want the badges to show u,v you just make the mapping on your side. But if you want an image of u,v you'll need to request from sci-wms a tile for eastward_water_velocity, northward_water_velocity.

I think this is as simple as keeping a dictionary of strings on your side for keeping track of the names you display and the info you get/send to sci-wms.

It will be the same deal for scalars. For example instead of us telling you there's a variable called ssh available for a given layer, we'll hand off the standard name sea_surface_height_above_geoid which you can display in a badge as whatever you'd like.

The idea here is that sci-wms could serve 100's of clients transparently and they can all display CF-standard variables with customized monikers but still communicate with sci-wms in a standard, coherent way.

[cgalvarino]

Ok. But if the standard names are fine to display on the client, I don't need the lookup right?

[brandonmayer-zz]

Of course. The point of this issue is that it should be 100% up to the client, we want to give you guys more control :)

Its just that @kknee wanted the aliases for the testbed project so instead of working with sci-wms on the backend, that display responsibility would be moved to the front.

I'll drop you a line when the json changes. It will take a while to implement. This is a sketch of the mapping we keep around to pass you the current information so you can start modifying the UI. For now you can ignore the scale_min/max stuff tho that might come into play in a different issue.

cfmap = { 'time': {'standard_name':'time'}, 'longitude': {'standard_name':'longitude', 'scale_min':'0', 'scale_max':'360'}, 'latitude': {'standard_name':'latitude', 'scale_min':'-90', 'scale_max':'90'}, 'ssh_geoid': {'standard_name':'sea_surface_height_above_geoid', 'scale_min':'0', 'scale_max':'7.0'}, 'ssh_reference_datum': {'standard_name':'water_surface_height_above_reference_datum', 'scale_min':'0', 'scale_max':'7.0'}, 'u': {'standard_name':'eastward_sea_water_velocity', 'scale_min':'0', 'scale_max':'2'}, 'v': {'standard_name':'northward_sea_water_velocity', 'scale_min':'0', 'scale_max':'2'}, 'hs': {'standard_name':'sea_surface_wave_significant_height', 'scale_min':'0', 'scale_max':'12'}, 'uwind': {'standard_name':'eastward_wind', 'scale_min':'0', 'scale_max':'80'}, 'vwind': {'standard_name':'northward_wind', 'scale_min':'0', 'scale_max':'80'}, 'salinity': {'standard_name':'sea_water_salinity', 'scale_min':'32', 'scale_max':'37'}, 'sst': {'standard_name':'sea_water_temperature', 'scale_min':'0', 'scale_max':'40'}, 'ubarotropic': {'standard_name':'barotropic_eastward_sea_water_velocity', 'scale_min':'0', 'scale_max':'2'}, 'vbarotropic': {'standard_name':'barotropic_northward_sea_water_velocity', 'scale_min':'0', 'scale_max':'2'}, }

[cgalvarino]

Do you imagine having this lookup live on the client hard-wired? Or are you going to make this available to me as a .json somewhere?

[cgalvarino]

Not hard-wired . . . I meant hard-coded.

[brandonmayer-zz]

I do think it should be a hard-coded list maintained on the front end.

I think all you need is a javascript function(s?) that return the cf-standard and scale ranges given an alias.

You can then pass the scale ranges via the style specification string we've been using. That would be the 4th and 5th (counting from one) elements of the style spec.

E.g: pcolor_average_jet_scaleMin_scaleMax_grid_False

[cgalvarino]

If it is hard coded here, what happens when you add something new like salinity on your side?

Are you still planning on giving me a default STYLE in the catalog?

[brandonmayer-zz]

I'll leave the catalogue as is so you'll get the same metadata as always. That data is aggregated by a seperate service I wrote to automatically query NGDC for available datasets so its ok that it knows something about the testbed project. SCI-WMS has the ability to store arbitrary json meta data so I just used that entry in the db to store the info parsed by the indexer.

Case in point, I'll still give a default style but we're moving away from needing one; the colormap can be selected by the user now using the ramp previews. The only other thing left the user needs to specify is to choose between a few option for 2d features e.g. vectors/barbs etc. which I'll get to shortly. Ideally (I'll start a new issue after we I finish what's already on my plate) we would also have sliders for data range & scale limits.

By adopting this approach, any cf-compliant name/layer that exists in the endpoint can be hit by sci-wms so we wouldn't add anything like 'salinity' on our end.

Rather than provide options for all cf-compliant layers in the ui @kknee only wants a subset of the total layers available for visualization on the frontend (which is how the cfmap was built). If she wants to add another, she'll tell you an alias/cf-standard name pair and you'll just add it to your hard-coded javascript. Sciwms will then transparently respond to the request for the cf-standard layer.

@brianmckenna review for you convenience