Re: [GRASS-dev] vector legend implementation
On 28/06/16 17:38, Anna Petrášová wrote: On Sat, Jun 25, 2016 at 3:01 PM, Anna Petrášováwrote: On Sat, Jun 25, 2016 at 7:47 AM, Martin Landa wrote: Hi, 2016-06-23 19:49 GMT+02:00 Anna Petrášová : 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? Sounds like a good solution to me. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] vector legend implementation
On Sat, Jun 25, 2016 at 3:01 PM, Anna Petrášováwrote: > On Sat, Jun 25, 2016 at 7:47 AM, Martin Landa wrote: >> Hi, >> >> 2016-06-23 19:49 GMT+02:00 Anna Petrášová : >>> 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 grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] vector legend implementation
On Sat, Jun 25, 2016 at 7:47 AM, Martin Landawrote: > Hi, > > 2016-06-23 19:49 GMT+02:00 Anna Petrášová : >> 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 > > Ma > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] vector legend implementation
ops! Forgot the list... Hello Anna, [...] GUI takes the series of d.vect commands and turns it into a text file in > format: > symbol color1 color2 size width text > > the legend symbols would be always the GRASS symbols, so even line, > areas would be symbols. We would add new symbols for lines and areas, > for example straight and crooked line, some irregular shape for areas. > color1 is outline color > color2 is fill color > size is symbol size > width is line width > text is legend label > Would it be possible to also have font and fontsize for the text part? > so for example: > > legend/line red none 5 2 State border > > then each line of the legend will be drawn with d.graph. > > [...] What about the name? > > d.vect.legend (like t.vect.list) > +1 (following d.vect.thematic and d.vect.chart) - this would imply to change d.legend to d.rast.legend perhaps I can't give any opinion regarding the most important issues, though... sooory :-P Best, Vero ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev