Hi Uwe,
On 29/03/21 15:59, Uwe Fischer wrote:
Hi Moritz,
for the question about lines and polys: I believe that confusion may come up
when one looks at a GRASS dataset in the QGIS browser panel (please see
attachment): there are lines and polygons in one map! And I can load them
exactly that way in QGIS. That is: when I load the lines in QGIS, I only get
lines!
GRASS GIS' vector format supports mixing all types of features in one
single map, so you can have points, lines and areas (boundary lines +
centroids) in one single map. The shapefile format does not support
this. AFAIK, QGIS follows the shapefile logic and does not allow
different geometry types in one single layer. Any area map in GRASS GIS
can actually be represented in three ways:
1) As what we generally would call polygons
2) The lines that constitute the contours of these polygons (called
boundaries in GRASS GIS)
3) Points that lie within the polygon (and are called centroids in GRASS
GIS, although they are not necessarily actual centroids in the
geometrical sense)
QGIS only provides 1 & 2.
You can see the effect of this format by playing around with 'type'
option in d.vect, directly in GRASS GIS.
And they ARE lines. That means: when I select a linear feature that separates
two areas with the mouse, I select only one feature! (attachment)
Were they boundaries, the mouse would grab two features, one for the left and
one for the right area??
Again, in GRASS GIS boundaries are lines, not polygons. And in QGIS they
are displayed as simple lines.
Because of its topological data format GRASS GIS does not have the
notion of polygons as such. It has the notion of areas which are the
combination of a boundary line with a centroid. Boundary lines without
centroids are not considered areas aka polygons.
AFAIK, QGIS does not support topological formats as such and so the
topological vector format of GRASS GIS (with points, centroids, lines,
boundaries, (virtual) areas) is mapped into simple features in QGIS:
points, lines, polygons. If you want to make use of the GRASS GIS'
topological format directly, you will have to use GRASS GIS.
Maybe it has to do with the way the dataset was imported: it came via v.in.ogr
using CAD data made up of lines and points using type='centroid,boundary'.
On the other hand, GRASS v.info for that same map gives me:
v.info -t map=forst_f_035980@lwk_work
nodes=86
points=0
lines=0
boundaries=109
centroids=42
areas=43
islands=20
primitives=151
map3d=0
No line features at all !
>
> So is the QGIS representation misleading? How can QGIS see lines
while GRASS does not?
>
Boundaries are lines which have a special status. But geometrically they
are lines, not polygones.
On the other hand, I learned from your example that v.select can use boundaries
as linear features. I checked the same for v.buffer and found that it works:
for type=boundary, v.buffer will put out tubular buffers around linear features
(it will not buffer the areas as a whole!) I did not expect that, because I
thougt that buffering boundarys gives me area buffers, since the boundaries are
the area borders.
Creating buffers around "areas" will give you area buffers, creating
buffers around boundaries will give you exactly that: buffers around the
lines that are defined as boundary lines.
Have you had the opportunity to read through
https://grass.osgeo.org/grass78/manuals/vectorintro.html#vector-model-and-topology
?
And for the data conversion tasks: such tasks come up in my projects from time
to time.
You are right, there are only lines or only polygons in a shapefile.
But I sometimes need to perform typical polygon tasks first (like selecting by
attributes or dissolving or buffering) and then line tasks on the same dataset
(like retrieving the clean lines, broken up and without duplicates or other
errors for exporting and further processing in CAD). The second part cannot be
done with boundaries, right? That is why i was looking for a good way to deal
with both.
Most GRASS GIS vector commands allow you to choose which aspect of the
vector map you want to work with, generally through a 'type' parameter.
This allows to do what I showed you with v.select, but also with
v.buffer, v.clean, etc. When you change boundaries, however, you have to
be aware that you might change them in a way that you break topology. So
some additional care might be necessary.
Moritz
-----Ursprüngliche Nachricht-----
Von: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Gesendet: Montag, 29. März 2021 12:01
An: Uwe Fischer <gisfi...@t-online.de>; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] v.select incredibly slow
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@PERMANENT binput=boundary_municp@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@PERMANENT atype=boundary
binput=boundary_municp@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:mlenn...@club.worldonline.be]
Gesendet: Sonntag, 28. März 2021 13:50
An: grass-user@lists.osgeo.org; Uwe Fischer <gisfi...@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 <gisfi...@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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
