[GRASS5] Problem with shapefile
David D Gray
ddgray at armadce.demon.co.uk
Fri Nov 15 22:19:02 EST 2002
Virgilio Gómez Rubio wrote:
> Hi all,
> GRASS:~/tmp > v.support option=build -r map=cod_munici
> Selected information from vector header
> 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
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:
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
> 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
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
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.
More information about the grass-dev