Dear liblas-dev: I've got some questions... I've already got some partial answers from Hobu off-list, but he suggested I reflect this back to the list for wider discussion.
1. I need some info on the policies for memory management of Headers (and possibly Points). It looks like the Header data is kept in a reference counted object (HeaderPtr), and I think the intent is that the Header data kept live with the Points returned, so they can be interpreted later. Is that right? 2. Auto_ptr is used for ReaderImpl and some others. What is the intent here? 3. The hierarchy of Reader, ReaderImpl, ReaderI, CachedReader, etc, is a bit confusing, so a couple words of explanation would be helpful. I am creating a new reader type for laszip files: I *think* I want my "LazReader" to be a ReaderI passed into the libas::Reader object, and Howard agreed. He also said > ReaderI -- interface > Reader -- original implementation <-- Implements ReaderI > ReaderImpl -- concrete implementation that Reader uses to do its work and > implement ReaderI > CachedReader(Impl) -- a point caching implementation (with a bad name) So at some level, I should think of Reader and ReaderImpl as really being LasReader and LasReaderImpl? Is ReaderI intended to be the basis for all future extensions? One could imagine (and Howard suggested) a factory which spits out ReaderI's based on given inputs (based on file extensions or magic numbers or whathaveyou, see next question). 4. How to determine if a file is regular LAS or LASzip? I'm not sure what the canonical extension is (.laz?), but Howard suggests we should actually be cracking open the header and looking at it. He said: > A. The point data format id is 8 bits long. For a compressed data indicator, > we will set the highest bit to zero (in addition to setting the lower bits as > before based on the point type) for a compressed data point format id set of > 128, 129, 130, 131, 132, ... > (1 << 7) + 1 # <-- point format 1 > (1 << 7) + 2 # <-- point format 2, etc. > The rationale for this approach is another software could potentially read > the header but not recognize the point format. > > B. The point record length will be set to 0. This should halt a software > that ignores the point format from reading any (mangled) data from the rest > of the file/stream/db entry. > > C. VLR records (possibly) exist that inform the compression. We will have at > least one or two different VLR types to hint the compression. One for a > chunk size, and maybe another for the compression type. This logic likely belongs in a Factory, then? -mpg _______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
