[pdal] readers.slpk: Failed to fetch info

[David Lewis]

James -
I'm currently running python-pdal version 2.1.8    and    pdal version
1.8.0. Not sure if those are mismatched or where I would check that. Conda
doesn't seem to report any issues.

Andrew -
I get the following traceback which is what I attempted to use to
understand the file structure on the Github. However, it doesn't seem very
verbose.

[image: image.png]

David

On Mon, Apr 1, 2019 at 9:21 AM James Klassen <klassen.js at gmail.com> wrote:

> Just thinking about possible errors on Linux that can seem
> random/impossible: Could there be a mismatch between the installed
> python-pdal version and the pdal library versions? Could there be a
> AppArmor/SELinux/etc. restriction that would depend on what program is
> running?
>
> On Mon, Apr 1, 2019 at 8:01 AM Andrew Bell <andrew.bell.ia at gmail.com>
> wrote:
>
>> I find this confusing.  Perhaps you can strace the python invocation and
>> determine the syscall that's failing?  I can't help thinking this is still
>> a filename or path issue, because things work fine through pdal info and
>> the stage is invoked and run through the python interface but the file
>> itself seems not to be loaded.  I'll do something to improve the error
>> message, but I don't know when the change would make it into a conda build.
>>
>> On Fri, Mar 29, 2019 at 4:32 PM David Lewis <dlewi146 at gmail.com> wrote:
>>
>>> I installed PDAL through conda. I used the command "conda install
>>> python-pdal -c conda-forge" .
>>>
>>> On Fri, Mar 29, 2019 at 2:52 PM Andrew Bell <andrew.bell.ia at gmail.com>
>>> wrote:
>>>
>>>> It would be nice to know what's wrong.  What is the source of your PDAL
>>>> installation?
>>>>
>>>> On Fri, Mar 29, 2019 at 2:25 PM David Lewis <dlewi146 at gmail.com> wrote:
>>>>
>>>>> The script still returns the same error when run with either an
>>>>> absolute or relative path.
>>>>>
>>>>> Interestingly enough, running `pdal info filename` from the command
>>>>> line seems to work fine. I can likely modify my top level program to call
>>>>> it from the command line from now on.
>>>>>
>>>>> Should I just attempt to transition to using the command line from now
>>>>> on or is this an error we should continue to pursue?
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 29, 2019 at 10:24 AM Andrew Bell <andrew.bell.ia at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Mar 28, 2019 at 6:26 PM David Lewis <dlewi146 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I've modified my code to use "filters.info" like yours and it still
>>>>>>> is giving me that error.
>>>>>>>
>>>>>>
>>>>>> I wouldn't have expected that to make any difference.  It just
>>>>>> provided some feedback that the data was actually loaded.
>>>>>>
>>>>>>
>>>>>>> I have also verified that the directory I am extracting the file
>>>>>>> into has sufficient space and write permissions. Are you using the same
>>>>>>> file that I sent in the .zip file or is that a different SLPK file?
>>>>>>>
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> I don't know what the problem might be.  I suppose you have run `pdal
>>>>>> info  SMALL_AUTZEN_LAS_All.slpk` with the same result?
>>>>>>
>>>>>> Have you tried providing an absolute path when loading
>>>>>> SMALL_AUTZEN_LAS_ALL.slpk?
>>>>>>
>>>>>> --
>>>>>> Andrew Bell
>>>>>> andrew.bell.ia at gmail.com
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Andrew Bell
>>>> andrew.bell.ia at gmail.com
>>>>
>>>
>>
>> --
>> Andrew Bell
>> andrew.bell.ia at gmail.com
>> _______________________________________________
>> pdal mailing list
>> pdal at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/pdal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20190402/28962d86/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 24588 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20190402/28962d86/attachment-0001.png>