As the chair of the ASTM E57.04 Data Interoperability subcommittee it is my responsibility to get the word out about the new format and to encourage people to push for its widespread adoption. We expect to have the standard approved this month after 3+ years of work.
To speed the adoption process the subcommittee has also developed reader and writer reference implementations. These are open source and available through our website – www.libe57.org. We are currently in a beta testing phase and welcome your possible interest in this program. Please let me know if you have any questions.
A number of the leading vendors are members of the subcommittee, but we encourage you to participate if you are a vendor, or if you are an end user we ask that you request that your vendor support the data exchange format. This is the solution to the problem of proprietary data formats in the laser scanning industry.
Why ASTMe57 vs LAS?
Also, LAS has a limited number of formats, and they all have a number of required fields that are specialized for aerial data collection (such as scan direction flag, edge of flight line, and scan angle rank). While the E57 format can encode such information, it is not required, so terrestrial laser scanners can use a format that is more appropriate to them.
E57 allows the user to select the format for the data that is most appropriate to them. For example, coordinate values can be stored in floating point values or scaled integers. Coordinates that do not need many bits to store can be stored efficiently, and this is configurable by the person writing the data. Note that this capability does not require creating any extension.
E57 has an essentially unlimited file size and number of records (1.8e19 bytes in length). LAS has limits of 4.2e9 records.
thanks!
you might want to include the first part of your response as well (from the email)??
Here are some of the differences:
1. We support 2D images.
2. We support range images – row and column. Some are calling this raster as opposed to point cloud only.
3. We intend to support compression.
4. We provide a de-centralized user ability to create their own extensions.
5. We do not pre-set the resolution.
6. We will provide approved reference implementations.
7. We will have integrated error detection.
8. We support 3 coordinate systems (Cartesian, spherical, cylindrical).
9. We support arbitrary groupings of points.
How are full waveform data supported in this format?
Full Waveform data is not yet covered by this version of the standard. What exactly do you expect to be standardized when saying “Full Waveform” data?
It would be nice to know who are the subcommittee members. I browsed the ASTM ( http://www.astm.org/COMMIT/COMMITTEE/E57.htm ) site for a list but I was not able to find any name…
BTW I welcome an open standard in this field (particularly if it really become a “STANDARD”) and I want to see if we can add its support to the open source mesh processing and range scanning tool MeshLab .
A few comments/questions:
- why have you used a non standard the license? Adopting one of the standard OSI license (MIT, LGPL ?) would make MUCH clearer how free is the reference implementation.
- a draft of the spec? on the sourceforge site I have found just the api of the library, but no high level info on the format itself (what kind of compression?)
Cheers
Paolo Cignoni
Paolo,
It is not the policy of the ASTM to publish the names, but we have representatives from many of the leading vendors. I believe the license is a standard license. The spec is going to be published by ASTM. You will have to purchase a copy once it is published.
We look forward to your support.
I posted an answer, but was using the wrong button to reply. See below…
If you join the beta test program you will get the spec.
The license used is the same as boost license (OSI approved). We used the same wording, but did not call it boost, since boost is something different.