[GRASS5] Re: v.digit odd attribute behavior

[Kirk R. Wythers]

On Mar 6, 2006, at 3:07 AM, Radim Blazek wrote:

> On 3/3/06, Kirk R. Wythers <kwythers at 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 defined
>>
>> Any idea what might have happened? or how to get rid of the ghost
>> layer1?
>>
>> Thanks,
>>
>> Kirk
>>
>>
>>
>>
>>
>>