#4009: 'where' option in v.to.rast can select wrong feature for raster attribute,
in areas where features overlap
---------------------------------+---------------------------------
Reporter: florisvdh | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Vector | Version: svn-releasebranch76
Keywords: v.to.rast sql where | CPU: x86-64
Platform: Linux |
---------------------------------+---------------------------------
I use GRASS 7.6.1 on Linux Mint 18.1, i.e. Ubuntu Xenial (16.04) based.
''(Note, this is my first post here, I'm a beginning GRASS user, mostly
working with R)''
I applied something like:
{{{
v.to.rast input=polygon_layer output=output_x1 where="field1 LIKE 'x1'" \
use=attr attribute_column=field2 memory=800 --overwrite
}}}
Importantly, {{{field1}}} in {{{polygon_layer}}} has several possible
values such as {{{x1}}}, {{{x2}}}, {{{x3}}} and so on (81 different values
in my usecase).
Moreover, in my usecase several features (polygons) have identical
geometry, i.e. many sets of 2 or more polygons exist with 100% overlap
among their own polygons (i.e. identical polygons), while each of these
polygons has its own specific attributes: different values of {{{field1}}}
and so on. The problem that I met occurs for those features; possibly the
same problem will occur for overlapping areas between polygons in general.
While the {{{where}}} option in {{{v.to.rast}}} is effective in
''localizing the correct areas'', i.e. where {{{field1}}} is {{{x1}}}, the
**problem** is that the **attribute value** ({{{field2}}}) may come from
one of the other (overlapping) features at that place, e.g. where
{{{field1}}} is {{{x2}}}. Which feature of an overlapping set is used for
the attribute probably depends on the order of those overlapping features.
From what I've seen, it appears that {{{v.to.rast}}} will select the
{{{field2}}} value **from the same feature regardless** of the value for
{{{field1}}} in the above {{{where}}} option, as long as ''one'' of those
overlapping features meets the {{{where}}} condition.
If this effectively ''is'' a bug in the program, maybe it happens in other
modules as well, where the {{{where}}} option is available.
''Note: I should also mention that I used this in a simple parallelization
approach in a loop (setting {{{field1}}} to different values), by starting
the commands as background processes until a certain number of them is
running (following an example I
[https://grasswiki.osgeo.org/wiki/Parallelizing_Scripts found] in the
GRASS wiki). That's why the memory option was used explicitly.''
Currently I worked around this problem by splitting {{{polygon_layer}}}
according to the value of {{{field1}}}, using {{{v.extract}}} (using just
a simple loop here as the simple parallelization doesn't work with this
one).
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/4009>
GRASS GIS <https://grass.osgeo.org>