[GRASS5] GRASS -> SF

[Radim Blazek]

On Monday 23 February 2004 19:31, Morten Hulden wrote:
> On Sat, 21 Feb 2004, Morten Hulden wrote:
> > So, for me it would be very useful if I could interface the vector data
> > in Postgis from both Mapserver and Grass. I use Grass alot for raster map
> > generating and v.digitizing, but Grass is becoming a little 'isolated'
> > now from the vector storage. Maybe there is something in 5.7 that I don't
> > know about, but I haven't been able to get it to compile yet :-(
>
> Only yesterday I managed to compile 5.7 so I got a chance to test Postgis
> connectivity. (--with-nls causes errors in lib/raster/io.c, PACKAGE not
> defined)
>
> Vectors and attributes in Postgis/Postgres works fine, but areas are very,
> very slow to render. As I understand it only lines and points are stored
> in Postgris, but topology is rebuilt each time the monitor is redrawn.
> That is bound to be slow, especially as the whole map is rebuilt, not only
> the visible area.

No, topology is built once when the vector is created. I think that slow
is to read boundaries by id from PostGIS to compose areas. This is fast
on disk (set offset and read coordinates) but slow with database
(create - send - parse query, send - recieve data).

> It should be possible to make it faster, e.g. by using the Postgis BBOX
> function to build only visible areas. To store full polygons in Postgis of
> cause would help too, but that may not be easy to achieve. Maybe through
> views?
>
> Retrieving full polygons is very fast, so Postgis itself is not the
> problem; retrieving thousands of polygons and lines reprojecting them on
> the fly takes only a few seconds in Mapserver.

I don't say that PostGIS is the problem, the problem is that GRASS data 
model is so different from SF. 

I think that the key problem is how to get line coordinates selected by
line id faster. Usually this is not problem for PostGIS clients 
because selection is done on server side. If GRASS loops through
areas it must for each area read boundaries by boundary id.
'select ... where id = x' may never be fast enough.
So it must select everything and access results by tuple number
PQgetvalue(). But nobody seems to be interested in contributions
to vectors and I have other things to do. 

Another interesting thing would be to write areas as polygons to 
PostGIS table when Vect_build is run or the map is updated on level 2.
That way areas digitised in GRASS would be accessible directly
in PostGIS.

Radim