Feature request #554
identify - some varchar column displayed instead of the key column
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | Tim Sutton | ||
Category: | Vectors | ||
Pull Request or Patch supplied: | Resolution: | worksforme | |
Easy fix?: | No | Copied to github as #: | 10613 |
Description
When I'm querying a GRASS vector I get a strange result that a varchar column (which is not the key column) is mentioned twice - see the attached picture.
Please note that the key column is "cat", not the "name":
$ v.db.connect -p cieki12_2zl Vector map <cieki12_2zl> is connected by: layer <1> table <cieki12_2zl> in database </home/grassdata/caves_utm33/melio2/dbf/> through driver <dbf> with key <cat>
Maciek
History
#1 Updated by Redmine Admin over 17 years ago
This problem is not reproducible with all GRASS vectors - usually a correct key is reported.
To reproduce it use the attached GRASS vector "wrong_key" form location/mapset "wrong_key/wrong_key".
Maciek
#2 Updated by Tim Sutton over 17 years ago
Moved to milestone 0.8.2 since we wont be fixing any further issues before the 0.8.1 release
#3 Updated by leolami - over 16 years ago
You can obtain the same behavior also with other OGR vector (es. shapes)
#4 Updated by Tim Sutton about 16 years ago
- Status changed from Open to In Progress
Hi
I believe this is in fact intended behaviour as the QgsVectorLayer author implemented it :
207 // If fldName is provided, use it as the display field, otherwise 208 // determine the field index for the feature column of the identify 209 // dialog. We look for fields containing "name" first and second for 210 // fields containing "id". If neither are found, the first field 211 // is used as the node.
Unless I am completely misunderstanding the issue...
One thing I did notice is that when I tried to change the display field to 'cat' using the test dataset provided above, the display field only showed 'name' as an option. Perhaps we need to allow display field to be set to non string fields. I will investigate futher.
In the meantime please clarify any misunderstanding I have - I would like to move this ticket from bug to enhancement and from status major to enhancement and remove must fix annotation. I await your feedback.
Regards
Tim
#5 Updated by Tim Sutton about 16 years ago
- Status changed from In Progress to Closed
- Resolution set to fixed
Hi
Ok another update on this. I found the problem causing display field combo box issues in vector props dialog (applied as . For me the issue is resolved now following this procedure:
- load supplied 'wrong key' dataset
- open vector properties
- select general tab
- select 'cat' for display field
- close vector properties
- use identify tool to select a feature
Result is shown in the attached screenie (https://trac.osgeo.org/qgis/attachment/ticket/554/ticket_554.jpeg).
I'm marking this ticket as fixed now. Please reopen if it does not work for you.
Regards
Tim
#6 Updated by Maciej Sieczka - about 16 years ago
- Status changed from Closed to Feedback
- Resolution deleted (
fixed)
Replying to [comment:6 timlinux]:
For me the issue is resolved now following this procedure:
- load supplied 'wrong key' dataset
- open vector properties
- select general tab
- select 'cat' for display field
- close vector properties
- use identify tool to select a feature
You did not understand the issue. It is that QGIS fails to recognise the real key column of the GRASS vector's dbf table. In case of the example vector map the key column is cat, not name. See the output of a command which confirms it:
$ v.db.connect -p wrong_key Vector map <wrong_key@wrong_key> is connected by: layer <1> table <wrong_key> in database </home/grassdata/wrong_key/wrong_key/dbf/> through driver <dbf> with key <cat>
In case of GRASS the id is "category" and nothing else ("category" is the official name in GRASS lingo). If the vector map has a table attached, the table contains a "key column" where "categories" are stored, and which lets link the vector features having "categories" with their attributes in the table. Usually the "key column" name is "cat", but it can be anything. v.db.connect -p can be used to detect the "key column" name.
Anyway, in case of GRASS vectors it would be best to just use the "category" number as the node and not bother with detecting the "key column" at all (mind that GRASS allows multiple features to have the same "category", which provides the same functionality as Shapefile's or PostGIS multi- feautures). If that's not possible now, please at least default to the real key column.
I don't know what would be the right approach for other formats, but it looks very strange when in case of a Shapefile which has e.g. 2 columns 'area' and 'length' one of them is used for the node. Wouldn't the "OGRFeature" be a better node candidate?
#7 Updated by Jürgen Fischer about 15 years ago
- Resolution set to worksforme
- Status changed from Feedback to Closed
Replying to [comment:7 msieczka]:
Replying to [comment:6 timlinux]:
For me the issue is resolved now following this procedure:
- load supplied 'wrong key' dataset
- open vector properties
- select general tab
- select 'cat' for display field
- close vector properties
- use identify tool to select a featureYou did not understand the issue. It is that QGIS fails to recognise the real key column of the GRASS vector's dbf table. In case of the example vector map the key column is cat, not name.
I don't see the problem here. In the identify dialog you don't see the key at the top, you see the display field.
So there's no relation between the key and the display field.