Fwd: [Liblas-devel] txt2las - psid only 1 byte?

Volker Wichmann wichmann at laserdata.at
Mon Jun 8 03:56:43 EDT 2009


Hi,

I just did a fresh svn checkout (trunk, rev. 1294) and get an error from 
configure:

checking for debug enabled... no
checking for GDAL... no
checking for libgeotiff... no
checking for spatialindex RTree.h... no
checking for libspatialindex... no
./configure: line 21461: syntax error near unexpected token 
`$ORACLE_OCI_REQ_VERSION'
./configure: line 21461: `AX_LIB_ORACLE_OCI($ORACLE_OCI_REQ_VERSION)'

Any help appreciated,
Volker


Volker Wichmann wrote:
> Howard,
>
> thanks for taking a look and applying a fix. I will report back next 
> week as soon as I have build a version from trunk.
>
> Volker
>
>
> Howard Butler wrote:
>
>> oops, forgot to CC the list.
>>
>> Begin forwarded message:
>>
>>> From: Howard Butler <hobu.inc at gmail.com>
>>> Date: June 5, 2009 10:27:20 AM CDT
>>> To: Volker Wichmann <wichmann at laserdata.at>
>>> Subject: Re: [Liblas-devel] txt2las - psid only 1 byte?
>>>
>>>
>>> On Jun 5, 2009, at 4:48 AM, Volker Wichmann wrote:
>>>
>>>> Hi,
>>>>
>>>> I have troubles converting an ASCII file with point source ids >  
>>>> 254 to LAS 1.1 using the txt2las tool (version 1.2.0b3). It seems  
>>>> to me, that the point source id is not written as unsigned short 
>>>> (2  bytes) but as unsigned char (1 byte) resulting psid=0. Is 
>>>> anybody  experiencing the same problem?
>>>>
>>>
>>> I have filed a ticket on this item.  Please continue to track its  
>>> development and improvement there (register for the site if you  
>>> haven't already).  I have applied what I think is the fix to trunk  
>>> if you have opportunity to build that.
>>>
>>> http://liblas.org/ticket/139
>>>
>>>
>>>> PS: I obtain correct results using the old lastools txt2las from  
>>>> Martin Isenburg
>>>
>>>
>>> I so very wish I could make a convincing case to Martin to have him  
>>> base his LAStools on libLAS.  I have tried very, very hard to do 
>>> so,  but I can't seem to make a compelling case.  It is unfortunate 
>>> that  we maintain essentially a fork of his utilities that have 
>>> different  capabilities than his.
>>>
>>>
>>
>> _______________________________________________
>> Liblas-devel mailing list
>> Liblas-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/liblas-devel
>
>
> _______________________________________________
> Liblas-devel mailing list
> Liblas-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/liblas-devel



More information about the Liblas-devel mailing list