Opened 8 years ago

Closed 7 years ago

#1606 closed defect (fixed)

WXGUI regression - attribute query tool reports "nothing found" when clicking on a vector object

Reported by: marisn Owned by: grass-dev@…
Priority: blocker Milestone: 6.4.3
Component: wxGUI Version: 6.4.3 RCs
Keywords: query Cc:
CPU: Unspecified Platform: Unspecified

Description

Steps to reproduce:

  • add a vector map with objects on layers 1 and 2
  • set layer and category parameters in d.vect to ensure that displayed objects have CATs
  • click on any object => "Nothing found" is reported.

Perform same steps in 6.4.0 and it gives object information:

East: 604649.560021
North: 6391439.273022
Map: celi_un_pilsetas 
Mapset: PERMANENT
Type: Point
Id: 18730
Layer: 2
Category: 8

Setting this issue as a blocker, as:

  • it's a regression
  • it prevents users from reading object CAT values required for an input in v.net.* modules
  • it breaks workflow descriptions that where made for 6.4.0/1 releases.

Change History (15)

comment:1 Changed 8 years ago by martinl

To better understand, you are referring to the map which has no attribute table linked to the layer 1 or 2, right?

comment:2 Changed 7 years ago by annakrat

This should be fixed for GRASS 7 by this r52832. Please could you test it with your data so that I can backport it before release?

Thanks, Anna

comment:3 Changed 7 years ago by marisn

Tested with GRASS 7 and works. Please backport to 6.4.3 to bring back previously broken functionality.

Related discussion on how it could work better is in #1703

comment:4 Changed 7 years ago by annakrat

Resolution: fixed
Status: newclosed

Backported in r52853, r52855 so I'm closing this ticket.

Anna

comment:5 Changed 7 years ago by marisn

Resolution: fixed
Status: closedreopened
Version: 6.4.26.4.3 RCs

Just tested with 6.4.3RC2 on Windows and issue still is present. When I display objects from layer 2, I still get "nothing found". Still it might be related to #1605

comment:6 Changed 7 years ago by annakrat

Keywords: query added

Sorry if I misunderstood the problem but I have just tested it (Linux, Windows) and I get right results. I created new vector in digitizer without db connection and created two areas, one (centroid) with layer 1 and cat 1 and second in layer 2 with cat 1. Querying outputs expected results.

Module v.what used for queries does not know anything about d.vect options layer and cats. Maybe there should be some connection but this is a different problem.

Anna

comment:7 in reply to:  6 Changed 7 years ago by hellik

Replying to annakrat:

Sorry if I misunderstood the problem but I have just tested it (Linux, Windows) and I get right results. I created new vector in digitizer without db connection and created two areas, one (centroid) with layer 1 and cat 1 and second in layer 2 with cat 1. Querying outputs expected results.

Module v.what used for queries does not know anything about d.vect options layer and cats. Maybe there should be some connection but this is a different problem.

tested here with

System Info                                                                     
GRASS version: 6.4.3svn                                                         
GRASS SVN Revision: 55073                                                       
GIS Library Revision: 50937 (2012-02-25)                                        
GDAL/OGR: 1.9.2                                                                 
PROJ4: Rel. 4.8.0, 6 March 2012                                                 
Python: 2.7.2                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)

and a self digitized vector (without attribute table for layer 1 and 2) and areas and lines in both layers:

layer1

v.what --v -a map=susi@user1 east_north=633585.748944,224051.026304 distance=229.193251
Building spatial index...
East: 633585.748944
North: 224051.026304
Map: susi 
Mapset: user1
Type: Area
Sq Meters: 22795916.264
Hectares: 2279.592
Acres: 5632.994
Sq Miles: 8.8016
Layer: 1
Category: 1
(Sun Feb 17 18:49:29 2013) Command finished (0 sec)   

layer2

v.what --v -a map=susi@user1 east_north=642295.092471,223982.268329 distance=229.193251
Building spatial index...
East: 642295.092471
North: 223982.268329
Map: susi 
Mapset: user1
Type: Area
Sq Meters: 14761474.121
Hectares: 1476.147
Acres: 3647.640
Sq Miles: 5.6994
Layer: 2
Category: 2

seems to work.

Helmut

comment:8 Changed 7 years ago by marisn

Just retested with 18 feb. 6.4.3 SVN build for Windows. Bug is still present.

Here are exact steps to reproduce in Spearfish:

v.net input=roads@PERMANENT points=archsites@PERMANENT output=roads_to_archsites operation=connect thresh=1000

Use WXGUI to query attribute data of any of archsites in roads_to_archsites map. It is required as v.net.* modules need CATs for start/end nodes.

