[Liblas-devel] Design/architecture questions

[Michael Gerlek]

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