[GRASS5] Problem with shapefile

[David D Gray]

Virgilio Gómez Rubio wrote:
> Hi all,
> 
> [...]
> 
> GRASS:~/tmp > v.support option=build -r map=cod_munici
> err=err_cod_munici
> 
> V.SUPPORT:
> 
> Selected information from vector header
>  Organization:
>  Map Name:      cod_munici
>  Source Date:
>  Orig. Scale:   2400
>  Snapping threshold    0.00
> Snapp No snapping will be done
>     Reading Vector file 100%
>     Building areas 100%
> Unclosed area, free end or edge inside area: line 771
> Unclosed area, free end or edge inside area: line 773
> Unclosed area, free end or edge inside area: line 777
> Unclosed area, free end or edge inside area: line 828
> Unclosed area, free end or edge inside area: line 829
> Unclosed area, free end or edge inside area: line 1774
> Unclosed area, free end or edge inside area: line 1776
>     Building islands 100%
>     Attaching labels
> PNT_TO_AREA failed: (765673.634168, 4491702.952495) (Category 12052)
> PNT_TO_AREA failed: (768903.289024, 4484561.074964) (Category 12100)
> PNT_TO_AREA failed: (718003.592441, 4386435.398790) (Category 46070)
> PNT_TO_AREA failed: (712646.684383, 4382275.341311) (Category 46116)
> WARNING: area 176 label: 46902 matched another label: 12066.
> PNT_TO_AREA failed: (714668.427559, 4382979.700161) (Category 46903)
> PNT_TO_AREA failed: (717899.462949, 4378108.989802) (Category 46190)
>  Number of lines:   1876
>  Number of nodes:   1244
>  Number of areas:   651
>  Number of isles:   28
>  Number of atts :   652
>  Number of unattached atts :   6
>  Snapped lines  :   0
> 

Hi,

The most likely reason is that the areas do not build because there are 
'topologically incorrect' features in the affected polygons - for 
example, one polygon edge has a vertex where its neighbour has none, for 
example, as follows:

-------------A----------------B-------------------------C-----
-------------A------------------------------------------C-----

The stable release of the import process recognises the loop A-B-C-A as 
a 'degenerate' polygon, but the build process detects it as an error, so 
the the areas adjacent to the affected segment do not build.

> 
> I think the problem is related to that unclosed areas, but it is also
> true that ArcVIew reads the shapefile without problems.
> 

It may appear that ArcView has no problems but its display does not 
check to see if polygons are correctly matched with their neighbours. 
This can affect various processing algorithms (ie ArcScripts) as well as 
the attribute table. For example the degenerate polygons may or may not 
be listed in the DBF file. (What you expect of course is that they 
shoudn't be)

> Any idea?
> 

The best procedure is to track down the problem polygons with v.digit 
and eliminate the offending lines.

0) Back up the attributes file in dig_att under the mapset. This is just 
cd'ing to the dig_att directory and copying the file to something 
convenient.
1) Use Tools | o to highlight the problem areas.
2) The option Tools|n will help to track down which of the polygons 
edges are problems. v.rm.dangles might help also.
3) When you are confident a particular line is a duplicate or otherwise 
problem edge, you can go back to the top level and use Edit|r to remove it.
4) When the bad edges have been fixed, go back to the dig_att directory, 
resotore the atts file to the correct name and then rebuild.

> Of course, if some developer wants to try the shapefile I can send it to
> him/her.
> 

In a former version v.in.shape went to considerable lengths to try and 
elliminate many errors automatically, but this ended up introducing far 
more problems than it solved. The current version is at the other 
extreme - it import maps as they are, and if there are problems they 
must be fixed manually. A revision of the module is in progress that 
will remove errors only of the kind described above. In usable maps 99% 
of errors are caused this way anyway. If there are more serious errors, 
the map is pretty corrupt anyway, and maybe then you should request the 
source to provide a better set of files.

David