<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jan 29, 2025 at 2:02 PM Norman Barker via pdal <<a href="mailto:pdal@lists.osgeo.org">pdal@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Howard,<div><br></div><div>I have been looking into this further and I would like to better understand how you envision using FileSpec and VSI to move over from Arbiter.</div><div><br></div><div>Taking the LasReader for example and in particular this line - <a href="https://github.com/PDAL/PDAL/blob/master/io/LasReader.cpp#L257" target="_blank">https://github.com/PDAL/PDAL/blob/master/io/LasReader.cpp#L257</a> where arbiter copies the LAS file locally, a direct replacement with VSI will also download the whole file. </div></div></div></blockquote><div><br></div><div>FileSpec doesn't really have anything to do with fetching remote files. It just provides a uniform way to communicate options that may be related to remote access or perhaps some other file operations.</div><div><br></div><div>I don't know that we really need/want a virtual file system in PDAL. This could end up being a hugely complicated thing that takes over. But it is useful to fetch blocks of data from remote storage. Right now we do this with a little helper class and Arbiter. This makes sense if you don't know the order in which you're going to fetch data or if you're going to need the entire file.<br><br>In most cases we do read all the data when dealing with a file, but it's not always sequential. LAS places metadata at the beginning and end of the file. You have to read those first before processing the actual data. But after that you (mostly) read the data sequentially. So in a perfect world you would pre-fetch data as you go. But this gets complex and the access pattern isn't absolutely sequential -- the code is threaded in order to have plenty of CPUs doing decompression, which is typically the gating factor.  Certainly you could request blocks of data as necessary, but then you're waiting on a round-trip to the server. To some extent this issue could be alleviated with more threads or async I/O, but it's all complicated. COPC does random access on remote data, so pre-fetching probably doesn't make sense for it. EPT is another thing altogether in that you read entire files as you need them. I haven't done a survey of other readers.<br><br>Writing to temporary disk isn't necessarily a big deal.  Data may never actually go to disk if you have sufficient memory to store the pages. The obvious disadvantage of the fetch-then-process model is that you need to wait until all the network traffic is done before you can start real processing. The advantage is simplicity.<br><br>Anyway, I don't think doing this transparently in the code is going to yield the best outcome. Perhaps a VFS-thing would make sense, but I don't think it's an obvious win. I know that GDAL's VSI has various limitations. Probably all do. I think we have a certain strength in the simplicity of what's there now. I'd like to see some experimentation before we commit to anything.<br><br>Note that this issue is a different one than providing more information to use when accessing remote sources (credentials, regions, chunk size, etc.)<br></div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div></div>