Opened 12 years ago

Closed 11 years ago

#1605 closed defect (fixed)

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

Reported by: marisn Owned by: grass-dev@…
Priority: major Milestone: 6.4.3
Component: wxGUI Version: 6.4.2
Keywords: vector layer Cc:
CPU: Unspecified Platform: Unspecified

Description

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.

Change History (15)

comment:1 by annakrat, 11 years ago

Keywords: vector layer added

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?

comment:2 by annakrat, 11 years ago

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

Anna

in reply to:  2 ; comment:3 by mmetz, 11 years ago

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

in reply to:  3 ; comment:4 by martinl, 11 years ago

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?

in reply to:  4 ; comment:5 by mmetz, 11 years ago

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

in reply to:  5 ; comment:6 by annakrat, 11 years ago

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

in reply to:  6 ; comment:7 by mmetz, 11 years ago

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

in reply to:  7 ; comment:8 by annakrat, 11 years ago

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

in reply to:  8 ; comment:9 by mmetz, 11 years ago

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

in reply to:  9 ; comment:10 by annakrat, 11 years ago

Replying to mmetz:

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

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

in reply to:  10 comment:11 by mlennert, 11 years ago

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

comment:12 by hamish, 11 years ago

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

in reply to:  12 comment:13 by marisn, 11 years ago

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

in reply to:  12 comment:14 by mlennert, 11 years ago

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

comment:15 by annakrat, 11 years ago

Resolution: fixed
Status: newclosed

Tested successfully also on Windows so I close the ticket.

Note: See TracTickets for help on using tickets.