[GRASS-dev] vector legend implementation

[Anna Petrášová]

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?

Thank you,

Anna



>
>>
>> Ma
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa