[GRASS-user] map display query and layers

[Dave_Roberts]

d.vect has an option for layer= but I don't get any consistent effect from the query tool in the map display. For example

GRASS GIS 7.0.4 > v.db.connect -p fuel
Vector map <fuel> is connected by:
layer <1/LAB> table <fuel_1> in database </home/dvrbts/grass/bryce/PERMANENT/sqlite/sqlite.db> through driver <sqlite> with key <cat>
layer <2/ARC> table <fuel_2> in database </home/dvrbts/grass/bryce/PERMANENT/sqlite/sqlite.db> through driver <sqlite> with key <cat>

says there two layers to this feature connected to a sqlite database. I'm interested in the data in layer=2, so

d.vect fuel layer=2

draws the map correctly, but when I click on polygons I get results from layer 1, not 2. And sometimes for other maps I get multiple layer results, but often not the one I want. It may depend on exactly where I click (e.g. nearest a centroid (often invisible) vs a boundary) but it seems more random to me.

GRASS 7.0.4

Linux 4.6.2-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux

Thanks, Dave

[Vincent_Bain]

Hello Dave,

am I wrong or is your map connected to two distinct tables with the same
key (cat) ? then the behavior you describe may be related to a confusion
on the type of features holding 'cat' values. For exemple in the case of
a polygon map, you need to define which type of object handles cats
(i.e. boundaries or centroids).
Just to check, you can have a look at this wiki entry :
https://grasswiki.osgeo.org/wiki/Vector_Database_Management#GRASS_GIS_vector_management_model

Best,
Vincent.

Le vendredi 30 septembre 2016 à 15:47 -0600, Dave Roberts a écrit :

d.vect has an option for layer= but I don't get any consistent effect
from the query tool in the map display. For example

GRASS GIS 7.0.4 > v.db.connect -p fuel
Vector map <fuel> is connected by:
layer <1/LAB> table <fuel_1> in database
</home/dvrbts/grass/bryce/PERMANENT/sqlite/sqlite.db> through driver
<sqlite> with key <cat>
layer <2/ARC> table <fuel_2> in database
</home/dvrbts/grass/bryce/PERMANENT/sqlite/sqlite.db> through driver
<sqlite> with key <cat>

says there two layers to this feature connected to a sqlite database.
I'm interested in the data in layer=2, so

d.vect fuel layer=2

draws the map correctly, but when I click on polygons I get results from
layer 1, not 2. And sometimes for other maps I get multiple layer
results, but often not the one I want. It may depend on exactly where I
click (e.g. nearest a centroid (often invisible) vs a boundary) but it
seems more random to me.

GRASS 7.0.4

Linux 4.6.2-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux

Thanks, Dave
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[Dave_Roberts]

Hi Vincent,

    I have studied the GRASS_GIS_vector_management_model page (and all the discussion leading up to that), and I think I understand the data model. What I don't understand is how the map display interacts with the data tables. So in my example case, yes, there are two tables, both with key=cat, but that's pretty typical for data imported into GRASS with v.in.ogr or v.in.e00. I have another case where I imported an ESRI GDB, and GRASS created 25 layers all with key=cat. When I do

d.vect bryceveg

it seems to draw correctly, but when I use the map query icon and mouse click it gives me results for layers 22, 23, 25, and 26 (which is not connected to a table). Even if I specify

d.vect bryceveg layer=1

when I query I still get 22, 23, 25, and 26, none of which I want.

    So undoubtedly it's possible (with significant effort) to convert this to 25 different vector features each with only one table, but that seems like a lot of work, and I would expect when I specify the layer to draw that's the layer that gets queried. If I have time, I'll dig into the code (hopefully python) driving the map query.

Thanks, Dave

On 10/01/16 01:04, Vincent Bain wrote:

Hello Dave,

am I wrong or is your map connected to two distinct tables with the same
key (cat) ? then the behavior you describe may be related to a confusion
on the type of features holding 'cat' values. For exemple in the case of
a polygon map, you need to define which type of object handles cats
(i.e. boundaries or centroids).
Just to check, you can have a look at this wiki entry :
https://grasswiki.osgeo.org/wiki/Vector_Database_Management#GRASS_GIS_vector_management_model

Best,
Vincent.

Le vendredi 30 septembre 2016 à 15:47 -0600, Dave Roberts a écrit :

d.vect has an option for layer= but I don't get any consistent effect
from the query tool in the map display. For example

GRASS GIS 7.0.4 > v.db.connect -p fuel
Vector map <fuel> is connected by:
layer <1/LAB> table <fuel_1> in database
</home/dvrbts/grass/bryce/PERMANENT/sqlite/sqlite.db> through driver
<sqlite> with key <cat>
layer <2/ARC> table <fuel_2> in database
</home/dvrbts/grass/bryce/PERMANENT/sqlite/sqlite.db> through driver
<sqlite> with key <cat>

says there two layers to this feature connected to a sqlite database.
I'm interested in the data in layer=2, so

d.vect fuel layer=2

draws the map correctly, but when I click on polygons I get results from
layer 1, not 2. And sometimes for other maps I get multiple layer
results, but often not the one I want. It may depend on exactly where I
click (e.g. nearest a centroid (often invisible) vs a boundary) but it
seems more random to me.

GRASS 7.0.4

Linux 4.6.2-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux

Thanks, Dave
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[hellik]

Dave Roberts wrote

Hi Vincent,

    I have studied the GRASS_GIS_vector_management_model page (and all
the discussion leading up to that), and I think I understand the data
model. What I don't understand is how the map display interacts with
the data tables. So in my example case, yes, there are two tables, both
with key=cat, but that's pretty typical for data imported into GRASS
with v.in.ogr or v.in.e00. I have another case where I imported an ESRI
GDB, and GRASS created 25 layers all with key=cat. When I do

d.vect bryceveg

it seems to draw correctly, but when I use the map query icon and mouse
click it gives me results for layers 22, 23, 25, and 26 (which is not
connected to a table). Even if I specify

d.vect bryceveg layer=1

when I query I still get 22, 23, 25, and 26, none of which I want.

    So undoubtedly it's possible (with significant effort) to convert
this to 25 different vector features each with only one table, but that
seems like a lot of work, and I would expect when I specify the layer to
draw that's the layer that gets queried. If I have time, I'll dig into
the code (hopefully python) driving the map query.

Thanks, Dave

tested here with the NC sample data set

<--------------
g.copy vector=firestations@PERMANENT,myfire
--------------
v.category input=myfire@user1
layer=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25
output=myfire_manylayers option=transfer
--------------
v.db.addtable map=myfire_manylayers@user1 layer=2
[...]
v.db.addtable map=myfire_manylayers@user1 layer=25
--------------
map query:
east, north: 634259.762762, 238301.919626
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 1
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers
  Key_column: cat
  Attributes:
    cat: 16
    ID: 17
    LABEL: RFD #23
    LOCATION: 8312 Pinecrest Rd
    CITY: Raleigh
    MUN_COUNT: M
    PUMPERS: 1
    PUMPER_TAN: 0
    TANKER: 0
    MINI_PUMPE: 0
    RESCUE_SER: 0
    AERIAL: 0
    BRUSH: 0
    OTHERS: 0
    WATER_RESC: 0
    MUNCOID: 1
    BLDGCODE: 256
    AGENCY: RF
    STATIONID: RF23
    RECNO: 18
    CV_SID2: RF23
    CVLAG: 0
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 2
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_2
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 3
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_3
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 4
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_4
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 5
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_5
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 6
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_6
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 7
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_7
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 8
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_8
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 9
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_9
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 10
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_10
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 11
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_11
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 12
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_12
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 13
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_13
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 14
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_14
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 15
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_15
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 16
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_16
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 17
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_17
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 18
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_18
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 19
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_19
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 20
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_20
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 21
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_21
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 22
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_22
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 23
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_23
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 24
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_24
  Key_column: cat
  Attributes:
    cat: 16