Sorry about that d.vect reference, as I was falsely assuming that GUI is querying only on displayed level.

PS. Helmut - You are right. There is no problem with v.what as it works as expected. The problem is in WXGUI.

comment:9 Changed 7 years ago by annakrat

The problem is that one layer is connected to database and one is not. So we can test if this situation happens and then redirect the v.what output to the gui command console instead of showing the vector feature attribute dialog (the same as when you query more vector maps at once). There is no consistent behaviour at all but at least you don't loose any data.

Or we can backport new querying from grass 7 (with the new dialog) which should work more consistently. This is maybe too much new but it was tested on all platforms successfully.

Anna

comment:10 in reply to:  9 Changed 7 years ago by marisn

Replying to annakrat:

The problem is that one layer is connected to database and one is not. So we can test if this situation happens and then redirect the v.what output to the gui command console instead of showing the vector feature attribute dialog (the same as when you query more vector maps at once). There is no consistent behaviour at all but at least you don't loose any data.

Or we can backport new querying from grass 7 (with the new dialog) which should work more consistently. This is maybe too much new but it was tested on all platforms successfully.

Anna

I would vote for redirecting plain, old v.what output. It's better to have all data than consistent way. I would also say -1 for backporting, as GRASS 7 differs from 6 and thus some rarely used combination might crop up just after release as there might be not enough time to test all aspects (like d.vect default layer option). Let's better work on 7.

comment:11 Changed 7 years ago by annakrat

In case there exist layers of vector map which are not connected to db, the query output is redirected in command console (r55184). This is the easiest solution, other solutions would need more changes which means more possible errors.

Anna

comment:12 in reply to:  11 ; Changed 7 years ago by mlennert

Replying to annakrat:

In case there exist layers of vector map which are not connected to db, the query output is redirected in command console (r55184). This is the easiest solution, other solutions would need more changes which means more possible errors.

Thanks ! It would be great, however, to be able to copy directly from the display, instead of having to copy everything to the clipboard, copy that to a text editor and then pick out the elements you want. As an example: sometimes I just want to identify the coordinates of a place. It would be nice to be able to click on it and then directly copy the values for easting and northing from the query results window.

Moritz

comment:13 in reply to:  12 ; Changed 7 years ago by annakrat

Replying to mlennert:

Replying to annakrat:

In case there exist layers of vector map which are not connected to db, the query output is redirected in command console (r55184). This is the easiest solution, other solutions would need more changes which means more possible errors.

Thanks ! It would be great, however, to be able to copy directly from the display, instead of having to copy everything to the clipboard, copy that to a text editor and then pick out the elements you want. As an example: sometimes I just want to identify the coordinates of a place. It would be nice to be able to click on it and then directly copy the values for easting and northing from the query results window.

You are talking about new querying in grass7? It is different than in grass 64, it is more consistent. But needs some improvemnets. Could you create a ticket for this? As for the coordinates, you can get them by right click on the map display.

Anna

comment:14 in reply to:  13 ; Changed 7 years ago by mlennert

Replying to annakrat:

Replying to mlennert:

Replying to annakrat:

In case there exist layers of vector map which are not connected to db, the query output is redirected in command console (r55184). This is the easiest solution, other solutions would need more changes which means more possible errors.

Thanks ! It would be great, however, to be able to copy directly from the display, instead of having to copy everything to the clipboard, copy that to a text editor and then pick out the elements you want. As an example: sometimes I just want to identify the coordinates of a place. It would be nice to be able to click on it and then directly copy the values for easting and northing from the query results window.

You are talking about new querying in grass7?

Yes, sorry. I got confused between versions here. The grass6 solution also works well, by the way. I'm just afraid that it will be a bit confusing for users to see two different reactions to the same action (either editable attributes or output to console).

It is different than in grass 64, it is more consistent. But needs some improvemnets. Could you create a ticket for this? As for the coordinates, you can get them by right click on the map display.

Thanks for the tip on coordinates (hadn't noticed this, yet, it's very practical !), but my remark was more general. I'll file a ticket.

Moritz

comment:15 in reply to:  14 Changed 7 years ago by mlennert

Resolution: fixed
Status: reopenedclosed

Replying to mlennert:

The grass6 solution also works well, by the way. I'm just afraid that it will be a bit confusing for users to see two different reactions to the same action (either editable attributes or output to console).

I think, that despite of the issue of two different reactions mentioned above, we can close this ticket as the issue is solved and any better solution should be (and is being) worked on in grass7.

Please reopen if necessary.

Moritz

Note: See TracTickets for help on using tickets.