[GRASS5] Can't get d.vect to display my data from PostGRASS

Craig_Funk · May 19, 2004, 7:09pm

Opps, this message may get posted twice - i apologize!

Hello Grass Developers. I am using GRASS 5.7 with PostGIS. I have
converted an e00 file using avcimport
(http://avce00.maptools.org/avce00/) and imported the files into
PostGRASS server.

The file is very large, however I can only see one polygon. There should
be 1000's. I pushed up the debugging level and some of the (hopefully)
relevant output is below:

The log file is 11Mb, so here is a snippet:
<snip>
D1/3: display areas:
D2/3: n_areas = 0
D1/3: Vect_Rewind(): name = bntl_bc
D3/3: Vect_read_line()
D3/3: V2_read_line_post(): line = 1
D3/3: Vect__Read_line_post(): id = 301
D3/3: select type, NumPoints(geom) , Dimension(geom) FROM bntl_bc_geom
where id = 301;
D3/3: store type = 2 n_points = 7
D3/3: DECLARE gcursor BINARY CURSOR FOR SELECT ASBINARY(
force_2d(geom), 'xdr') FROM bntl_bc_geom WHERE id = 301
D3/3: FETCH ALL in gcursor
D3/3: wkb length = 121
D3/3: np = 2
D3/3: SELECT field, cat FROM bntl_bc_cat WHERE id = 301;
D3/3: gType = 2 -> type = 2
D3/3: Vect_read_line()
D3/3: V2_read_line_post(): line = 2
D3/3: Vect__Read_line_post(): id = 301
D3/3: select type, NumPoints(geom) , Dimension(geom) FROM bntl_bc_geom
where id = 301;
D3/3: store type = 2 n_points = 7
D3/3: DECLARE gcursor BINARY CURSOR FOR SELECT ASBINARY(
force_2d(geom), 'xdr') FROM bntl_bc_geom WHERE id = 301
D3/3: FETCH ALL in gcursor
D3/3: wkb length = 121
D3/3: np = 2
D3/3: SELECT field, cat FROM bntl_bc_cat WHERE id = 301;
D3/3: gType = 2 -> type = 2
D3/3: Vect_read_line()
D3/3: V2_read_line_post(): line = 3
D3/3: Vect__Read_line_post(): id = 301
D3/3: select type, NumPoints(geom) , Dimension(geom) FROM bntl_bc_geom
where id = 301;
D3/3: store type = 2 n_points = 7
D3/3: DECLARE gcursor BINARY CURSOR FOR SELECT ASBINARY(
force_2d(geom), 'xdr') FROM bntl_bc_geom WHERE id = 301
D3/3: FETCH ALL in gcursor
D3/3: wkb length = 121
<snip>

Note the id=301.

What is that and where does it come from? I did not specify that
anywhere in a query, and I suspect that is why I only get one polygon. I
am a novice with PostGIS, but I took a look at id=301 in Postgres in the
table bntl_bc_geom and this is what is there:

301 | 2 | SRID=-1;LINESTRING(1551506.75 505591.8125,1558783.5
506437.65625,1566056.5 507288.3125,1564843.5 518251.875,1557581.875
517397.5625,1550317.125 516547.34375,1551506.75 505591.8125)

In total there is 17185 rows in the table.

Also...I have imported other e00 files that have less than 300 lines of
data in the tables. d.vect crashes with a bus error. When I try to
display a subset of the data using d.vect I get warning messages:
"WARNING: Cannot select line 301 from database"

So where does the 301 come from, and how can I get rid of it?

Thanx in advance,
Craig

Craig_Funk · May 19, 2004, 9:42pm

Since posting the last message, I executed a v.build on the map. Now all the ids are 0 (instead of 301) and I get a bus error from d.vect. I am not very familar with the GRASS code, but it appears that Line->offset is always 0 in V2_read_line_post():
Line = Map->plus.Line[line];
return Vect__Read_line_post (Map, line_p, line_c, Line->offset);

Could this mean that the files in the GRASS database are not built properly? Or have i screwed something up somewhere?

Craig

On 19-May-04, at 1:09 PM, Funkmeister wrote:
<snip>

Note the id=301.

<snip>

Radim_Blazek · May 20, 2004, 5:38am

On Wednesday 19 May 2004 23:42, you wrote:

Since posting the last message, I executed a v.build on the map. Now
all the ids are 0 (instead of 301) and I get a bus error from d.vect. I
am not very familar with the GRASS code, but it appears that
Line->offset is always 0 in V2_read_line_post():
Line = Map->plus.Line[line];
return Vect__Read_line_post (Map, line_p, line_c, Line->offset);

Could this mean that the files in the GRASS database are not built
properly? Or have i screwed something up somewhere?

Craig

On 19-May-04, at 1:09 PM, Funkmeister wrote:
<snip>

> Note the id=301.

PostGIS support was removed from GRASS 5.7.
http://grass.itc.it/pipermail/grassuser/2004-May/025539.html

Radim

Craig_Funk · May 20, 2004, 2:19pm

Thank you Radim, I did not see that posting previously.

What would be the best approach for using a PostGIS database with GRASS? Import the shp file with shp2pgsql and then link to the PostGIS database as described in your posting?

Thanks again,
Craig

On 19-May-04, at 11:38 PM, Radim Blazek wrote:

On Wednesday 19 May 2004 23:42, you wrote:

Since posting the last message, I executed a v.build on the map. Now
all the ids are 0 (instead of 301) and I get a bus error from d.vect. I
am not very familar with the GRASS code, but it appears that
Line->offset is always 0 in V2_read_line_post():
Line = Map->plus.Line[line];
return Vect__Read_line_post (Map, line_p, line_c, Line->offset);

Could this mean that the files in the GRASS database are not built
properly? Or have i screwed something up somewhere?

Craig

On 19-May-04, at 1:09 PM, Funkmeister wrote:
<snip>

Note the id=301.

PostGIS support was removed from GRASS 5.7.
http://grass.itc.it/pipermail/grassuser/2004-May/025539.html

Radim

Radim_Blazek · May 20, 2004, 4:30pm

On Thursday 20 May 2004 16:19, Funkmeister wrote:

Thank you Radim, I did not see that posting previously.

What would be the best approach for using a PostGIS database with
GRASS? Import the shp file with shp2pgsql and then link to the PostGIS
database as described in your posting?

Yes, it is one possibility, but it is better to import data to GRASS,
because topology for OGR data sources is not fully supported.

Radim

Thanks again,
Craig

On 19-May-04, at 11:38 PM, Radim Blazek wrote:
> On Wednesday 19 May 2004 23:42, you wrote:
>> Since posting the last message, I executed a v.build on the map. Now
>> all the ids are 0 (instead of 301) and I get a bus error from d.vect.
>> I
>> am not very familar with the GRASS code, but it appears that
>> Line->offset is always 0 in V2_read_line_post():
>> Line = Map->plus.Line[line];
>> return Vect__Read_line_post (Map, line_p, line_c, Line->offset);
>>
>> Could this mean that the files in the GRASS database are not built
>> properly? Or have i screwed something up somewhere?
>>
>> Craig
>>
>> On 19-May-04, at 1:09 PM, Funkmeister wrote:
>> <snip>
>>
>>> Note the id=301.
>
> PostGIS support was removed from GRASS 5.7.
> http://grass.itc.it/pipermail/grassuser/2004-May/025539.html
>
> Radim