WXGUI d.vect doesn't offer all vector map layers in a dropdown list

[marisn]

Steps to reproduce:

• Add a vector map with more than one layer
• Go to properties -> selection
• Layer option has only "-1" and "1" as options, "2" is missing
• Enter "2" manually to ensure that objects are present and are rendered correctly for layer "2".

Setting priority major as it might lead users to wrong conclusions that only single layer is present for the vector map.

[annakrat]

It lists only layers which are connected do database. Can we simply backport this ​method? There is some comment (line 763) which I don't understand much and I am also not sure about the dsn parameter.

It might be better to move the functionality (=list all layers of vector map) in core.utils. Currently there is a function for getting all layers connected to DB.

Do we need to distinguish in dialogs if we want all layers or only the ones which are connected to DB?

[annakrat]

Should be fixed in r55137. Now, layers listed with v.category (and not v.db.connect) are shown. Please test.

Anna

[mmetz]

Replying to annakrat:

Now, layers listed with v.category (and not v.db.connect) are shown.

Not good. This method was used some years ago, but it makes the GUI even slower than it is already. Therefore v.category was no longer used to get the vector's layers. v.db.connect is usually very fast, but v.category takes some time for a larger vector.

Please revert this change.

Markus M

[martinl]

Replying to mmetz:

Replying to annakrat:

Now, layers listed with v.category (and not v.db.connect) are shown.

Not good. This method was used some years ago, but it makes the GUI even slower than it is already. Therefore v.category was no longer used to get the vector's layers. v.db.connect is usually very fast, but v.category takes some time for a larger vector.

Please revert this change.

any other suggestion? Store number of layers in header file?

[mmetz]

Replying to martinl:

Replying to mmetz:

Replying to annakrat:

Now, layers listed with v.category (and not v.db.connect) are shown.

Not good. This method was used some years ago, but it makes the GUI even slower than it is already. Therefore v.category was no longer used to get the vector's layers. v.db.connect is usually very fast, but v.category takes some time for a larger vector.

Please revert this change.

any other suggestion? Store number of layers in header file?

Alternatively, v.category could get a new option for option, something like option=layers which would print out only layer numbers, one per line. This would be fast if topology is available because in this case the internal category index can be used and the vector map would need to be opened with head only. Without topology, option=layers would print nothing.

Markus M

[annakrat]

Replying to mmetz:

Replying to martinl:

Replying to mmetz:

Replying to annakrat:

Now, layers listed with v.category (and not v.db.connect) are shown.

Not good. This method was used some years ago, but it makes the GUI even slower than it is already. Therefore v.category was no longer used to get the vector's layers. v.db.connect is usually very fast, but v.category takes some time for a larger vector.

Please revert this change.

Reverted.

any other suggestion? Store number of layers in header file?

Alternatively, v.category could get a new option for option, something like option=layers which would print out only layer numbers, one per line. This would be fast if topology is available because in this case the internal category index can be used and the vector map would need to be opened with head only. Without topology, option=layers would print nothing.

Is this change possible now for grass 64?

Anna

[mmetz]

Replying to annakrat:

Replying to mmetz:

Replying to martinl:

any other suggestion? Store number of layers in header file?

Alternatively, v.category could get a new option for option, something like option=layers which would print out only layer numbers, one per line. This would be fast if topology is available because in this case the internal category index can be used and the vector map would need to be opened with head only. Without topology, option=layers would print nothing.

Is this change possible now for grass 64?

In theory yes, we can add new functionality as long as existing functionality is not changed.

Please try trunk r55140.

Markus M

[annakrat]

Replying to mmetz:

Replying to annakrat:

Replying to mmetz:

Replying to martinl:

any other suggestion? Store number of layers in header file?

Alternatively, v.category could get a new option for option, something like option=layers which would print out only layer numbers, one per line. This would be fast if topology is available because in this case the internal category index can be used and the vector map would need to be opened with head only. Without topology, option=layers would print nothing.

Is this change possible now for grass 64?

In theory yes, we can add new functionality as long as existing functionality is not changed.

Please try trunk r55140.

Thanks, it works, could you backport it (at least the v.category part)?

Anna

[mmetz]

Replying to annakrat:

Replying to mmetz:

Replying to annakrat:

Replying to mmetz:

Replying to martinl:

any other suggestion? Store number of layers in header file?

Alternatively, v.category could get a new option for option, something like option=layers which would print out only layer numbers, one per line. This would be fast if topology is available because in this case the internal category index can be used and the vector map would need to be opened with head only. Without topology, option=layers would print nothing.

Is this change possible now for grass 64?

In theory yes, we can add new functionality as long as existing functionality is not changed.

Please try trunk r55140.

Thanks, it works, could you backport it (at least the v.category part)?

I have backported the v.category part in r55142-3.

Markus M

[annakrat]

Replying to mmetz:

I have backported the v.category part in r55142-3.

Thanks, the rest is done r55145. Please, could others test?

[mlennert]

Replying to annakrat:

Replying to mmetz:

I have backported the v.category part in r55142-3.

Thanks, the rest is done r55145. Please, could others test?

A quick test here doesn't show any problems. Seems to work for me on Debian GNU/Linux.

Moritz

[hamish]

Hi,

sorry I am coming late to this conversation, and I mostly work with rasters so am a bit thin on the category layer know-how, but to summarize, the trouble was that you can have multiple layers of categories connected to topological data features within the same map, and each of those layers may or may not have a DB connection specified in vector/$MAP/dbln, right?

So using v.db.connect -g only listed the layers with DB connections, and missed the layers that existed as category-only. But the new v.category option will list all that exist w/ or w/o a DB connection. (note not used very much, but as in v.db.connect -g the layer number can have a /name alias too. that might only be widely used in DBs like Oracle, or a "for the future" idea from Radim?)

is that right?

To help me visualize using layers better, could someone suggest a use case for when you'd use this? (the whole thing is a little mysterious to me)

trying to understand, Hamish

[marisn]

Replying to hamish:

To help me visualize using layers better, could someone suggest a use case for when you'd use this? (the whole thing is a little mysterious to me)

Here You go: ​https://trac.osgeo.org/grass/ticket/1606#comment:8

[mlennert]

Replying to hamish:

To help me visualize using layers better, could someone suggest a use case for when you'd use this? (the whole thing is a little mysterious to me)

Check out:

​http://grass.osgeo.org/grass64/manuals/vectorintro.html ("Vector object categories and attribute management")

and

for the network analysis cases Maris hinted at:

​http://grass.osgeo.org/grass64/manuals/v.net.html

Moritz

[annakrat]

Tested successfully also on Windows so I close the ticket.