[Liblas-devel] Header::SetDataFormatId, and supported schemas

[Michael P. Gerlek]

I'm not keen on more file formats in the world, but one thing I've on my
wish list is a sort of "binary" version of the ascii format to use for
interchange -- that is, a text header file which lists the columns and data
types for a point (e.g. as a C-style struct), and a binary file which just
stores the binary points, e.g. as an array of structs.  Trivial to read and
write, arbitrarily flexible, and smaller than ascii.  And, perhaps,
compressible with laszip technology.

-mpg


> -----Original Message-----
> From: liblas-devel-bounces at lists.osgeo.org [mailto:liblas-devel-
> bounces at lists.osgeo.org] On Behalf Of Martin Isenburg
> Sent: Sunday, March 06, 2011 6:53 AM
> To: Ben Discoe
> Cc: liblas-devel
> Subject: Re: [Liblas-devel] Header::SetDataFormatId, and supported
> schemas
> 
> hi ben.
> 
> > ePointFormat0: has dimensions "X, Y, Z, Intensity, Return Number,
> > Number of Returns, Scan Direction, Flightline Edge, Classification,
> > Scan Angle Rank, User Data, Point Source ID".
> >
> > ePointFormat1: all of those, plus it adds "Time".
> >
> > ePointFormat2: adds Color ("Red", "Green", "Blue")
> >
> > ePointFormat3: adds "Time" and Color.
> >
> > ePointFormat4: adds "Time" (and WavePacket?)
> >
> > ePointFormat5: adds ???
> 
> ePointFormat5: adds "Time" and Color and WavePacket
> 
> > Besides clarifying those options a bit more for the documentation,
> > could someone tell if this means we cannot define our own schema?
> 
> We cannot. LAS has those 6 point types. If you only use XYZ and RGB then
> you should use point type 2. If you are worried about space (e.g.
> storing too many unused fields) you can consider leaving all those fields
at
> zero and storing your data LASzip compressed ... they will be pretty much
> "compressed away" completely.
> 
> Martin
> _______________________________________________
> Liblas-devel mailing list
> Liblas-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/liblas-devel