[GRASS-dev] d.vect render= and corrupted vector display

[Maciej Sieczka]

Glynn Clements wrote:
> Maciej Sieczka wrote:
> 
>>> I've changed the clipping/culling code to handle this particular case
>>> (i.e. use <= 0 rather than < 0), so #4 and #5 now match the other
>>> three.
>>> Beyond that, the main issue is that the code which sets up the
>>> coordinate mapping (D_setup/D_do_conversions) maps the current region
>>> to the current frame *exactly*, without any margin. This is arguably
>>> the right thing, even if the net result isn't always ideal (and the
>>> result of v.in.region is the worst possible case).
>> Don't you think it is confussing for the user? If I do v.in.region, I'm
>> right to expect that the whole vector will be displayed when my working
>> region matches the v.in.region's output extent.

> Hmm; not really. v.in.region generates a vector map corresponding to
> the region's boundary. d.vect displays the portion of a vector map
> which lies inside the region.
> 
> Is a region's boundary *inside* the region?

1. This is not a boundary, but a line (v.in.region output=frame type=line).

2. Even if it was a boundary - either the *whole* boundary should be
displayed, or not. Currently, 75% of the boundary is displayed, while
the other 25% is not. This looks strange to the user.

Too bad if cannot be "fixed", though I'm 100% OK with whatever you
decide about it and thank you for taking your time to check it out and
explain it.

> If you treat the boundary as an area, then the area which d.vect will
> fill is exactly the region, i.e. inside the boundary == inside the
> region. But is the boundary itself inside the region?
> 
> I'm aware that this may be counter-intuitive, but that isn't the same
> thing as being wrong. The problem is that I don't see how to change
> this without creating more significant problems.

>> And if this doesn't
>> happen (as it is currently), I start wondering whether there could be a
>> bug in v.in.region, or g.region, or d.vect an so on. Waste of time,
>> less trust in GRASS, bogus bug reports etc.
>>
>> If it is possible to fix that without too much effort, I would be for it.

> How do you propose "fixing" this case

I can't know that. I thought you might, so I asked.

> without breaking more sensible cases.

What could be broken?

> Bear in mind that this is
> (quite literally) a "boundary case".

I don't agree. This issue might bias user's understanding of GRASS'
region, which is not trivial:

g.region vect=frame; d.vect frame

In a result, 25% of lines is missing on display, while region and
display were ordered to encompass the whole vector "frame". As the 3/4
of lines is displayed while 1/4 is not, it just looks "not good" to the
user, thus might incline him to think there is a defect somewhere
underneath.

Please note that if you decide this cannot be fixed/too intrusive to do
so/to much work compared to profit, please be sure I'm perfectly OK
with your decision. Yet, the issue would remain.

Maciek