myfire_manylayers@user1:
  Type: Point
  Id: 16
  Layer: 25
  Category: 16
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_25
  Key_column: cat
  Attributes:
    cat: 16
  
-------------------
v.db.addcolumn map=myfire_manylayers@user1 layer=25 columns="xcoor double,
ycoor double"
-------------------
v.to.db map=myfire_manylayers@user1 layer=25 option=coor columns=xcoor,ycoor
query_layer=25
-------------------
d.vect map=myfire_manylayers@user1 layer=25
type=point,line,boundary,area,face color=255:128:128 fill_color=yellow
width=1 icon=basic/point
-------------------
map query:

east, north: 635640.025007, 234049.31523
myfire_manylayers@user1:
  Type: Point
  Id: 17
  Layer: 1
  Category: 17
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers
  Key_column: cat
  Attributes:
    cat: 17
    ID: 0
    LABEL: RFD #17
    LOCATION: 4601 Pleasant Valley Rd
    CITY: Raleigh
    MUN_COUNT: M
    PUMPERS: 1
    PUMPER_TAN: 0
    TANKER: 0
    MINI_PUMPE: 0
    RESCUE_SER: 0
    AERIAL: 0
    BRUSH: 0
    OTHERS: 0
    WATER_RESC: 0
    MUNCOID: 1
    BLDGCODE: 257
    AGENCY: RF
    STATIONID: RF17
    RECNO: 19
    CV_SID2: RF17
    CVLAG: 0
myfire_manylayers@user1:
  Type: Point
  Id: 17
  Layer: 2
  Category: 17
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_2
  Key_column: cat
  Attributes:
    cat: 17
[...]
myfire_manylayers@user1:
  Type: Point
  Id: 17
  Layer: 25
  Category: 17
  Driver: sqlite
  Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
  Table: myfire_manylayers_25
  Key_column: cat
  Attributes:
    cat: 17
    xcoor: 635640.313379964
    ycoor: 234048.036434468
-------------------
v.what -a map=myfire_manylayers@user1 layer=25 coordinates=635642.103403,
234048.276032 distance=10
East: 635642.103403
North: 234048.276032
------------------------------------------------------------------
Map: myfire_manylayers
Mapset: user1
Type: Point
Id: 17
Layer: 1
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers
Key column: cat
cat : 17
ID : 0
LABEL : RFD #17
LOCATION : 4601 Pleasant Valley Rd
CITY : Raleigh
MUN_COUNT : M
PUMPERS : 1
PUMPER_TAN : 0
TANKER : 0
MINI_PUMPE : 0
RESCUE_SER : 0
AERIAL : 0
BRUSH : 0
OTHERS : 0
WATER_RESC : 0
MUNCOID : 1
BLDGCODE : 257
AGENCY : RF
STATIONID : RF17
RECNO : 19
CV_SID2 : RF17
CVLAG : 0
Layer: 2
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_2
Key column: cat
cat : 17
Layer: 3
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_3
Key column: cat
cat : 17
Layer: 4
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_4
Key column: cat
cat : 17
Layer: 5
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_5
Key column: cat
cat : 17
Layer: 6
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_6
Key column: cat
cat : 17
Layer: 7
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_7
Key column: cat
cat : 17
Layer: 8
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_8
Key column: cat
cat : 17
Layer: 9
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_9
Key column: cat
cat : 17
Layer: 10
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_10
Key column: cat
cat : 17
Layer: 11
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_11
Key column: cat
cat : 17
Layer: 12
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_12
Key column: cat
cat : 17
Layer: 13
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_13
Key column: cat
cat : 17
Layer: 14
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_14
Key column: cat
cat : 17
Layer: 15
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_15
Key column: cat
cat : 17
Layer: 16
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_16
Key column: cat
cat : 17
Layer: 17
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_17
Key column: cat
cat : 17
Layer: 18
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_18
Key column: cat
cat : 17
Layer: 19
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_19
Key column: cat
cat : 17
Layer: 20
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_20
Key column: cat
cat : 17
Layer: 21
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_21
Key column: cat
cat : 17
Layer: 22
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_22
Key column: cat
cat : 17
Layer: 23
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_23
Key column: cat
cat : 17
Layer: 24
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_24
Key column
: cat
cat : 17
Layer: 25
Category: 17
Driver: sqlite
Database: J:\gisdata\nc_spm_08_grass7\user1\sqlite\sqlite.db
Table: myfire_manylayers_25
Key column: cat
cat : 17
xcoor : 635640.313379964
ycoor : 234048.036434468
-------------->

