Mateusz: > Yes, it confirms what I've read in GRASS docs and Wiki pages, > that there is no direct support to ASPRS LAS format. ... > I'm willing to contribute a module for LAS read/write. However, I'm not > an experienced GRASS user nor developer, so I'll likely need to prepare > myself a little (read docs and code) before I can start. Means, I'm not > sure I can provide you with ready solution very soon. ... > The libLAS building follows well-known *nix patterns and there is > autotools-based builder. Optionally, users are provided with cmake > configuration as well as project files for Visual C++ 2005. > The library itself has no external dependencies.
Hi, I don't claim to know anything about what libLAS does, so sorry if this doesn't make sense. But if it is purely vector format I/O would it be better to write it as a new format for GDAL's OGR and have grass access it with v.in.ogr? Then other FOSS softwares could easily gain advantage of it too. http://liblas.org/wiki/LASElements Or is the dataset size/model such that it is better to directly import/process it in GRASS using fast C modules as a front end to the lib? or simply DAS export to a text file: DAS -> x|y|z|extra1|extra2|extra3|... + header metadata | r.in.xyz ? Helena: > > But this will raise a question for GRASS dev whether we want to add > > another dependency to GRASS in addition to GDAL and PROJ and a number > > of optional ones? I see no problem adding new optional depenencies, if they are useful, added into the build system properly, switched off by default, and license compatible. Hamish ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
