[GRASS5] Re: vector point dataset

[Radim Blazek]

Brent Wood wrote:
> Thank you for following this up, 'tis appreciated.
> 
> Hmm.... I'm not using GRASS much, mostly GMT/QGIS/PostGIS, but I want to
> do more with GRASS. I appreciate your comment on the value of indices for
> points. I guess with modern hard drives the space is not a huge issue, and
> the time taken to import the file & create the index is only a once off,
> whereas queries are likely to be ongoing.
> 
> A typical use for me, would be taking 120,000,000 point elevations and
> building a DEM. I have mainly used GMT for this, so hope to simply import
> the GMT netCDF grids (so far unsuccesfully), but I was also interested in
> building the model with GRASS, as it supposedly has some excellent tools
> for this. I've tried a few times, but so far I have been unable to get a
> DEM built by GRASS.
> 
> GMT takes about 3 hrs on a fast PC. The same box with GRASS has been
> running for 15hrs with no result. I do need to look into this more, & it
> is not directly in answer to your question, but is background to what I'm
> trying to achieve with GRASS.
> 
> As long as GRASS was doing what it should, & the index files are useful I
> have no problem with them being built.

Can you specify better which GRASS modules do you use?
v.in.ascii creates by default attribute table, that is slow as
it is using SQL to write data to a database. Try to run v.in.ascii
with '-t' flag.

For v.surf.rst and v.surf.idw, both opens vector with support files
(topology, spatial index, category index). We could consider also 
reading vectors without support files. Currently category index is not 
used anyway but it can be useful if only small part of input points
is used. RST library used by v.surf.rst also uses topology
to get nodes for connected lines to don't duplicate line end points.


In general, vector modules usually open vectors with support files,
which can be slow for large files. We should check all modules if it is 
necessary. It may be, that even modules which select features by box
could be faster without spatial index if read all features only once
(v.surf.*,v.to.rast,...) but modules which need to search many times
certainly need spatial index (e.g. v.distance, v.select, ...).

Until now, we were trying to get things working, no we can look
better also at performance.

> Something I'm not aware of is the approach used by GRASS57 for accessing
> data from a PostGIS table. If the points were stored in PostGIS and
> accessed by GRASS, I presume GRASS would not build an index. I have not
> yet tried to build a DEM using GRASS to work with points in PostGIS.

You can define external data source with v.external. v.external
also creates support files, but you can also create link to external
data in text editor. That is not solution however, because v.surf.*
will ask you to build topology.

Radim