it seems that d.what.vect [1] reports always all data of all layers.

the same with v.what although the queried layer is specified.

so maybe a bug/enhancement ticket is needed.

[1] https://grass.osgeo.org/grass73/manuals/d.what.vect.html
[2] https://grass.osgeo.org/grass73/manuals/v.what.html

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5288923.html
Sent from the Grass - Users mailing list archive at Nabble.com.

[mlennert]

On 02/10/16 10:53, Helmut Kudrnovsky wrote:

it seems that d.what.vect [1] reports always all data of all layers.

the same with v.what although the queried layer is specified.

so maybe a bug/enhancement ticket is needed.

https://trac.osgeo.org/grass/ticket/3172

I've attached a patch to v.what. Please test if this solves your problem.

Moritz

[Dave_Roberts]

Thanks Helmut,

On 10/02/16 02:53, Helmut Kudrnovsky wrote:

{material deleted for space ...}

it seems that d.what.vect [1] reports always all data of all layers.

the same with v.what although the queried layer is specified.

so maybe a bug/enhancement ticket is needed.

[1] https://grass.osgeo.org/grass73/manuals/d.what.vect.html
[2] https://grass.osgeo.org/grass73/manuals/v.what.html

Just to be clear, in my case the problem was not that d.what.vect listed ALL the layers (that would have been OK although excessively verbose), but rather from click to click I might get different layers reported, and even different numbers of layers reported. Generally the one I wanted wasn't included or I would have ignored the problem.

Moritz has proposed a fix to the issue you noted, and it looks like it will likely solve my problem as well. That may take a while to find out though.

Thanks, Dave

[Dave_Roberts]

Thanks Moritz. This looks like the solution I was looking for.

However, I have not been successful at building GRASS from source for quite a long time (just tried again and generated fatal errors in over
50 directories), so it will be a little while before I can test the patch. At a first glance, much of it appears to be the use of a TAB in python code causing indentation problems, but that is clearly a different issue than v.what behavior.

The v.what Makefile has a few environment variables to sort out before I can isolate just that program and substitute it in, so I will report on test results as soon as I am able.

Thanks, Dave

On 10/02/16 06:23, Moritz Lennert wrote:

On 02/10/16 10:53, Helmut Kudrnovsky wrote:

it seems that d.what.vect [1] reports always all data of all layers.

the same with v.what although the queried layer is specified.

so maybe a bug/enhancement ticket is needed.

https://trac.osgeo.org/grass/ticket/3172

I've attached a patch to v.what. Please test if this solves your problem.

Moritz

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[neteler]

On Sun, Oct 2, 2016 at 7:12 PM, Dave Roberts <droberts@montana.edu> wrote:

Thanks Moritz. This looks like the solution I was looking for.

However, I have not been successful at building GRASS from source for quite
a long time (just tried again and generated fatal errors in over
50 directories),

I am happy to help offlist, as needed.

Markus

[hellik]

Dave Roberts wrote

Thanks Helmut,

On 10/02/16 02:53, Helmut Kudrnovsky wrote:

{material deleted for space ...}

it seems that d.what.vect [1] reports always all data of all layers.

the same with v.what although the queried layer is specified.

so maybe a bug/enhancement ticket is needed.

[1] https://grass.osgeo.org/grass73/manuals/d.what.vect.html
[2] https://grass.osgeo.org/grass73/manuals/v.what.html

Just to be clear, in my case the problem was not that d.what.vect listed
ALL the layers (that would have been OK although excessively verbose),
but rather from click to click I might get different layers reported,
and even different numbers of layers reported. Generally the one I
wanted wasn't included or I would have ignored the problem.

Moritz has proposed a fix to the issue you noted, and it looks like it
will likely solve my problem as well. That may take a while to find out
though.

Thanks, Dave
_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

Are all vector geometries of your data available in all layers?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5288958.html
Sent from the Grass - Users mailing list archive at Nabble.com.

[hellik]

Moritz Lennert wrote

On 02/10/16 10:53, Helmut Kudrnovsky wrote:

it seems that d.what.vect [1] reports always all data of all layers.

the same with v.what although the queried layer is specified.

so maybe a bug/enhancement ticket is needed.

https://trac.osgeo.org/grass/ticket/3172

I've attached a patch to v.what. Please test if this solves your problem.

Moritz

_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

tested r69647

nice addition.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5288990.html
Sent from the Grass - Users mailing list archive at Nabble.com.

[neteler]

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts <droberts@montana.edu> wrote:

Hi Markus,

    Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts). The primary problem was
python confusion, where arch linux assumes python3 as the default, and I had
not done the symbolic links correctly to redicrect to python2. After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully. I'm now testing GRASS-7.0.5.

Glad you solved it! Please verify if all here is ok:

https://grasswiki.osgeo.org/wiki/Compile_and_Install#Arch_Linux

Best,
Markus

[Maciej_Sieczka]

W dniu 03.10.2016 o 23:18, Markus Neteler pisze:

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts <droberts@montana.edu> wrote:

Hi Markus,

    Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts). The primary problem was
python confusion, where arch linux assumes python3 as the default, and I had
not done the symbolic links correctly to redicrect to python2. After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully. I'm now testing GRASS-7.0.5.

Hi Dave,

My PKGBUILD may help:
https://gitlab.com/tutturu/grass7_pkgbuild/blob/master/PKGBUILD.
Advertised on https://grass.osgeo.org/download/software/linux/.

Maciek

--
Maciej Sieczka
http://www.sieczka.org

[Dave_Roberts]

Markus, The material at the wiki (url below) did not work for me, but it DID provide the clues I needed to get things to work. I can't speak for other Arch linux users, but I don't have sudo configured and just su to root when necessary. So, the posted script failed when I didn't have permission to sudo ln -s. In addition, since I don't sudo, I don't quite understand the path being constructed. $HOME for someone using sudo is presumably their home directory (not root), and creating $HOME/usr/bin seems like an odd idea to me. so,

su
ln -s /usr/bin/python2.7 /usr/bin/python
ln -s /usr/bin/python2.7-config /usr/bin/python-config
exit

worked. That means that from now on python2 is the default, as opposed to python3, but I'm fine with that. Then, I don't have all the libraries required by the config command (notably liblas, maybe more), so the config command needed to be edited for me, and there were several libraries I didn't include in addition to freetype. Others may have different needs and experiences.

Again, I didn't sudo, but

make
su
make install
exit

worked of course. Finally, I now have /usr/bin/grass70 as GRASS-7.0.4
and /usr/local/bin/grass70 as GRASS-7.0.5. /usr/bin precedes /us/local/bin so I am at present entering /usr/local/bin/grass70 to start GRASS-7.0.5. I think

mv /usr/bih/grass70 /usr/bin/grass704
mv /usr/local/bin/grass70 /usr/bin/grass705

might be my solution to have both available.

Thanks, Dave

P.S. the subject on this rthread should probably have been switched to Arch linux GRASS build, but I left it alone to allow tracking

On 10/03/16 15:18, Markus Neteler wrote:

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts <droberts@montana.edu> wrote:

Hi Markus,

    Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts). The primary problem was
python confusion, where arch linux assumes python3 as the default, and I had
not done the symbolic links correctly to redicrect to python2. After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully. I'm now testing GRASS-7.0.5.

Glad you solved it! Please verify if all here is ok:

https://grasswiki.osgeo.org/wiki/Compile_and_Install#Arch_Linux

