#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>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev