[Liblas-devel] E57

Ben Discoe bdiscoe at 510systems.com
Sat Mar 5 17:50:08 EST 2011


On Fri, Mar 4, 2011 at 7:57 PM, Howard Butler <hobu.inc at gmail.com> wrote:
> As an aside, I have written up some language for WKT for the next LAS 1.4 specification that I hope is adopted.
>  See http://liblas.org/development/wkt.html for more information, and I'd be interested in any feedback folks might have.

Seems entirely reasonable; Geotiff's CRS stuff is mysterious to me, so
i'd be happy to see LAS move to something that is ... um, well known.

> Another aside is that E57 explicitly supports polar coordinate systems http://libe57.org/
You might look there for options too.

I did check out E57 a while back (the format, and the library).  Here
are my notes from then:

The Good:

1. The low-level format is described fairly well.
2. The basic approach (blobs, with XML text afterwards) is unusual,
but reasonable.
3. Depending on how its used, it could be very storage-efficient.
4. It's very, very flexible.
5. An open-source implementation library is generally a very good thing to have.

Minor issues with the library:

1. No Mac support. #if WIN32 [] #elif defined(LINUX) [] #else #error.
2. More overhead than seems necessary - i.e. the massive Xerces
library, the full set of systems headers on Win32, just to read a point cloud.
3. The E57Simple sample shows some rather strange usage, e.g. point
colors as double *colorRed, double *colorGreen, double *colorBlue.
The example has 22 fields _per point_.  I can only hope that it's
valid to leave the majority NULL.

Issues with the format:

1. Although the low-level format and vector/chunk types are documented
and library-supported, the valid ways in which they are composed in
the file is /not/ public information.  "The standard will be available
for purchase via the ASTM website."  Probably not a big deal for some
companies (which could just join the E57 committee of the ASTM), but still.

2. The format is SO flexible that that there is a large danger to
interoperability.  Like many other historical formats (VRML, GML, IGES
come to mind), it may be easy for a dozen apps/vendors to read/write
"E57", yet be unable to correctly read anyone else's E57 files.

My conclusion on E57: wait and see.  If the high-level format becomes
a bit more open, like with some sample files or actual demo code that
writes a conformant file in a reasonable way, then maybe.  Right now,
LAS is looking more promising.

-Ben


More information about the Liblas-devel mailing list