Could anyone give me a quick rundown on the different line, boundary, node, and centroid colors in v.digit 6.1.cvs?
Thanks,
Kirk
The colors are described on symbology tab in settings.
Radim
On 3/2/06, Kirk R. Wythers <kwythers@umn.edu> wrote:
Could anyone give me a quick rundown on the different line, boundary,
node, and centroid colors in v.digit 6.1.cvs?Thanks,
Kirk
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Radim,
I would like to hear your thoughts concerning what appears to be fairly odd behavior in v.digit. First some background.
I am working with some vectors that were digitized by students using ESRI products. The students then saved their work as shape files. I am double checking their work and using v.digit (6.1.cvs) to make a few edits (where my interpretation is a little different from theirs) and add attributes to areas.
The vector is connected to a single table in postgresql.
In 90% of the cases were I select a centroid, or line, or an area, the expected results get printed to for form which pop up.
However, in a few cases, when I select a centroid, the form pops up with 3 tabs at the top (Layer 1, Layer 1, Layer2)
The two layer 1 tabs will different information in the fields (including different cat values), and the layer 2 tab, says "Database connection not defined"
g.list shows the vector name to be "test",
v.info shows 1 dblink. and the -c option shows:
GRASS 6.1.cvs (minnesota_utm):~ > v.info -c test
Displaying column types/names for database connection of layer 1:
INTEGER|cat
INTEGER|id
CHARACTER|type
CHARACTER|class
GRASS 6.1.cvs (minnesota_utm):~ >
GRASS 6.1.cvs (minnesota_utm):~ > v.info -c test layer=2
Displaying column types/names for database connection of layer 2:
ERROR: Database connection not defined
Any idea what might have happened? or how to get rid of the ghost layer1?
Thanks,
Kirk
On 3/3/06, Kirk R. Wythers <kwythers@umn.edu> wrote:
Radim,
I would like to hear your thoughts concerning what appears to be
fairly odd behavior in v.digit. First some background.I am working with some vectors that were digitized by students using
ESRI products. The students then saved their work as shape files. I
am double checking their work and using v.digit (6.1.cvs) to make a
few edits (where my interpretation is a little different from theirs)
and add attributes to areas.The vector is connected to a single table in postgresql.
In 90% of the cases were I select a centroid, or line, or an area,
the expected results get printed to for form which pop up.However, in a few cases, when I select a centroid, the form pops up
with 3 tabs at the top (Layer 1, Layer 1, Layer2)The two layer 1 tabs will different information in the fields
(including different cat values), and the layer 2 tab, says "Database
connection not defined"
This is all correct. v.in.ogr must clean the topology but it
preserves all input data. In this case there were 2 overlaping
areas in the input. GRASS created one topologicaly clean
area (without overlaps) linked to 2 records (original attributes of
the 2 areas). Those are the 2 tabs for Layer 1.
Because this happens quite often when a shapefile is imported
and in most cases it means errors (overlaps) in input data
v.in.ogr adds for convenience a new layer 2 with number
of categories in Layer 1. Using Layer 2 it is very easy
to visualize and identify all errors in the input data.
Radim
g.list shows the vector name to be "test",
v.info shows 1 dblink. and the -c option shows:
GRASS 6.1.cvs (minnesota_utm):~ > v.info -c test
Displaying column types/names for database connection of layer 1:
INTEGER|cat
INTEGER|id
CHARACTER|type
CHARACTER|class
GRASS 6.1.cvs (minnesota_utm):~ >GRASS 6.1.cvs (minnesota_utm):~ > v.info -c test layer=2
Displaying column types/names for database connection of layer 2:
ERROR: Database connection not definedAny idea what might have happened? or how to get rid of the ghost
layer1?Thanks,
Kirk
On Mar 6, 2006, at 3:07 AM, Radim Blazek wrote:
On 3/3/06, Kirk R. Wythers <kwythers@umn.edu> wrote:
Radim,
I would like to hear your thoughts concerning what appears to be
fairly odd behavior in v.digit. First some background.I am working with some vectors that were digitized by students using
ESRI products. The students then saved their work as shape files. I
am double checking their work and using v.digit (6.1.cvs) to make a
few edits (where my interpretation is a little different from theirs)
and add attributes to areas.The vector is connected to a single table in postgresql.
In 90% of the cases were I select a centroid, or line, or an area,
the expected results get printed to for form which pop up.However, in a few cases, when I select a centroid, the form pops up
with 3 tabs at the top (Layer 1, Layer 1, Layer2)The two layer 1 tabs will different information in the fields
(including different cat values), and the layer 2 tab, says "Database
connection not defined"This is all correct. v.in.ogr must clean the topology but it
preserves all input data. In this case there were 2 overlaping
areas in the input. GRASS created one topologicaly clean
area (without overlaps) linked to 2 records (original attributes of
the 2 areas). Those are the 2 tabs for Layer 1.Because this happens quite often when a shapefile is imported
and in most cases it means errors (overlaps) in input data
v.in.ogr adds for convenience a new layer 2 with number
of categories in Layer 1. Using Layer 2 it is very easy
to visualize and identify all errors in the input data.Radim
Thanks Radim,
In this case, one of the "Layer 1s" is just plain wrong and the best thing to do is delete it. I thought to use db.droptable, but that command is not available (has it been removed?). Additionally, since the second Layer 1 is not a "real" table in postgres. I don't see that it would work anyway.
I think the question here is... Is there a way to correct someone else's accidental double coding of a polygon by removing the offending layer?
Kirk
g.list shows the vector name to be "test",
v.info shows 1 dblink. and the -c option shows:
GRASS 6.1.cvs (minnesota_utm):~ > v.info -c test
Displaying column types/names for database connection of layer 1:
INTEGER|cat
INTEGER|id
CHARACTER|type
CHARACTER|class
GRASS 6.1.cvs (minnesota_utm):~ >GRASS 6.1.cvs (minnesota_utm):~ > v.info -c test layer=2
Displaying column types/names for database connection of layer 2:
ERROR: Database connection not definedAny idea what might have happened? or how to get rid of the ghost
layer1?Thanks,
Kirk
On 3/6/06, Kirk R. Wythers <kwythers@umn.edu> wrote:
On Mar 6, 2006, at 3:07 AM, Radim Blazek wrote:
> On 3/3/06, Kirk R. Wythers <kwythers@umn.edu> wrote:
>> Radim,
>>
>> I would like to hear your thoughts concerning what appears to be
>> fairly odd behavior in v.digit. First some background.
>>
>> I am working with some vectors that were digitized by students using
>> ESRI products. The students then saved their work as shape files. I
>> am double checking their work and using v.digit (6.1.cvs) to make a
>> few edits (where my interpretation is a little different from theirs)
>> and add attributes to areas.
>>
>> The vector is connected to a single table in postgresql.
>>
>> In 90% of the cases were I select a centroid, or line, or an area,
>> the expected results get printed to for form which pop up.
>>
>> However, in a few cases, when I select a centroid, the form pops up
>> with 3 tabs at the top (Layer 1, Layer 1, Layer2)
>>
>> The two layer 1 tabs will different information in the fields
>> (including different cat values), and the layer 2 tab, says "Database
>> connection not defined"
>
> This is all correct. v.in.ogr must clean the topology but it
> preserves all input data. In this case there were 2 overlaping
> areas in the input. GRASS created one topologicaly clean
> area (without overlaps) linked to 2 records (original attributes of
> the 2 areas). Those are the 2 tabs for Layer 1.
>
> Because this happens quite often when a shapefile is imported
> and in most cases it means errors (overlaps) in input data
> v.in.ogr adds for convenience a new layer 2 with number
> of categories in Layer 1. Using Layer 2 it is very easy
> to visualize and identify all errors in the input data.
>
> RadimThanks Radim,
In this case, one of the "Layer 1s" is just plain wrong and the best
thing to do is delete it. I thought to use db.droptable, but that
command is not available (has it been removed?). Additionally, since
the second Layer 1 is not a "real" table in postgres. I don't see
that it would work anyway.
There is onle ONE layer 1, but TWO records.
You just need to delete the record and category
on the centroid using 'Delete' button in 'Display categories'
windows or 'Delete' button in attibutes windows in QGIS.
Radim
I think the question here is... Is there a way to correct someone
else's accidental double coding of a polygon by removing the
offending layer?Kirk
>
>> g.list shows the vector name to be "test",
>>
>> v.info shows 1 dblink. and the -c option shows:
>>
>> GRASS 6.1.cvs (minnesota_utm):~ > v.info -c test
>> Displaying column types/names for database connection of layer 1:
>> INTEGER|cat
>> INTEGER|id
>> CHARACTER|type
>> CHARACTER|class
>> GRASS 6.1.cvs (minnesota_utm):~ >
>>
>> GRASS 6.1.cvs (minnesota_utm):~ > v.info -c test layer=2
>> Displaying column types/names for database connection of layer 2:
>> ERROR: Database connection not defined
>>
>> Any idea what might have happened? or how to get rid of the ghost
>> layer1?
>>
>> Thanks,
>>
>> Kirk
>>
>>
>>
>>
>>
>>
On Mar 6, 2006, at 7:25 AM, Radim Blazek wrote:
There is onle ONE layer 1, but TWO records.
You just need to delete the record and category
on the centroid using ‘Delete’ button in ‘Display categories’
windows or ‘Delete’ button in attibutes windows in QGIS.
Radim
Thanks again Radim. With your patient explanations, I am finally starting to understand this stuff (and better yet, fix problems that were created when I or someone else did not understand this stuff).
Kirk