[GRASS-user] v.select incredibly slow

Mon Mar 29 03:01:19 PDT 2021

Hi Uwe,

On 29/03/21 09:53, Uwe Fischer wrote:
> But it led me again to some kind of misunderstanding that I cannot figure out:
> 
> My data are imported from polygon shapefiles.
> 
> First question: using v.in.ogr, what does the "type=" parameter mean exactly? In the manual, it reads: "Optionally change default input type". But imho, the input is the input. You cannot change it. What can be changed is the output or the way you process the input. This question prevents me from really understanding what v.in.ogr does with my polygons.

You probably do not need to use this parameter. It allows you to 
transform specific data to another type. A classical example would be to 
import area centroids as points, not centroids:

v.in.ogr census_wake2000.gpkg out=cw_noType
v.in.ogr census_wake2000.gpkg out=cw_point type=point

v.info -t cw_noType
nodes=192
points=0
lines=0
boundaries=296
centroids=105
areas=105
islands=1
primitives=401
map3d=0

v.info -t cw_point
nodes=192
points=105
lines=0
boundaries=296
centroids=0
areas=105
islands=1
primitives=401
map3d=0

Even though v.info indicates a certain number of areas, as centroids=0 
in cw_point, you will not have complete areas as in GRASS GIS an area is 
defined as the combination of boundaries and centroids.

But as mentioned, this is for very specific uses.

> Second question: I thought a GRASS map is able to hold areas and lines together in one map at the same time. How can I achieve such a mixed map using v.in.ogr from my polygon Shapes?

As far as I know, a shapefile cannot contain both lines and polygons, so 
are you sure you want to import both from the same file ? Are the lines 
you want to import the boundaries of the polygons ?

> When I use it with "type=line", it will produce lines only, some of which are holding former area attributes (which makes no sense for lines)

Attribute data is imported into a table, but AFAICT, there is no link 
between the lines and the attribute data. I guess it was decided to not 
lose the attribute data and so import it into a table. If you don't want 
to import the attribute table, you can use the -t flag.

An important aspect is that lines that imported this way do not have 
category values. So when you run v.select on these lines you will have 
to indicate that you do not want v.select to skip features without 
categories (-c flag).

> When I use it with "type=line, boundary", it will also produce lines only.
> Using "type=centroid, boundary" makes no sense because the input polygon shapefile has only polygons, but no centroids.

You have to think in GRASS GIS terms, and its topological data model, to 
understand this. I suggest reading 
https://grass.osgeo.org/grass78/manuals/vectorintro.html#vector-model-and-topology 
to get an overview.

> Maybe I have to go another way?

You could probably not worry about the question of lines vs polygons at 
the moment of import. Just import all polygons as polygons. You can then 
decide to check for boundary lines at the v.select stage. Here's an 
example using the NC demo data set:

# select polyons of layer A that are within polygons of layer B
v.select ainput=census_wake2000 at PERMANENT 
binput=boundary_municp at PERMANENT output=census_select operator=within

# select boundary lines of layer A that are withing polygons of layer B
v.select -c ainput=census_wake2000 at PERMANENT atype=boundary 
binput=boundary_municp at PERMANENT output=census_select_lines operator=within

[Note the use of -c as boundary lines normally do not have category 
values as these are attached to the centroids for areas.]

Attached you can see a quick map showing the results: as you can see the 
red lines selected go beyond the yellow polygons selected.

Moritz

> 
> -----Ursprüngliche Nachricht-----
> Von: Moritz Lennert [mailto:mlennert at club.worldonline.be]
> Gesendet: Sonntag, 28. März 2021 13:50
> An: grass-user at lists.osgeo.org; Uwe Fischer <gisfisch at t-online.de>
> Betreff: Re: [GRASS-user] v.select incredibly slow
> 
> Hi Uwe,
> 
> Am 27. März 2021 14:58:01 MEZ schrieb Uwe Fischer <gisfisch at t-online.de>:
>> Hello list,
>>
>> I have trouble selecting line features using their location compared to
>> a polygon layer using v.select. The line features I want to select from
>> are parcel borders, and the polygon layer is made up of tubular-shaped
>> buffers around municipal borders. I need to find the parcel borders
>> which are inside this buffer.
>>
>> The command line in a Python script I use is:
>>
>> grass.run_command('v.select', ainput='temp5', atype='line',
>> binput='buff', blayer=1, btype='area', output='grenz',
>> operator='within', overwrite=True)
>>
>> The process starts, but it runs incredibly slow (> 15 min) and it
>> brings not the desired result (but trash data). When I start it in the
>> GRASS ui, it also works very very slow.
>>
>> I have only about 2000 parcel borders, so it cannot be a problem of too
>> much features. Furthermore, the exact same selection task is processed
>> in QGIS 3 in a second with perfect results.
>>
>> I used v.build on both maps before v.select, but it does not help.
>>
>> I would like to perform it in GRASS because it is part of a bigger data
>> preparation script which makes my work a lot easier. So I need to
>> integrate it here rather than selecting in QGIS manually.
> 
> 
> First of all: which version of GRASS GIS are you using ?
> 
> I filed a bug about this same issue a few years ago [1] and Markus Metz reorganized the code at the time to speed things up. I don't remember which version was the first to include the fixes (7.6 ?). However, even though it was slow, results were ok which doesn't seem to be the case for you, so that is a bit worrying.
> 
> Can you reproduce the same issue with the example given in that bug report ? If not can you provide a reproducible example, including relevant data ? Ideally as a GitHub issue ?
> 
> As a workaround you could try either the alternative provided in the bug report, or you  could try to reduce the number of line candidates first using v.select operator=overlap and using operator=within only on those selected in the first call.
> 
> Moritz
> 
> [1] https://trac.osgeo.org/grass/ticket/3361
> 
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.png
Type: image/png
Size: 277839 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20210329/888e4f94/attachment-0001.png>