[GRASS5] v.in.shape missing some polygons

When I import shapefiles using v.in.shape almost everything goes ok, except for some polygons, that show up the lines, but have no values, which means that when I convert the vector file to raster there is nothing. I tried changing the colinearity tolerance and the snap distance, but the result is the same.
I tried exporting one of these images back as a E00 and the polygons that didn't show up had a value of zero. I changed manually the values to 1 and re-exported to shapefile, imported in GRASS, etc. and I got the same result.

Is this some known bug or am I doing something wrong?

Thanks,

Gualter

Gualter Barbas Baptista wrote:

When I import shapefiles using v.in.shape almost everything goes ok, except for some polygons, that show up the lines, but have no values, which means that when I convert the vector file to raster there is nothing. I tried changing the colinearity tolerance and the snap distance, but the result is the same.
I tried exporting one of these images back as a E00 and the polygons that didn't show up had a value of zero. I changed manually the values to 1 and re-exported to shapefile, imported in GRASS, etc. and I got the same result.

Is this some known bug or am I doing something wrong?

Thanks,

Gualter

Hi

It is a known bug. It happens when a polygon is imported after all the surounding polygons have been imported. This was originally a `feature' to try and get round the annoying frequency with which (at least older versions of) ArcView generated multiple copies of the same polygon, usually simple island polygons. Unfortunately it had this side-effect for some cell-like polygons, ie those with many neighbours.

The next release of v.in.shape should be free of this.

David

Gualter Barbas Baptista wrote:

Is there some workaround for this (like exporting to some other format with Arcview) while it's not fixed?

Thanks,

Gualter

Can you get a script to export as e00? That should have the properly deconstructed linework, and attributes with topology already built, so it is then, if all else is OK, a direct import into GRASS. Similarly for DLG (there never used to be a DLG export for GRASS, but it's a while since I looked), or maybe SDTS.

Otherwise, there are some tools, like XTools, that can export the `centroids' as a point theme. These are a set of representative interior points, one for each polygon, not true centroids in the geometric sense, so can be used to carry the attributes of the associated polygons.

If you include the X and Y readings in the theme database, then that can be converted to a text file easily and you then have the data you need.

This next bit is a bit `hacky', but I occasionally use it myself for various reasons:

1) Use something like `awk' or `sed' to morph the lines of text in the text file created above so each line has the following fields, in this order with spaces separating:

A <X-coord> <Y-coord> <your chosen numeric attribute>

Note the `A' is literal and *must* be uppercase.

2) Drop this manually into the dig_att directory as a file with the name of the target polygon coverage. This will probably replace the existing file (which you might want to back up).

3) Rebuild the map with `v.support option=build'.

You can carry out the above three stages with a sites_list file as well, if you import the centroids coverage with s.in.shape. But some people have reported this gives errors as well, on some platforms.

David

David D Gray wrote:

Gualter Barbas Baptista wrote:

When I import shapefiles using v.in.shape almost everything goes ok, except for some polygons, that show up the lines, but have no values, which means that when I convert the vector file to raster there is nothing. I tried changing the colinearity tolerance and the snap distance, but the result is the same.
I tried exporting one of these images back as a E00 and the polygons that didn't show up had a value of zero. I changed manually the values to 1 and re-exported to shapefile, imported in GRASS, etc. and I got the same result.

Is this some known bug or am I doing something wrong?

Thanks,

Gualter

Hi

It is a known bug. It happens when a polygon is imported after all the surounding polygons have been imported. This was originally a `feature' to try and get round the annoying frequency with which (at least older versions of) ArcView generated multiple copies of the same polygon, usually simple island polygons. Unfortunately it had this side-effect for some cell-like polygons, ie those with many neighbours.

The next release of v.in.shape should be free of this.

David

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Your solution ("hacking" the file in dig_att) worked perfectly! After two days trying to figure out a solution to this, it's really good to see all those polygons drawed.

This bug should be on the top priority for fixing :wink:

Thanks,

Gualter

David D Gray wrote:

Gualter Barbas Baptista wrote:

Is there some workaround for this (like exporting to some other format with Arcview) while it's not fixed?

Thanks,

Gualter

Can you get a script to export as e00? That should have the properly deconstructed linework, and attributes with topology already built, so it is then, if all else is OK, a direct import into GRASS. Similarly for DLG (there never used to be a DLG export for GRASS, but it's a while since I looked), or maybe SDTS.

Otherwise, there are some tools, like XTools, that can export the `centroids' as a point theme. These are a set of representative interior points, one for each polygon, not true centroids in the geometric sense, so can be used to carry the attributes of the associated polygons.

If you include the X and Y readings in the theme database, then that can be converted to a text file easily and you then have the data you need.

This next bit is a bit `hacky', but I occasionally use it myself for various reasons:

1) Use something like `awk' or `sed' to morph the lines of text in the text file created above so each line has the following fields, in this order with spaces separating:

A <X-coord> <Y-coord> <your chosen numeric attribute>

Note the `A' is literal and *must* be uppercase.

2) Drop this manually into the dig_att directory as a file with the name of the target polygon coverage. This will probably replace the existing file (which you might want to back up).

3) Rebuild the map with `v.support option=build'.

You can carry out the above three stages with a sites_list file as well, if you import the centroids coverage with s.in.shape. But some people have reported this gives errors as well, on some platforms.

David

David D Gray wrote:

Gualter Barbas Baptista wrote:

When I import shapefiles using v.in.shape almost everything goes ok, except for some polygons, that show up the lines, but have no values, which means that when I convert the vector file to raster there is nothing. I tried changing the colinearity tolerance and the snap distance, but the result is the same.
I tried exporting one of these images back as a E00 and the polygons that didn't show up had a value of zero. I changed manually the values to 1 and re-exported to shapefile, imported in GRASS, etc. and I got the same result.

Is this some known bug or am I doing something wrong?

Thanks,

Gualter

Hi

It is a known bug. It happens when a polygon is imported after all the surounding polygons have been imported. This was originally a `feature' to try and get round the annoying frequency with which (at least older versions of) ArcView generated multiple copies of the same polygon, usually simple island polygons. Unfortunately it had this side-effect for some cell-like polygons, ie those with many neighbours.

The next release of v.in.shape should be free of this.

David

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5