Best,
Markus

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David W. Roberts office 406-994-4548
Professor and Head FAX 406-994-3190
Department of Ecology email droberts@montana.edu
Montana State University
Bozeman, MT 59717-3460

[Dave_Roberts]

Dear Maciek,

     Thanks you sincerely for an updated PKGBUILD. If I delete the includes for liblas and python-termcolor it builds successfully. Whether or not my previous reassignment of /usr/bin/python (see response to Markus) had any effect or whether your PKGBUILD finessed that I don't know. Like the AUR PKGBUILD your PKGBUILD generated an extraordinary number of warnings about

  dlsym(acl_get_file): /usr/lib/libfakeroot/libfakeroot.so: undefined symbol: acl_get_file

As I expected

pacman -U grass7-7.0.5-1-x86_64.pkg.tar.xz

complained about conflicts with the existing GRASS7; when I approved an overwrite it installed fine.

    At any rate, since I did not edit what.c to apply Moritz's patch none of this affects my issues with map display query or d.what.vect. I'll get back to that in a subsequent post.

Thanks, Dave

On 10/03/16 15:46, Maciej Sieczka wrote:

W dniu 03.10.2016 o 23:18, Markus Neteler pisze:

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts <droberts@montana.edu>
wrote:

Hi Markus,

    Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts). The primary
problem was
python confusion, where arch linux assumes python3 as the default,
and I had
not done the symbolic links correctly to redicrect to python2.
After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully. I'm now testing GRASS-7.0.5.

Hi Dave,

My PKGBUILD may help:
https://gitlab.com/tutturu/grass7_pkgbuild/blob/master/PKGBUILD.
Advertised on https://grass.osgeo.org/download/software/linux/.

Maciek

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David W. Roberts office 406-994-4548
Professor and Head FAX 406-994-3190
Department of Ecology email droberts@montana.edu
Montana State University
Bozeman, MT 59717-3460

[hellik]

  >At any rate, since I did not edit what.c to apply Moritz's patch

none of this affects my issues with map display query or >d.what.vect.
I'll get back to that in a subsequent post.

Fyi

http://lists.osgeo.org/pipermail/grass-commit/2016-
October/040536.html

Anna committed the patch to trunk ; so if may be able to switch to trunk for
compiling, this v.what addition is available there without the need of
manually patching.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289152.html
Sent from the Grass - Users mailing list archive at Nabble.com.

[Dave_Roberts]

Thanks Helmut, Thanks Anna

I compiled the trunk version, and the map query tool now clearly behaves differently, but not how I expected

1) it shows all layers in the map query results, regardless of what layer (if any) was selected in d.vect

I.e.

d.vect map
d.vect map layer=1
v.vect map layer=2

all have identical results in map query. In addition, specifying layers that don't exist emits no warning, e.g. d.vect map layer=999
works fine, and behaves the same as any of the d.vect commands above

2) it highlights selected features in yellow, and the selected features (areas in my case) reflect layer #1, no matter what layer is requested in d.vect. I.e. d.vect map layer=2 map queries highlight layer 1.

I had been working on this with a quite complicated imported data set, so to isolate the behavior more clearly I created the data below

(file ascii.txt)
VERTI:
B 5
  0 0
  0 10
10 10
10 0
  0 0
C 1 1
  8 5
  1 1
B 5
10 0
10 10
20 10
20 0
10 0
C 1 1
18 5
   1 2
B 5
  3 3
  3 7
  7 7
  7 3
  3 3
C 1 1
  5 5
  1 2
B 5
13 3
13 7
17 7
17 3
13 3
C 1 1
15 5
  1 1
(end of file)

then

v.in.ascii input=ascii.txt output=ascii format=standard
g.region vect=ascii
v.category --overwrite option=add input=ascii output=new_ascii
     layer=2 type=centroid

# check results

v.category ascii op=report
# 1 layer, 4 centroids with cats 1 & 2
v.category new_ascii op=report
# 2 layers, L1 4 centroids with cats 1,2 L2 4 centroids cats=1,2,3,4

