Hi,
can anyone explain the difference between grass64 and 7 in clipping vector data for display? I attached 2 pictures created with d.mon png and cairo driver (to avoid influences from GUI) and you can see that in 64 the lines are clipped to match computational region while in grass7 it seems to display all vector features which have at least part in the region. Is this bug or feature? I couldn’t find any discussion on this topic…
Thanks,
Anna
Anna Petrášová wrote:
can anyone explain the difference between grass64 and 7 in clipping vector
data for display? I attached 2 pictures created with d.mon png and cairo
driver
Which is png and which is cairo?
(to avoid influences from GUI) and you can see that in 64 the lines
are clipped to match computational region while in grass7 it seems to
display all vector features which have at least part in the region. Is this
bug or feature? I couldn't find any discussion on this topic...
In 7.0, there are two distinct sets of clipping operations.
D_set_clip_mode, D_set_clip and D_clip_to_map control clipping which
is performed within the display library. The default is no clipping.
Using this functionality for graphical clipping is problematic if you
use thick lines, as clipped lines will be capped at the point where
they're clipped. It would also affect the dash offset for dashed lines
(although that isn't implemented yet).
Additionally, the driver's Set_window function establishes a clip
region (e.g. via cairo_clip() for the cairo driver). This defaults to
the entire "screen", but can be overridden by setting the environment
variable GRASS_FRAME.
Arguably, the code which sets up the coordinate system so that the
current region just fits the display (D_setup) should also set the
clip region to fit the current region.
However, this is complicated slightly be the fact that there's no
distinction between the display "frame" (either the screen or the
frame set by GRASS_FRAME) and the current clip region, so setting a
clip region would lose the only record of the frame.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
thanks for reply,
On Tue, Sep 16, 2014 at 7:59 AM, Glynn Clements <glynn@gclements.plus.com> wrote:
Anna Petrášová wrote:
can anyone explain the difference between grass64 and 7 in clipping vector
data for display? I attached 2 pictures created with d.mon png and cairo
driverWhich is png and which is cairo?
the map70.png is cairo, the other one is png.
(to avoid influences from GUI) and you can see that in 64 the lines
are clipped to match computational region while in grass7 it seems to
display all vector features which have at least part in the region. Is this
bug or feature? I couldn’t find any discussion on this topic…In 7.0, there are two distinct sets of clipping operations.
D_set_clip_mode, D_set_clip and D_clip_to_map control clipping which
is performed within the display library. The default is no clipping.Using this functionality for graphical clipping is problematic if you
use thick lines, as clipped lines will be capped at the point where
they’re clipped. It would also affect the dash offset for dashed lines
(although that isn’t implemented yet).
Is there any way to set different default mode without modifying the code?
Additionally, the driver’s Set_window function establishes a clip
region (e.g. via cairo_clip() for the cairo driver). This defaults to
the entire “screen”, but can be overridden by setting the environment
variable GRASS_FRAME.Arguably, the code which sets up the coordinate system so that the
current region just fits the display (D_setup) should also set the
clip region to fit the current region.However, this is complicated slightly be the fact that there’s no
distinction between the display “frame” (either the screen or the
frame set by GRASS_FRAME) and the current clip region, so setting a
clip region would lose the only record of the frame.
I still don’t understand if the current behavior in 7 is intended and if so, why no vector clipping is better?
Anna
–
Glynn Clements <glynn@gclements.plus.com>
Anna Petrášová wrote:
> Using this functionality for graphical clipping is problematic if you
> use thick lines, as clipped lines will be capped at the point where
> they're clipped. It would also affect the dash offset for dashed lines
> (although that isn't implemented yet).Is there any way to set different default mode without modifying the code?
No.
> Additionally, the driver's Set_window function establishes a clip
> region (e.g. via cairo_clip() for the cairo driver). This defaults to
> the entire "screen", but can be overridden by setting the environment
> variable GRASS_FRAME.
>
> Arguably, the code which sets up the coordinate system so that the
> current region just fits the display (D_setup) should also set the
> clip region to fit the current region.
>
> However, this is complicated slightly be the fact that there's no
> distinction between the display "frame" (either the screen or the
> frame set by GRASS_FRAME) and the current clip region, so setting a
> clip region would lose the only record of the frame.I still don't understand if the current behavior in 7 is intended and if
so, why no vector clipping is better?
It isn't intended, it's an oversight.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Sep 17, 2014 at 4:18 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:
Anna Petrášová wrote:
> > Using this functionality for graphical clipping is problematic if you
> > use thick lines, as clipped lines will be capped at the point where
> > they're clipped. It would also affect the dash offset for dashed lines
> > (although that isn't implemented yet).
>
> Is there any way to set different default mode without modifying the
code?No.
> > Additionally, the driver's Set_window function establishes a clip
> > region (e.g. via cairo_clip() for the cairo driver). This defaults to
> > the entire "screen", but can be overridden by setting the environment
> > variable GRASS_FRAME.
> >
> > Arguably, the code which sets up the coordinate system so that the
> > current region just fits the display (D_setup) should also set the
> > clip region to fit the current region.
> >
> > However, this is complicated slightly be the fact that there's no
> > distinction between the display "frame" (either the screen or the
> > frame set by GRASS_FRAME) and the current clip region, so setting a
> > clip region would lose the only record of the frame.
>
> I still don't understand if the current behavior in 7 is intended and if
> so, why no vector clipping is better?It isn't intended, it's an oversight.
I see. So, are you (or anyone else who understands this part of code) going
to do something about it?
--
Glynn Clements <glynn@gclements.plus.com>
Anna Petrášová wrote:
> > I still don't understand if the current behavior in 7 is intended and if
> > so, why no vector clipping is better?
>
> It isn't intended, it's an oversight.I see. So, are you (or anyone else who understands this part of code) going
to do something about it?
Try r62026.
This sets the clip region to the destination rectangle by default.
However, there may be situations where this clips things which
shouldn't be clipped. E.g. if you're plotting points with
"d.vect ... icon=...", points near the edge of the map will probably
have their icons clipped to the bounds of the map.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Sep 17, 2014 at 6:56 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:
Anna Petrášová wrote:
> > > I still don't understand if the current behavior in 7 is intended
and if
> > > so, why no vector clipping is better?
> >
> > It isn't intended, it's an oversight.
>
> I see. So, are you (or anyone else who understands this part of code)
going
> to do something about it?Try r62026.
thanks a lot!
This sets the clip region to the destination rectangle by default.
However, there may be situations where this clips things which
shouldn't be clipped. E.g. if you're plotting points with
"d.vect ... icon=...", points near the edge of the map will probably
have their icons clipped to the bounds of the map.
yes, but that's fine (at least for me)
but, d.rast freezes when I try to zoom to a map with png driver. With cairo
driver, everything works fine.
Anna
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Sep 17, 2014 at 9:40 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:
This sets the clip region to the destination rectangle by default.
However, there may be situations where this clips things which
shouldn't be clipped. E.g. if you're plotting points with
"d.vect ... icon=...", points near the edge of the map will probably
have their icons clipped to the bounds of the map.yes, but that's fine (at least for me)
For me too. I was thinking about it and the behavior is not what I expect
but it is actually what I want at the end. So it seems to me perfectly
fine. Thanks a lot, Glynn.
On Wed, Sep 17, 2014 at 9:40 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:
On Wed, Sep 17, 2014 at 6:56 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:Anna Petrášová wrote:
> > > I still don't understand if the current behavior in 7 is intended
and if
> > > so, why no vector clipping is better?
> >
> > It isn't intended, it's an oversight.
>
> I see. So, are you (or anyone else who understands this part of code)
going
> to do something about it?Try r62026.
thanks a lot!
This sets the clip region to the destination rectangle by default.
However, there may be situations where this clips things which
shouldn't be clipped. E.g. if you're plotting points with
"d.vect ... icon=...", points near the edge of the map will probably
have their icons clipped to the bounds of the map.yes, but that's fine (at least for me)
but, d.rast freezes when I try to zoom to a map with png driver. With
cairo driver, everything works fine.
Steps to reproduce (nc_spm_08):
export GRASS_RENDER_IMMEDIATE=png
g.region rast=elevation
export GRASS_WIDTH=100
export GRASS_HEIGHT=501
d.rast elevation
99%
The problem is here:
http://trac.osgeo.org/grass/browser/grass/trunk/lib/display/raster.c#L169
return (A_row < src[1][1]) ? A_row : -1;
-1 is never selected because src is always greater than A_row
Anna
--
Glynn Clements <glynn@gclements.plus.com>
Anna Petrášová wrote:
but, d.rast freezes when I try to zoom to a map with png driver. With cairo
driver, everything works fine.
This should be fixed by r62036.
--
Glynn Clements <glynn@gclements.plus.com>