Moritz Lennert wrote:
Markus:
If an old vector is opened just for reading (v.what, v.info, probably
also d.vect), the fastest solution is probably to only load the header
of the spatial index, as is done for the coor file, and perform spatial
queries in file. This is very fast AFAIKT.
Then
On Wed, 24 Jun 2009, Markus GRASS wrote:
Paul Kelly wrote:
On Tue, 23 Jun 2009, Markus GRASS wrote:
My implementation is completely file based, also when creating or
updating a vector. This comes obviously with a speed penalty because
reading in memory is faster than reading from file. With
Hamish wrote:
Moritz wrote:
The largest file I have used is about 125000 areas with a
topo file weighing 42M, so taking your worst estimation,
this would mean around 200MB of spatial index, which is
still largely acceptable for me.
lidar and swath bathymetry data will easily have
Markus M wrote:
Lidar is a special case, I don't see a reason to drag along
with them topo and the spatial index, maybe the spatial index, but
not topo
there is nothing at all special about lidar data, it's just a bunch of
x,y,z points. (often with other variables like signal return strength)
Paul Kelly wrote:
Markus:
What are memory-mapped files? Excuse my ignorance, I'm just a
self-trained coder (learning by doing).
http://en.wikipedia.org/wiki/Memory-mapped_file
A chunk of a disk file is directly mapped into memory so you can
access it using normal pointers as if it was
Hi,
2009/6/25 Glynn Clements gl...@gclements.plus.com:
[...]
I have prepared list of fns, see [1]. I would suggest to rename some
of them. Waiting for you comments.
color_str.c should remain in libgis; it isn't specific to rasters
(e.g. it's also used by display modules).
OK, done in
On Thu, 25 Jun 2009, Markus GRASS wrote:
[...]
very little about in this case. E.g. for completely random access
there might not be a lot of gain.
It is completely random, the next chunk to be read/written can be
anywhere in the file.
[...]
But if there was random access only within a
Paul Kelly wrote:
On Thu, 25 Jun 2009, Markus GRASS wrote:
[...]
very little about in this case. E.g. for completely random access
there might not be a lot of gain.
It is completely random, the next chunk to be read/written can be
anywhere in the file.
[...]
But if there was random
Hi,
2009/6/25 Glynn Clements gl...@gclements.plus.com:
[...]
G_incr_void_ptr() should probably be kept in libgis.
done in r38073.
Martin
--
Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
Hi,
after upgrading OSGeo SVN server to 1.5 I am getting a lot of modified
files when merging changes between branches. E.g.
Property changes on: general/g.mapsets/main.c
___
Deleted: svn:mergeinfo
From [1]
If it finds a path with
See the following announcement. NASA (USA) will release high
resolution DEM's of the globe, produced from the Terra ASTER
satellite, at no charge. You can check out the web announcement at https://lpdaac.usgs.gov/lpdaac/about/news_archive/monday_june_22_20092
. As a Terra ASTER user, I've
11 matches
Mail list logo