d.vect new_ascii layer=2

# and check results with map query tool

Thanks, Dave

On 10/04/16 01:31, Helmut Kudrnovsky wrote:

  >At any rate, since I did not edit what.c to apply Moritz's patch

none of this affects my issues with map display query or >d.what.vect.
I'll get back to that in a subsequent post.

Fyi

http://lists.osgeo.org/pipermail/grass-commit/2016-
October/040536.html

Anna committed the patch to trunk ; so if may be able to switch to trunk for
compiling, this v.what addition is available there without the need of
manually patching.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289152.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[mlennert]

On 04/10/16 13:55, Dave Roberts wrote:

Thanks Helmut, Thanks Anna

I compiled the trunk version, and the map query tool now clearly behaves
differently, but not how I expected

Please note: the patch that was applied was for v.what. At this stage, I haven't had the opportunity to look at the GUI, yet.

Could you test with v.what ?

Moritz

[hellik]

Dave Roberts wrote

Thanks Helmut, Thanks Anna

I compiled the trunk version, and the map query tool now clearly behaves
differently, but not how I expected

1) it shows all layers in the map query results, regardless of what
layer (if any) was selected in d.vect

I.e.

d.vect map
d.vect map layer=1
v.vect map layer=2

all have identical results in map query. In addition, specifying layers
that don't exist emits no warning, e.g. d.vect map layer=999
works fine, and behaves the same as any of the d.vect commands above

2) it highlights selected features in yellow, and the selected features
(areas in my case) reflect layer #1, no matter what layer is requested
in d.vect. I.e. d.vect map layer=2 map queries highlight layer 1.

I had been working on this with a quite complicated imported data set,
so to isolate the behavior more clearly I created the data below

(file ascii.txt)
VERTI:
B 5
  0 0
  0 10
10 10
10 0
  0 0
C 1 1
  8 5
  1 1
B 5
10 0
10 10
20 10
20 0
10 0
C 1 1
18 5
   1 2
B 5
  3 3
  3 7
  7 7
  7 3
  3 3
C 1 1
  5 5
  1 2
B 5
13 3
13 7
17 7
17 3
13 3
C 1 1
15 5
  1 1
(end of file)

then

v.in.ascii input=ascii.txt output=ascii format=standard
g.region vect=ascii
v.category --overwrite option=add input=ascii output=new_ascii
     layer=2 type=centroid

# check results

v.category ascii op=report
# 1 layer, 4 centroids with cats 1 & 2
v.category new_ascii op=report
# 2 layers, L1 4 centroids with cats 1,2 L2 4 centroids cats=1,2,3,4

d.vect new_ascii layer=2

# and check results with map query tool

Thanks, Dave

On 10/04/16 01:31, Helmut Kudrnovsky wrote:

  >At any rate, since I did not edit what.c to apply Moritz's patch

none of this affects my issues with map display query or >d.what.vect.
I'll get back to that in a subsequent post.

Fyi

http://lists.osgeo.org/pipermail/grass-commit/2016-
October/040536.html

Anna committed the patch to trunk ; so if may be able to switch to trunk
for
compiling, this v.what addition is available there without the need of
manually patching.

-----
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289152.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

AFAIK the map query hasn't been changed by Anna's commit.

v. what (https://grass.osgeo.org/grass73/manuals/v.what.html) has a changed
behaviour by now reckognizing the specified layer.

the same behaviour for the map query may need a separate enhancement ticket.

in the meantime would be v.what an alternative?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289199.html
Sent from the Grass - Users mailing list archive at Nabble.com.

[Dave_Roberts]

Dear Moritz and Helmut,

     v.what works perfectly; thanks for that. Sadly, the issue reflects my misunderstanding. I thought the map display GUI was calling v.what with coordinates extracted by the GUI from the mouse click. I have been talking about the map display query tool on wx# all along, so I apologize if I have used the wrong vocabulary to describe the problem.

     File PERMANENT/.tmp/hostname/MONITORS/wx0/cmd correctly reflects the layer request from d.vect, so it shouldn't be too difficult to get the GUI query tool to honor that, but I'm just beginning to dig into GRASS source code and I wouldn't want to tackle this yet.

Thanks, Dave

On 10/04/16 06:32, Helmut Kudrnovsky wrote:

Dave Roberts wrote

Thanks Helmut, Thanks Anna

I compiled the trunk version, and the map query tool now clearly behaves
differently, but not how I expected

1) it shows all layers in the map query results, regardless of what
layer (if any) was selected in d.vect

