On Sat, Jun 25, 2016 at 3:01 PM, Anna Petrášová <[email protected]> wrote: > On Sat, Jun 25, 2016 at 7:47 AM, Martin Landa <[email protected]> wrote: >> Hi, >> >> 2016-06-23 19:49 GMT+02:00 Anna Petrášová <[email protected]>: >>> I would like to get some feedback on the implementation of vector >>> legend which Adam will start working on soon as part of GSoC. >>> >>> Basically, the implementation would be in Python using d.graph which >>> allows to draw shapes, symbols, lines and text. >>> The first implementation would solve only basic things. >> >> are you sure that it will be enough? Wouldn't be better to start >> writing this module in C? > > Yes, you are right, d.graph is pretty powerful, but we will need some > low level display functions. > >> >>> d.vect.legend (like t.vect.list) >> >> We don't have any d.rast.legend (what about renaming d.legend?) >> >>> d.legend.vect (like v.what.rast) >> >> + d.legend.rast ? > > I agree, d.legend.rast, d.legend.vect and d.legend could become a > wrapper for backwards compatibility. We also have d.rast.leg. > > We can decide this later. > > Anna
We have to decide how the d.vect commands will get translated into the legend information. This is my a Vasek's suggestion: d.vect commands will have a new option legend, which can be a) empty- nothing happens, b) '-' will print legend information in the format I mentioned above to stdout and c) path to file - will write (append) the legend specification in that file. So the GUI will automatically append the legend=- to all d.vect commands and get the legend specification for that particular layer. When drawing the legend, it will go through the d.vect layers and put together the specifications into one file and call d.legend.vect with that file. The advantage of letting d.vect write the legend specification for itself is that d.vect has all the necessary information and it could possibly allow to output even more complicated legend specification (for example when the vector has color table). The same would then work for d.vect.thematic. d.vect would have to have other legend related options, for example legend_label which would be optional. This is similar behavior to how ps.map vector instructions work, you specify the label for legend there as well, not in the legend instruction. Users would be able to edit the resulting legend specification in d.legend.vect directly, because it's just a text file with couple of lines. We might need to design a special widget so that people can just click and select symbol, change size etc. Does that sound reasonable, could someone see any possible problems with that? Thank you, Anna > >> >> Ma >> >> -- >> Martin Landa >> http://geo.fsv.cvut.cz/gwiki/Landa >> http://gismentors.cz/mentors/landa _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
