Closed GoogleCodeExporter closed 9 years ago
Agreed, some way to help to visually sift through long lists of Parameters is
needed. Is this enhancement request encompassed by Issue 23? If so, we can
close it and keep 23 active.
Original comment by MBARIm...@gmail.com
on 4 Feb 2014 at 8:05
I am not sure. Issue 23 is about having too many parameters whereas this issue
is about not knowing which platform they belong to. They are related, as the
nested accordions proposed in 23 would solve this one if the title is the
platform, but they are not the same issue I believe (eg you could solve 23 by
grouping the parameters into physics/nutrients/optics for instance, which may
make more sense but doesn't solve this issue).
Original comment by monique....@gmail.com
on 4 Feb 2014 at 8:12
The existing way to learn which parameters belong to which platforms and vice
versa is to select one for filtering and observe what remains in the other
list. The Parameter button could be outlined colored with the color of the
platform, but some Parameter names belong to multiple platforms and there is
really no limit to how many platforms. I could see implementing this if there
were a clean way to add any number of colors to the button or in the row for
the Parameter. Ideas?
Original comment by MBARIm...@gmail.com
on 5 Feb 2014 at 6:55
Attached is a screen shot of a test of showing colored symbols to the right of
the Parameter button: a '|' represents a platform that produced a trajectory
data set and a '*' represents either timeSeries or timeSeriesProfile data. Does
this solution address the issue?
Original comment by MBARIm...@gmail.com
on 7 Feb 2014 at 12:45
Attachments:
This issue was closed by revision e35bc35c6f01.
Original comment by MBARIm...@gmail.com
on 8 Feb 2014 at 6:30
Sorry for the delay in answering - the end of last week was pretty busy.
I guess I hadn't understood the parameter vs. standard name concept. I thought
there was a different button for each platform in parameters, and that
selecting the standard name was selecting all the platforms that measured that
variable. I am not sure there is an interest in separating "PSAL" and
"sea_water_salinity_HR" in this case. Wouldn't it make more sense to only use
standard names when available and to forget about the name / standard name
difference? (I guess it's a separate issue - and I'm only talking about the web
interface here, not the database). I understand some don't have standard names
- in this case you could just add an asterisk that means "not a "real" standard
name".
Regarding the specific issue, yes I think this helps - it is a bit hard to see
at a glance which platform it belongs to but at least it gives a very good idea
of how many platforms there are and which parameters are worth looking at.
Original comment by monique....@gmail.com
on 10 Feb 2014 at 5:53
Original issue reported on code.google.com by
monique....@gmail.com
on 31 Jan 2014 at 7:42