Opened 13 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: | |
---|---|---|---|
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 , 12 years ago
Keywords: | vector layer added |
---|
follow-up: 3 comment:2 by , 12 years ago
Should be fixed in r55137. Now, layers listed with v.category (and not v.db.connect) are shown. Please test.
Anna
follow-up: 4 comment:3 by , 12 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
follow-up: 5 comment:4 by , 12 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?
follow-up: 6 comment:5 by , 12 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
follow-up: 7 comment:6 by , 12 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
follow-up: 8 comment:7 by , 12 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
follow-up: 9 comment:8 by , 12 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
follow-up: 10 comment:9 by , 12 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
follow-up: 11 comment:10 by , 12 years ago
comment:11 by , 12 years ago
follow-ups: 13 14 comment:12 by , 12 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
comment:13 by , 12 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
comment:14 by , 12 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 , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Tested successfully also on Windows so I close the ticket.
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?