[GRASS-user] v.in.ascii : ERROR: write sidx

Le Jeune Yann lj.yann at gmail.com
Fri Sep 27 00:20:26 PDT 2013


> Ok, 88 million points and running 64bit Linux. Since 3D points
> and no additional data columns columns I think it will default
> to not creating a database, so you don't have to worry about the
> -t flag or the memory needed for that, just the finite amount of
> RAM per point for topology. Maybe 64GB RAM will be enough for 88M,
> perhaps more, but it will need a lot to build topology for all those
> points.
>

Ok


>
> May I ask what process you'd like to do with the data?


I am processing point clouds from photogrammetry (here an engraved
megalith, 6.5 m²) and LIDAR data in forested areas (archaeology at another
scale).
For this i am working on a script that perform all classical processes (for
achaeologist, including qualimetry, animations, PDF maps etc.) for all
*.csv file in a given directory. It's a work in progress, shellscript, but
i hope to do this in C and/ or in a contribution to grass if it worth it.


> Perhaps
> r.in.xyz + r.to.vect helps reduce the number of points to something
> more manageable.


I will try this.


> The v.in.ascii '-r' flag can be helpful for importing
> only those points within the current computational region of interest,
> and if importing without building topology (the '-b' flag you tried
> before) many of the LiDAR modules and v.surf.rst have been modified
> to work without needing it.
>

ok, i will looke at that too.


> If it is some other vector module maybe we can modify it to load data
> without topology too.
>

i use also v.neighbors


> Is it sparse x,y data or gridded?
>

It's sparse data.

Thanks à lot !!!

yann
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130927/e711be41/attachment-0001.html>


More information about the grass-user mailing list