Hi,
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.
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
so for example:
legend/line red none 5 2 State border
then each line of the legend will be drawn with d.graph.
This format could be general enough to support more complicated cases
(thematic vector?). What is not clear to me now is how the legend
module will be called from d.mon wx0 and cairo. In GUI, it can
automatically create this text file, but in d.mon cairo there is
currently no way to get the d.vect commands (d.save is not in G7). So
when scripting, users would have to write the input text file
specifying the legend. Or the input could be a list of d.vect commands
in a file if that would be more convenient. But when using d.mon wx0,
it would be convenient to use d.vect.legend without any parameters,
because the GUI knows the layers. So maybe we need some kind of
wrapper module on top of the lower level implementation. I am sorry if
this sounds confusing, but this can be decided later.
What about the name?
d.vect.legend (like t.vect.list)
d.legend.vect (like v.what.rast)
d.vlegend
Thanks for any feedback,
Anna
Hi,
2016-06-23 19:49 GMT+02:00 Anna Petrášová <kratochanna@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?
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 ?
Ma
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On Sat, Jun 25, 2016 at 7:47 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2016-06-23 19:49 GMT+02:00 Anna Petrášová <kratochanna@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
Ma
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On Sat, Jun 25, 2016 at 3:01 PM, Anna Petrášová <kratochanna@gmail.com> wrote:
On Sat, Jun 25, 2016 at 7:47 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2016-06-23 19:49 GMT+02:00 Anna Petrášová <kratochanna@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
On 28/06/16 17:38, Anna Petrášová wrote:
On Sat, Jun 25, 2016 at 3:01 PM, Anna Petrášová <kratochanna@gmail.com> wrote:
On Sat, Jun 25, 2016 at 7:47 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2016-06-23 19:49 GMT+02:00 Anna Petrášová <kratochanna@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