When running v.select on a vector coverage with attributes stored in a relational database (MySQL), the new coverage of selected polygons is associated with a new table that has as many entries as the original table, even though the number of selected polygons is significantly smaller. Is this a bug, or is there another way of getting an attribute table that contains only the attributes for the selected polygons?
Running 5.7 on OSX 10.3
Thanks
Chris Fonnesbeck
--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia
On Wednesday 07 January 2004 21:57, Christopher Fonnesbeck wrote:
When running v.select on a vector coverage with attributes stored in a
relational database (MySQL), the new coverage of selected polygons is
associated with a new table that has as many entries as the original
table, even though the number of selected polygons is significantly
smaller. Is this a bug, or is there another way of getting an attribute
table that contains only the attributes for the selected polygons?
Running 5.7 on OSX 10.3
More or less bug, I did not have time to write db_copy_table_where()
so db_copy_table is used and all records are written to output.
Radim
On Jan 8, 2004, at 4:34 AM, Radim Blazek wrote:
On Wednesday 07 January 2004 21:57, Christopher Fonnesbeck wrote:
When running v.select on a vector coverage with attributes stored in a
relational database (MySQL), the new coverage of selected polygons is
associated with a new table that has as many entries as the original
table, even though the number of selected polygons is significantly
smaller. Is this a bug, or is there another way of getting an attribute
table that contains only the attributes for the selected polygons?
Running 5.7 on OSX 10.3
More or less bug, I did not have time to write db_copy_table_where()
so db_copy_table is used and all records are written to output.
Can I then use v.extract to get the proper attribute table?
Thanks,
Chris
--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia
On Jan 8, 2004, at 4:34 AM, Radim Blazek wrote:
On Wednesday 07 January 2004 21:57, Christopher Fonnesbeck wrote:
When running v.select on a vector coverage with attributes stored in a
relational database (MySQL), the new coverage of selected polygons is
associated with a new table that has as many entries as the original
table, even though the number of selected polygons is significantly
smaller. Is this a bug, or is there another way of getting an attribute
table that contains only the attributes for the selected polygons?
Running 5.7 on OSX 10.3
More or less bug, I did not have time to write db_copy_table_where()
so db_copy_table is used and all records are written to output.
I need to get some type of (temporary) solution to this problem, since an output layer with the wrong attribute table is not very useful. Is there a way of getting at the cats of the new coverage and using them with v.extract? I don't mind doing some C programming, if thats what it takes, but I am not experienced with the GRASS C API, so hints would be welcome.
Thanks,
Chris
--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia