[GRASS-dev] vector legend implementation

[Moritz Lennert]

On 28/06/16 17:38, Anna Petrášová wrote:
> On Sat, Jun 25, 2016 at 3:01 PM, Anna Petrášová <kratochanna at gmail.com> wrote:
>> On Sat, Jun 25, 2016 at 7:47 AM, Martin Landa <landa.martin at gmail.com> wrote:
>>> Hi,
>>>
>>> 2016-06-23 19:49 GMT+02:00 Anna Petrášová <kratochanna at gmail.com>:
>>>> 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