Hi Will,<br>
<br>
Wow. That was a well thought out email. Your suggested design choices<br>
sound like you have put quite a bit of thought into this.<br>
<br>
Some history: When I wrote the original version las2txt in the<br>
pre-liblas days as part of there was a demand to go from LAS to simple<br>
xyzit (or else) files that could easily be imported into any other gis<br>
tool. So ASCII or TXT was the keyword that people where looking for<br>
when they were "stuck" with a LAS file. To encourage people to use the<br>
much more efficient parse-able LAS directly I wrote easy C/C++<br>
interfaces lasreader.cpp and laswriter.cpp so anyone would easily be<br>
able to write importers and exporters for the GIS package of their<br>
choosing. But in the early days people where quite content with a<br>
simple *.txt file with content like this:<br>
x y z a i<br>
x y z a i<br>
x y z a i<br>
x y z a i<br>
...<br>
...<br>
Not sure these customers would appreciate a mandatory header (as your<br>
LYT files would *have* to include the header ... it would no longer be<br>
optional. That said ... your idea to make it possible to use the<br>
(optional) header should it exists to go back to the original LAS (by<br>
modifying the txt2las.exe program to (optionally) use an existing<br>
header to populate the LAS header.<br><br>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.<br>
<br>
It seems that you have identified a new need: instead of only having<br>
easy to parse xyzai ASCII files without header that are trivially fed<br>
into any other GIS package, you would like the binary LAS format to<br>
have a textual LYT twin that are exactly identical and can be<br>
converted back and forth without any loss ... just like some image and<br>
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?)<br>
<br>
But don't we shoot ourselves into our own foot if we provide this<br>
functionality. After all ... the original reason I created lastools<br>
and the first laslib package was to promote the binary format. I do<br>
not really see a need for a textual version of LAS beyond the sneak<br>
peak and raw text conversion funtionality provided by las2txt ... Howard? Etienne?<br>
<br>
Sure ... A las2kml would be useful. But what primitive should the kml<br>
file contain? Points? My las2dem and las2iso provide lidar derivatives<br>
in KML. Is it useful to have the Lidar points directly in KML? For the<br>
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 ...<br>
<br>
Regards,<br>
<br>
Martin<br>
<br>
PS: your last argument concerning office document formats does not<br>
consider the fact that lidar is often GB of storage. And compressed<br>
text that is GB of storage can be seriously troublesome for some post<br>
processing operations.<br><br>