Talk:Plotting Parallel Data (PGraph)

From ParaQ Wiki
Jump to navigationJump to search

This is a good place to capture discussions about PGraph. When editing, please follow the standard convention of talk pages (http://en.wikipedia.org/wiki/Wikipedia:Talk_page). In particular, indent responses from what they are responding to with colons (:) and make sure you sign your entries with four tildes (~~~~)

Is Array Representation Sufficient?

The entire approach depends on representing plot data as 1D or 2D arrays? Will this always be the case? Are there use cases otherwise?

--Kmorel 19:54, 4 Jan 2006 (EST)

Non Qt plotting components?

Is it too restrictive to say that the plotting components will be in Qt? There may be some cases to use VTK to generate some of the plots.

For example, the easiest way to implement an X-Y-Z plot is with a 3D drawing package like OpenGL. And if we are using OpenGL anyway, why not let VTK do the work? This is how Prism does its X-Y-Z plots.

Also, it may be handy to have both Qt component plotting and VTK plotting for other types. That would make it possible to do plotting on a tiled display. I know, people say plotting on a tiled display is pointless, but what about putting up lots of plots for comparative vis? What about really detailed scatter plot for a large amount of data?

There may even be cause to have a "plotting component" that is neither Qt nor VTK/OpenGL. What about a component that outputs an image file such as an encapsulated postscript, pdf, or image? What about a component that outputs a data file to be imported in another package such as excel or grace?

Ultimately, I think there are two questions. First, should references to "Qt Plotting Components" be changed to the more generic "Plotting Components"? Second, should there be some consideration for plots that happen on the server side?

--Kmorel 19:54, 4 Jan 2006 (EST)


I don't think we should use Qt for 3D drawing. We should definitely use VTK or something similar for the X-Y-Z Plots. If Qt has better font support, we could combine the two. I'm not sure how well that would work though.
Mark Richardson 13:32, 9 Jan 2006 (EST)
We should keep in mind that python users will probably want access to plotting as well. Although there are relatively decent 2D plotting packages for python, the 3D support is not as good. If we were to use VTK or some similar 3D plotting library accessible through python, it would make python users happy.
Berk 14:25, 11 Jan 2006 (EST)
I've removed any mention of Qt from the document. It now mearly says that a plotting component interfaces with the GUI. The actual implementation of the components are, for the most part, beyond the scope of this document.
--Kmorel 17:18, 17 Jan 2006 (EST)

Curves vs. lines

Ken, when I talked to Dean Dobranich about temporal support, he was almost more interested in plotting than in temporal support. One particular request from him was the ability to examine values along a circular curve rather than along a line – when he looks at datasets with cylindrical features, he often finds himself interested in tangential as well as radial values. That is why I've altered the use case for the "line probe".

David Thompson 19:53, 6 Jan 2006 (EST)

Good call. I've changed the name of the entry in the table to "Curve Probe" to be more specific.
I'm hoping others will chime in on users requests. Are users interested in a similar extension of "Plane Probe" to work on other types of surfaces? Are there other ways to define curves in space? I've heard (second- or third-hand) about requests to define a curve along an existing surface. I could fill the table with all sorts of interesting ways to make plots, but that would be pointless if they are of no use to anyone.
--Kmorel 12:24, 10 Jan 2006 (EST)

Why image data?

Can't there be cases where we want to visualize other types of (small) data on the client side? Maybe we should not restrict reduction and delivery from server to client to only image data?

Berk 09:21, 17 Jan 2006 (EST)