[Liblas-devel] Re: las2txt question

[Martin Isenburg]

Hi Will,

Wow. That was a well thought out email. Your suggested design choices
sound like you have put quite a bit of thought into this.

Some history: When I wrote the original version las2txt in the
pre-liblas days as part of there was a demand to go from LAS to simple
xyzit (or else) files that could easily be imported into any other gis
tool. So ASCII or TXT was the keyword that people where looking for
when they were "stuck" with a LAS file. To encourage people to use the
much more efficient parse-able LAS directly I wrote easy C/C++
interfaces lasreader.cpp and laswriter.cpp so anyone would easily be
able to write importers and exporters for the GIS package of their
choosing. But in the early days people where quite content with a
simple *.txt file with content like this:
x y z a i
x y z a i
x y z a i
x y z a i
...
...
Not sure these customers would appreciate a mandatory header (as your
LYT files would *have* to include the header ... it would no longer be
optional. That said ... your idea to make it possible to use the
(optional) header should it exists to go back to the original LAS (by
modifying the txt2las.exe program to (optionally) use an existing
header to populate the LAS header.

However ... with Howard's liblas we have a software engineering project that
goes far beyond my little C/C++ library form the early days. Maybe we should
extend the functionality beyond the needs I mentioned above.

It seems that you have identified a new need: instead of only having
easy to parse xyzai ASCII files without header that are trivially fed
into any other GIS package, you would like the binary LAS format to
have a textual LYT twin that are exactly identical and can be
converted back and forth without any loss ... just like some image and
polygon mesh formats have both a textual and a binary version. What do
others think? Would an ASCII-LAS be worthwhile as a format? Should it
contain xyz in their integer representation (i.e.. unscaled & unoffset?)

But don't we shoot ourselves into our own foot if we provide this
functionality. After all ... the original reason I created lastools
and the first laslib package was to promote the binary format. I do
not really see a need for a textual version of LAS beyond the sneak
peak and raw text conversion funtionality provided by las2txt ... Howard?
Etienne?

Sure ... A las2kml would be useful. But what primitive should the kml
file contain? Points? My las2dem and las2iso provide lidar derivatives
in KML. Is it useful to have the Lidar points directly in KML? For the
time being GE does not handle large number primitive but knowing google that
may just be a matter of time. Does anyone know if GE is planning to support
binary geometry formats? KML & DEA are limited when it comes to detailed
geometries ...

Regards,

Martin

PS: your last argument concerning office document formats does not
consider the fact that lidar is often GB of storage. And compressed
text that is GB of storage can be seriously troublesome for some post
processing operations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/liblas-devel/attachments/20101125/1d7c3896/attachment-0001.html