v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.

[pertusus]

On a location with a longitude latitude projection I do a map that corresponds with the grid, like:

rows_nr=`g.region -g |grep '^rows=' |sed 's/^rows=//'`
r.mapcalc "grid_map=col() + ((row()-1) * $rows_nr)"
r.to.vect input=grid_map out=grid_map_v feature=area

g.region -p
projection: 3 (Latitude-Longitude)
zone:       0
datum:      ** unknown (default: WGS84) **
ellipsoid:  wgs84
north:      90N
south:      90S
west:       180W
east:       180E
nsres:      0:30
ewres:      0:30
rows:       360
cols:       720
cells:      259200

In another location, where the region is:

projection: 99 (Lambert Azimuthal Equal Area)
zone:       0
datum:      ** unknown (default: WGS84) **
ellipsoid:  sphere
north:      4149500
south:      -5044500
west:       -4368500
east:       4367500
nsres:      1000
ewres:      1000
rows:       9194
cols:       8736
cells:      80318784

I try to project the vector and I get an assertion:

v.proj input="grid_map_v" location="cru_maps"
Building topology for vector map <grid_map_v>...
Registering primitives...
v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.
Aborted

In the svn version the file and the assertion is at lib/vector/rtree/split.c and the bug may be fixed. I can try to reproduce on the svn version if you give me some directions on how to test in source.

[pertusus]

In the lambert location:

g.proj -j
+proj=laea
+lat_0=5
+lon_0=20
+x_0=0
+y_0=0
+no_defs
+a=6370997
+b=6370997
+to_meter=1

In the lonlat location:

g.proj -j
+proj=longlat
+a=6378137
+rf=298.257223563
+no_defs

[mmetz]

Assertion happens only if the whole globe gets reprojected from lonlat to laea, but not if only the current region extends of laea get reprojected to laea.

Although it looks like the assertion prevented you from an illegal reprojection, the assertion should not happen. The changes to the vector spatial index in grass7 can not be backported because the spatial index in grass7 has been nearly completely rewritten and is incompatible with the grass6.x spatial index. The code in question has been replaced by another algorithm written anew from scratch. In short, this is unlikely to get fixed in grass6.x.

Markus M

[neteler]

See also ticket #674

[neteler]

Close as "wontfix" (for GRASS 6)?

[mmetz]

Replying to neteler:

Close as "wontfix" (for GRASS 6)?

Closed as "wontfix" because 1) it is quite difficult to reproject the whole globe from latlon to laea without causing all sorts of numerical instabilities since laea is not meant to represent the whole globe, 2) the spatial index of GRASS 7 will not be backported.

Markus M