v.in.shape error

GRASS GRASS user
1

I have updated to the latest v.in.shape source, and I am still getting the
same error. I get the following when I run it ...

"vtd42071" successfully opened
Creating dig_att(L) file "vtd42071"
v.in.shape: shp2dig.c:751: partCalcFieldsPolygon: Assertion `fabs(newx1) < 1.0e10 && fabs(newx2) < 1.0e10' failed.
Aborted (core dumped)

The same thing happens whether I use the defaults or smaller for the snap
distance. Should I be setting the resolution lower? I have it set at :01"
now, but I have tried 0:00:00.01 with no difference.

Brian

On Mon, 11 Sep 2000, David D Gray wrote:

Brian

I managed to import your files to the required projection.

1) I used v.in.shape (most recent snapshot - actually with the default
values reduced further). This was imported to a LL location with the
following settings:

    +40.34
  -76.74 -75.85
    +39.70

  NSres 0.001
  EWres 0.001

Import parameters snapdist=0.0000001 sliver=0.0001

2) Create a UTM location with the following settings:

    4465523.252
  350836.065 427811.811
    4395595.396

  NSres 5
  EWres 5

  Spheroid airy (you will prob choose something else)
  Zone: 18

calculated from (1) with m.ll2u

3) In UTM projection, imported the map from the LL location with v.proj

4) Build with scale set to [1:]200

Result:

No unassigned attributes, but quite a lot of unlabelled areas. The map
sems to have many little slivers, cut corners, generally quite poor
topology. Ah well, you get this with shape files (not those made by
GRASS mind you :slight_smile: but most others from the common sources).

I think the bugs that were causing the problems are those that havebeen
fixed since Beta8 was released.

David

2

"Joseph Brian Adams, PhD" wrote:

I have updated to the latest v.in.shape source, and I am still getting the
same error. I get the following when I run it ...

"vtd42071" successfully opened
Creating dig_att(L) file "vtd42071"
v.in.shape: shp2dig.c:751: partCalcFieldsPolygon: Assertion `fabs(newx1) < 1.0e10 && fabs(newx2) < 1.0e10' failed.
Aborted (core dumped)

The same thing happens whether I use the defaults or smaller for the snap
distance. Should I be setting the resolution lower? I have it set at :01"
now, but I have tried 0:00:00.01 with no difference.

Brian

Brian

This really looks like a bug in the centroid (re-)location routines.
However I've not been able to repeat it or see what might be causing it,
even when tracking with gdb.

The values set for snap distance and sliver have to be decimal values at
present. Map units (or degrees for LL) for the snap distance, and
degrees (used to be radians but this was confusing so it was changed)
for the sliver. It could be set to accept DMS values if that would be
convenient.

Did you specify the value in decimal? I'm not sure what would happen if
you put a string like `0:00:00.01'. I suspect it would be interpreted as
0.0, which could explain things - I get a core dump (but without the
`assert' error) when I specify anything less than 1.0e-7 for the snap
distance in this map. Also have you tried the settings that worked for
me (as below)?

David

On Mon, 11 Sep 2000, David D Gray wrote:
> Brian
>
> I managed to import your files to the required projection.
>
> 1) I used v.in.shape (most recent snapshot - actually with the default
> values reduced further). This was imported to a LL location with the
> following settings:
>
>
> +40.34
> -76.74 -75.85
> +39.70
>
> NSres 0.001
> EWres 0.001
>
> Import parameters snapdist=0.0000001 sliver=0.0001
>
>
> 2) Create a UTM location with the following settings:
>
> 4465523.252
> 350836.065 427811.811
> 4395595.396
>
> NSres 5
> EWres 5
>
> Spheroid airy (you will prob choose something else)
> Zone: 18
>
> calculated from (1) with m.ll2u
>
>
> 3) In UTM projection, imported the map from the LL location with v.proj
>
> 4) Build with scale set to [1:]200
>
> Result:
>
> No unassigned attributes, but quite a lot of unlabelled areas. The map
> sems to have many little slivers, cut corners, generally quite poor
> topology. Ah well, you get this with shape files (not those made by
> GRASS mind you :slight_smile: but most others from the common sources).
>
> I think the bugs that were causing the problems are those that havebeen
> fixed since Beta8 was released.
>
>
> David