[GRASS-dev] r.in.lidar not running in Mac binaries for 7.1

[Michael Barton]

So far I'm stuck on compiling liblas with new gdal and no one has had any advice for a way forward. If that can happen, I can recompile with new liblas. That is why I was hoping for laslib. It may be that I just did not link it correctly. I'm open to advice.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Sep 15, 2015, at 6:02 PM, Vaclav Petras <wenzeslaus at gmail.com<mailto:wenzeslaus at gmail.com>> wrote:

[Was: Re: [GRASS-dev] New Mac binaries uploaded]

Hi Michael,

On Mon, Aug 24, 2015 at 11:45 PM, Michael Barton <Michael.Barton at asu.edu<mailto:Michael.Barton at asu.edu>> wrote:
That would be wonderful. I sort of got that impression too. But will the GRASS lidar tools be able to use LASlib instead of Liblas?

the binary in Dropbox has lasinfo et al. from LAStools. However, r.in.lidar doesn't work (2 different computers). Does it work for you? Running r.in.lidar or v.in.lidar --help and says

dyld: Library not loaded: /usr/local/lib/liblas.2.2.0.dylib

As I said earlier, GRASS is made to dynamically link with libLAS. In case the API of LAStools library is the same, there might be a way to change the GRASS configuration and makefiles or the ones for LAStools, so that GRASS can compile with LAStools statically but I don't know the way.

Currently with LAStools compiled with GRASS on Mac, you can use the tools in command line but it's useless for GRASS modules, namely r|v.in.lidar.

Thanks,
Vaclav

PS: Although I'm working on migration to PDAL [1], it will take some time before it gets even to 7.1 (trunk), not mentioning 7.0. So, the libLAS library is still needed.

[1] https://trac.osgeo.org/grass/ticket/2732


> On Aug 24, 2015, at 8:40 PM, William Kyngesburye <woklist at kyngchaos.com<mailto:woklist at kyngchaos.com>> wrote:
>
> I looked at LAS this spring.  From what I found, libLAS is superceded by LASlib, found in LAStools.  laslib and some of the tools are still opensource, but other tools are not.
>
> Laslib does not have a configure, it's a simple makefile that needs a little tweaking for OS X.  And there appears to be no dependence on BOOST or Geotiff, or anything else.
>
> For laslib, all I needed to do was edit laslib/src/makefile and change these lines:
>
> COPTS     = -Os -Wall -Wno-deprecated -DNDEBUG -DUNORDERED -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.7.sdk
> COMPILER  = clang++
>
> And in the liblas.a target, add a line after the cp line (tha's a tab at the start):
>
>       ranlib ../lib/$@
>
> Also delete the precompiled Windows lib in laslib/lib.
>
> You should be able to use the library right from the source, it's static so it will be built into GRASS without needing a copy of the laslib.  For GRASS configuration, the library will be in that lib folder and includes in the laslib/inc folder.
>
> On Aug 24, 2015, at 3:47 PM, Michael Barton <michael.barton at asu.edu<mailto:michael.barton at asu.edu>> wrote:
>
>> For LASlib compliing, I managed to get past the GEOTIFF problem with the following:
>>
>> cmake -G "Unix Makefiles" -D CMAKE_OSX_ARCHITECTURES="i386;x86_64” \
>> -D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.7.sdk” \
>> -D GDAL_CONFIG=/Library/Frameworks/GDAL.framework/Programs/gdal-config \
>> -D GEOTIFF_INCLUDE_DIR=/Library/Frameworks/UnixImageIO.framework/unix/include \
>> -D GEOTIFF_LIBRARY=/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib \
>> ../
>>
>> But now cmake is complaining about the CMAKE_OSX_ARCHITECTURES flag. I don’t know if this harkens back to the similar problem with boost or if this is new. I’ve tried both i386 and x86_64 individually and it still won’t compile.
>>
>> Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150916/d6523cd1/attachment-0001.html>