I.e.

d.vect map
d.vect map layer=1
v.vect map layer=2

all have identical results in map query. In addition, specifying layers
that don't exist emits no warning, e.g. d.vect map layer=999
works fine, and behaves the same as any of the d.vect commands above

2) it highlights selected features in yellow, and the selected features
(areas in my case) reflect layer #1, no matter what layer is requested
in d.vect. I.e. d.vect map layer=2 map queries highlight layer 1.

I had been working on this with a quite complicated imported data set,
so to isolate the behavior more clearly I created the data below

material deleted to reduce the length

Fyi

http://lists.osgeo.org/pipermail/grass-commit/2016-
October/040536.html

Anna committed the patch to trunk ; so if may be able to switch to trunk
for
compiling, this v.what addition is available there without the need of
manually patching.

-----
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289152.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

AFAIK the map query hasn't been changed by Anna's commit.

v. what (https://grass.osgeo.org/grass73/manuals/v.what.html) has a changed
behaviour by now reckognizing the specified layer.

the same behaviour for the map query may need a separate enhancement ticket.

in the meantime would be v.what an alternative?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289199.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[annakrat]

On Tue, Oct 4, 2016 at 10:48 AM, Dave Roberts <droberts@montana.edu> wrote:

Dear Moritz and Helmut,

    v.what works perfectly; thanks for that. Sadly, the issue reflects my
misunderstanding. I thought the map display GUI was calling v.what with
coordinates extracted by the GUI from the mouse click. I have been talking
about the map display query tool on wx# all along, so I apologize if I have
used the wrong vocabulary to describe the problem.

    File PERMANENT/.tmp/hostname/MONITORS/wx0/cmd correctly reflects the
layer request from d.vect, so it shouldn't be too difficult to get the GUI
query tool to honor that, but I'm just beginning to dig into GRASS source
code and I wouldn't want to tackle this yet.

Thanks, Dave

It should be fairly simple to add. First it has to be changed in
library function vector_what, then in GUI. Please create a ticket for
that.

Anna

On 10/04/16 06:32, Helmut Kudrnovsky wrote:

Dave Roberts wrote

Thanks Helmut, Thanks Anna

I compiled the trunk version, and the map query tool now clearly behaves
differently, but not how I expected

1) it shows all layers in the map query results, regardless of what
layer (if any) was selected in d.vect

I.e.

d.vect map
d.vect map layer=1
v.vect map layer=2

all have identical results in map query. In addition, specifying layers
that don't exist emits no warning, e.g. d.vect map layer=999
works fine, and behaves the same as any of the d.vect commands above

2) it highlights selected features in yellow, and the selected features
(areas in my case) reflect layer #1, no matter what layer is requested
in d.vect. I.e. d.vect map layer=2 map queries highlight layer 1.

I had been working on this with a quite complicated imported data set,
so to isolate the behavior more clearly I created the data below

material deleted to reduce the length

Fyi

http://lists.osgeo.org/pipermail/grass-commit/2016-
October/040536.html

Anna committed the patch to trunk ; so if may be able to switch to trunk
for
compiling, this v.what addition is available there without the need of
manually patching.

-----
best regards
Helmut
--
View this message in context:

http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289152.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

AFAIK the map query hasn't been changed by Anna's commit.

v. what (https://grass.osgeo.org/grass73/manuals/v.what.html) has a
changed
behaviour by now reckognizing the specified layer.

the same behaviour for the map query may need a separate enhancement
ticket.

in the meantime would be v.what an alternative?

-----
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289199.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user