QGIS » QGIS Application

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

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

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?

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 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.

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.