search

Unidata / rosetta

ρζητα ⇒ rosetta
http://www.unidata.ucar.edu/software/rosetta/
BSD 3-Clause "New" or "Revised" License
17 stars 7 forks source link

featureType profile #28

Open aleksandervines opened 7 years ago

aleksandervines commented 7 years ago

We need the featureType profile as an option (for e.g. CTD/XBT data).

Therefore, I thought I should start implementing this, and I have some questions.

If I understand this correctly, the main magic is happening in the class extending NetcdfFileManager, and this is the main class to implement. However, there are two adjustments to the input information that also needs to be done: Selecting observation platform - which sets the cfType input to profile. I've already implemented this, as that was the easy part. Specify cite specific information - The main thing here is that we don't want the altitude in here, but the date/time instead (and fetch altitude from the input file instead). Here I'm not sure how to proceed as I'm not certain of your plans for correct approach. I've noticed that the current information is stored in platformMetadata.xml, and there exists a platformMetadataProfile.xml, but this does not seem to be in use yet as the specifyPlatformMetadata.jspf only concerns itself with the "default" settings. Or perhaps this is implemented in parts and I have not seen it yet.

The question is: where do you think this logic, that decides what site specific input, should go?

The way I see it, the logic in the create view needs to be reworked. At the point in time where the HTML for the "specify site specific information" is generated, the user has not yet selected platform.

lesserwhirls commented 7 years ago

Yes, the logic needs reworked for sure. My original idea was to have a "create" workflow for each featureType. However, I've come to believe that one "create" workflow would be ideal. Rosetta should inspect what has been specified as "coordinate" variables from the main variable selection table, and fill in the "specify site specific information" step on the fly, requesting other information as needed. In this case, selection of a platform to set a featureType wouldn't necessarily be needed, as that could be figured out based on the coordinate variables defined.

aleksandervines commented 7 years ago

It does sound nice to skip the step where we choose the platform. But I believe a few more featureTypes should be implemented before you switch that, it's not point for a user to hopefully start adding metadata to discover that the featureType he needs is not supported.

I therefore think I'll look into a workflow that modifies the specifyPlatform-html code in the repopulateStep. This might also be where the code to automatically select featureType could go at a later stage.