[GRASS5] Re: vector point dataset

[Helena]

Brent,

can you write me more about what you are doing?
Which version of GRASS are you using, what are your inputs
(ascii sites, vector points), what is the resolution and size
of the resulting grid, which program are you using to create the DEM
(s.to.rast, s.surf.idw, s.surf.rst or their v.* versions for 5.7),
and where exactly are you having problems.
We have a project (with authors of r.terraflow) for computing massive DEMs
and your data set looks like the size that we are aiming at, but there may be
other bottlenecks in GRASS than gridding so we need to look at those too.

Thank you,

Helena

Do you know which method is used by GMT to build the model?

Radim Blazek wrote:
> 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
> 
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5