Ticket #647 (assigned task)

Opened 12 years ago

Last modified 11 years ago

[DS][WG] DX GUI: requirements and proposals

Reported by: fvenuti Owned by: fvenuti
Priority: discussion Milestone:
Component: ndg2 Version:
Keywords: DataExtractor Cc:

Description (last modified by fvenuti) (diff)

This is an attempt to systematize the ideas collected by the DX-GUI team in terms of functional or graphical requirements and proposed solutions.

The DX GUI should interact with the discovery interface, rather than just being called by the latter. This would allow the user to perform tasks from within the DX GUI rather than moving from one interface to the other. For instance, the user should be able to switch between views of previously discovered datasets easily. The DX GUI should also provide an option to search for datasets “alternative” to the displayed dataset, based on the characteristics (spatial/temporal coverage, parameters, production tool etc.) of the current datasets. E.g.: the user extracts a CTD profile and then he might be interested in comparing these data with data from a model that has the same temporal/spatial coverage. It might not be obvious how to define algorithmically the notion of alternative dataset in a context where data are heterogeneous. For instance: a user that extracted a CTD profile is unlikely to be interested in seismic data collected in the same geographical area. This is something to discuss. In theory, we could “code” some expert knowledge and common patterns followed by researchers in each specific area of interest and use this knowledge base to search for candidate alternative datasets. All this should happen within the DX interface without the need to go back to discovery.

We should aim for a DX GUI that, as a minimum, is able to compare two feature types from two different datasets. This is considered a good proof of concept. Other features of the DX GUI:

  • Different feature types could trigger different views of the interface, though, for instance, point series and profiles could be associated with the same view. The views would display different options or have some options disabled. [Helen, you might want to comment on this, as it was your idea.] I think that we need to be careful in anticipating what users might want or not want to do with the data, especially if this implies that we prevent users from interacting with the system in certain ways.
  • It should be possible to save a search as a sequence of commands with proper parameters already set, to be used in calling NDG web services directly from inside an application (e.g. matlab), without having to go through the web GUI to get to the same dataset at a later time.

What we want to achieve could look something like this:  http://www.neodaas.ac.uk/data_portal. A snapshot is shown in the picture below:

neodaas portal - example

where we could have the parameters in the “data type” box. I’m not sure about the “Date Selection” box, as some datasets might need to be browsed in a different way (e.g.: time of the day might be important). So instead we could have simply two text boxes that, by default, are already filled with min/max time values. The interface could also provide “sliders” that the user can move along, without having to enter manually values (for example, something like this:  http://www-pcmdi.llnl.gov/software-portal/cdat/tutorials/getting-started/starting-vcdat). The “Region Selection” could contain spatial info of the current dataset being browsed. E.g., for a collection of CTD profiles it could show the CTD stations on a map. Instead of having the “Select one area below”, we could have in the same space a list of previously selected datasets or alternative datasets, where the alternative datasets could be datasets originated in the same area. This would provide a quick way to browse different datasets without having to go back to “search” mode (but see discussion about the notion of alternative dataset above). The summary box could also contain a button that calls the visualization module (GeoSPlAT or other).

The DX GUI team thinks that the visualization phase should not be considered as the end of a process, but rather as part of a loop (search dataset – browse data within dataset – visualize data). So the team thinks that the DX GUI and data visualization module should engage in an interaction, rather than the visualization module simply being called by the DX GUI. The visualization could be something like this:  http://www.npm.ac.uk/rsg/projects/mceis/ (then follow link to demonstrations), as shown in the picture below:

RSDAS - visualization tool (1)

The visualization tool provides some features like display of numerical values while moving the mouse over the image, zoom and customizable contrast/palettes. From the visualization window, the user should be able to get a list of previously discovered datasets and to visualize them side by side or as overlays. The last possibility would be given only for same feature types with same characteristics. For example something like this:

RSDAS - visualization tool (2)

Attachments

neodaas_portal.jpg Download (256.3 KB) - added by fvenuti 12 years ago.
neodaas portal - example
vis_tool1.jpg Download (225.3 KB) - added by fvenuti 12 years ago.
RSDAS - visualization tool (1)
vis_tool2.jpg Download (221.4 KB) - added by fvenuti 12 years ago.
RSDAS - visualization tool (2)

Change History

comment:1 Changed 12 years ago by fvenuti

  • Priority changed from blocker to discussion
  • Owner changed from astephen to fvenuti

Changed 12 years ago by fvenuti

neodaas portal - example

Changed 12 years ago by fvenuti

RSDAS - visualization tool (1)

Changed 12 years ago by fvenuti

RSDAS - visualization tool (2)

comment:2 Changed 12 years ago by fvenuti

  • Status changed from new to assigned
  • Cc hsnaith, pmiller, lawrence, astephen, selatham added

comment:3 Changed 12 years ago by fvenuti

  • Cc hsnaith, pmiller, lawrence, astephen, selatham removed
  • Description modified (diff)

comment:4 Changed 12 years ago by fvenuti

  • Description modified (diff)

comment:5 Changed 12 years ago by fvenuti

  • Description modified (diff)
  • Summary changed from DX GUI: requirements and proposals to [DS][WG] DX GUI: requirements and proposals

comment:6 Changed 11 years ago by lawrence

  • Keywords DataExtractor added
  • Component changed from T03_DataExtractor to ndg2

Moved to obsolete ndg2 components as part of ndg2 cleanup

Note: See TracTickets for help on using tickets.