[GRASS-dev] [GRASS GIS] #4009: 'where' option in v.to.rast can select wrong feature for raster attribute, in areas where features overlap

[GRASS GIS]

#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>