[SoC] SVG-graph-plotting questions
Hello there, I would really like to come up with a SoC-application for the graph-plotting-thing. However there are some questions that came to my mind: (1) It is mentioned, that data inside a container should be plotted as a function graph. Is this data arbitrarily collected or does it necessarily popped out of a math-function? The latter would make it way easier to interpolate a smooth function from the data (by passing the function as a whole or at least the first derivatives of the data). (2) Are there suggestions about the context this should be implemented in? Should it go into a specific boost-lib? Should it be a single function that takes loads of parameters (like color, range, size, ...). Should it be a class where the user would set these parameters as attributes? (3) It is said, that the data comes from some stl-containers. Just to be sure: You mean 2 dimensional containers for plotting a 2d function? Thanks in advance, Johannes
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Johannes Laudenberg Sent: 15 March 2007 22:01 To: boost@lists.boost.org Subject: [boost] [SoC] SVG-graph-plotting questions
Hello there,
I would really like to come up with a SoC-application for the graph-plotting-thing. However there are some questions that came to my mind:
(1) It is mentioned, that data inside a container should be plotted as a function graph. Is this data arbitrarily collected or does it necessarily popped out of a math-function? The latter would make it way easier to interpolate a smooth function from the data (by passing the function as a whole or at least the first derivatives of the data).
I see a need for at least: 1 Plotting actual data points with markers like + * etc. 'Arbitrary' 2 Plotting straight lines - eg the least squares line to fit the above. 3 Plotting very well-behaved math functions - curves showing slightly non-linear fits. 4 Plotting a little less well-behaved curves like sin and cos plots. SVG polyline should be enough here. 5 Plotting badly behaved functions that whizz off to infinity and back. This suggests that BOTH collections of arbitrary data values AND at least well-behaved math functions are needed. And of course one would want to plot several of these on the same graph, with colors, (sin in red and cos in green) legends, labels to reduce the confusion.
(2) Are there suggestions about the context this should be implemented in? Should it go into a specific boost-lib?
I would expect it can be used via a simple include, something like #include <boost/plot/SVG/2Dplot.hpp> Of course, it could also be packaged as a library but these have proved more problematic to be portable, and less popular, so keep it simple?
Should it be a single function that takes loads of parameters (like color, range, size, ...). Should it be a class where the user would set these parameters as attributes?
Well I think an interesting part of the project is to explore which of these, or some combination, is most convenient. Boosters will undoubtedly have some (many?) opinions on this ;-)) I'm sure a single function would have far too many parameters, but one could have several functions. But this being a C++ project, classes will probably be de rigeur ;-)
(3) It is said, that the data comes from some stl-containers. Just to be sure: You mean 2 dimensional containers for plotting a 2d function?
Well yes, and no ;-) If the values are equi-spaced, then a vector, say, of values AND start, finish and spacing and/or count will do. Otherwise you'll need to deal with containers of x,y pairs. Providing a variety of these to meet users individual demands may be the challenging bit! 95% of data applications will be a vector full of equally spaced doubles, and a straight line or quadratic 'through' them. Of course, you'll want to use iterators and/or counts of number of points to allow users more control. Auto axis scaling, labelling and marking would be a popular option. Others will want to just pass a math function and get a plot. My instinct is to make this a 'phase 2' because you can quite easily, if less slickly, achieve this with point plotting. A major problem with short projects has proved to be biting off more than you can chew. So making sure that the project results in achieving at least this would be good. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
Should it be a single function that takes loads of parameters (like color, range, size, ...). Should it be a class where the user would set these parameters as attributes?
Well I think an interesting part of the project is to explore which of these, or some combination, is most convenient.
Boosters will undoubtedly have some (many?) opinions on this ;-))
I think design is crucial here: we would want something extensible I guess. So how about a "mini DOM" for vector graphics: class vector_drawing; // does this need template params?? with vector_drawing supporting simple drawn lines, text output etc. And then: class graph : public vector_drawing{ ... }; To extend the interface to include drawings made from data-points or functors? Wait, we could just use a factory function that returns a vector_drawing instead of inheritance maybe? All very traditional OO so far... Then what about saving the result: it could be as SVG, or maybe some other format (rendered as png or whatever?), so perhaps non-member writer functions would be best, along with accessor const-member functions in the vector_drawing type to allow the DOM to be enumerated? Presumable it would be possible to read in SVG as well, although maybe that would be a step too far for this project? More questions than answers here maybe, but something for you to think about. HTH, John.
Hi there,
Then what about saving the result: it could be as SVG, or maybe some other format (rendered as png or whatever?), so perhaps non-member writer functions would be best, along with accessor const-member functions in the vector_drawing type to allow the DOM to be enumerated? Presumable it would be possible to read in SVG as well, although maybe that would be a step too far for this project?
More questions than answers here maybe, but something for you to think about.
Since gil has been accepted into boost I could image using gil for writing an image. I'm creating an extension for gil using openCV for the drawing commands. It's very limited so far, but the basic commands are there, like line, polyline, circle, etc.. It's also very easy to extend the capabilities. So, why not use gil for saving the results of the SVG plotter? Christian
Christian Henning wrote:
Since gil has been accepted into boost I could image using gil for writing an image. I'm creating an extension for gil using openCV for the drawing commands. It's very limited so far, but the basic commands are there, like line, polyline, circle, etc.. It's also very easy to extend the capabilities. So, why not use gil for saving the results of the SVG plotter?
That gets you bitmap output, which is fine in some cases but a bit of a diversion, as really we would want SVG output as the main priority. There's also AntiGrain (http://www.antigrain.com/index.html) which seems to have quite a few fans around here, and looks to have strong rendering capabilities - much better than anyone could cook up within the confines of an SOC project - it also has SVG rendering capabilities, and I believe some folks have used it with GIL as the image backend. What I'm trying to get at here is that while the project should have one eye to the future - make it easily extensible in other words - the priority should be on a designing a half-decent vector-image DOM, with graphing support sitting on top. It's one of those projects that could easily grow out of control and not get finished, so a clear focus and development roadmap needs to be in place from the start. Cheers, John.
John Maddock wrote:
Paul A Bristow wrote:
Should it be a single function that takes loads of parameters (like color, range, size, ...). Should it be a class where the user would set these parameters as attributes?
Well I think an interesting part of the project is to explore which of these, or some combination, is most convenient.
Boosters will undoubtedly have some (many?) opinions on this ;-))
I think design is crucial here: we would want something extensible I guess. So how about a "mini DOM" for vector graphics:
class vector_drawing; // does this need template params??
Such as: http://doc.trolltech.com/4.2/qgraphicsscene.html
with vector_drawing supporting simple drawn lines, text output etc.
Such as: http://doc.trolltech.com/4.2/qgraphicslineitem.html http://doc.trolltech.com/4.2/qgraphicssimpletextitem.html ? - Volodya
Vladimir Prus wrote:
I think design is crucial here: we would want something extensible I guess. So how about a "mini DOM" for vector graphics:
class vector_drawing; // does this need template params??
Such as:
http://doc.trolltech.com/4.2/qgraphicsscene.html
with vector_drawing supporting simple drawn lines, text output etc.
Such as:
http://doc.trolltech.com/4.2/qgraphicslineitem.html http://doc.trolltech.com/4.2/qgraphicssimpletextitem.html
?
Similar yes, but that's tailored towards GUI display, and I was looking for something that's closer to SVG. However, the more I look into SVG the more I wonder whether a project such as this is actually achieveable :-( John.
Thanks for all your advice, I summed it up and this is what my proposal for the SoC-application will look like (Yes, I know I have to submit it to Google): (1) Classes for SVG primitives. This includes paths, circles, ellipses, rectangles, polygons, lines and polylines. Styles for strokes and fills end up in a base class. (2) "Draw"-mechanism. Primitives are hold in a layer's container from where their "to_svg()"-methods are called and the strings are put together based on their position inside the layer and the layer's position. (3) Graph plotter. Provides functions for plotting graphs from container-data. Includes options for color and shape (dots, linear connections, quadratic connections, columns, ...), just as options for the co-system (grid?, height, length, ...) and a positionable legend. Nothing spectacular, everything was said before, however, comments again appreciated. Thanks, Johannes
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Johannes Laudenberg Sent: 19 March 2007 11:48 To: boost@lists.boost.org Subject: Re: [boost] [SoC] SVG-graph-plotting questions
Thanks for all your advice, I summed it up and this is what my proposal for the SoC-application will look like (Yes, I know I have to submit it to Google):
(1) Classes for SVG primitives. This includes paths, circles, ellipses, rectangles, polygons, lines and polylines. Styles for strokes and fills end up in a base class.
(2) "Draw"-mechanism. Primitives are hold in a layer's container from where their "to_svg()"-methods are called and the strings are put together based on their position inside the layer and the layer's position.
(3) Graph plotter. Provides functions for plotting graphs from container-data. Includes options for color and shape (dots, linear connections, quadratic connections, columns, ...), just as options for the co-system (grid?, height, length, ...) and a positionable legend.
Nothing spectacular, everything was said before, however, comments again appreciated.
Looks on the right lines - if perhaps over-ambitious in getting into fills etc. Not sure if layers needed for simple graphs, but may not be much extra trouble to implement. Plots don't mention axes labels (units too) and title - perhaps taken as obvious. In general, important to KISS - "Keep It Simple Sir" so that something is finished by the end of a short project. Might worth including an unimplemented switch for output format, so consider .png jpg etc as a future project/enahncement. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
participants (6)
-
Christian Henning -
Johannes Laudenberg -
John Maddock -
Mathias Gaunard -
Paul A Bristow -
Vladimir Prus