Etienne,
I am in the process of rewriting las2txt to use the C++ API (so we get the
new-style filters, etc).
Great !
I have everything done except for the header writing portion. After looking at
it a bit, I'm wondering if it is that useful in its current form. Do you
expect that las2txt output of a header should be easily parseable, or you
expect it to act much like a comment block at the front of a source code?
I'd say it should be easily readable with other tools like a csv
reader/editor. That's the reason I personnaly use the las2txt (or
recommend it to others). For instance load points in PostGIS, or even
load points in a GIS (when the las2shp is unreadable -e.g. in ArcGIS).
As it is right now, las2txt's header output does neither very well. It would
be quite simple to have las2txt output libLAS' xml-ification of the header if
the user specified a --header argument in the invocation. Would this be useful?
In my case, I'd say no. It is not usefull because the people that need
txt file are not going to use an xml parser. I'd say the the design
should be targetting something simple at least by default. Output one
file, maybe that option could be useful, for other purposes, but I find
it quite complex for the name of the tool or the use cases I have in mind.
Or is the intention that the header in the front of a .txt xyz LAS file is must
cursory information that can't actually be used to get back to the original LAS
file?
I'm not sure I understand well your question, but I think I see the
las2txt as an end. I use it because I need a file I can read with a text
reader. If I want to manipulate the file to create a new las file, I
should do it using with appropriate tools like python for instance.
Hope it helps you.
Cheers for the rewriting,
Etienne
Howard
On Oct 28, 2010, at 3:44 PM, Etienne Bellemare wrote:
Good point, I'd like to suggest also the ability to specify the header
separated the same way the fields are going to be. It will create a much more
consistent file. e.g. for the moment you can't use tab to seperate header even
if your fields are. Having the ability to set a name for the header could be a
nice feature too.
Thanks again,
Etienne
On Thu, Oct 28, 2010 at 4:22 PM, Howard Butler<[email protected]> wrote:
On Oct 28, 2010, at 3:16 PM, Randy Bucciarelli wrote:
Hi Howard,
Is there a way to format resulting precision of values from the output of
las2txt?
Or does 'las2txt' simply output the precision of the values how there were
initially stored when creating LAS files?
There isn't, but I agree there should be an option to set/override the
precision of x/y/z values (independently) I have rewritten lasinfo and las2las
using the new C++ API, and I think las2txt should also be rewritten as well.
In summary output and other venues in those rewritten utilities, I have tried
to respect the specified scale/precision of the dimension if it was set in the
header.
Rewriting las2txt similarly to lasinfo and las2las is in my queue, but I
probably won't get to it for a bit.
Howard
PS, this question should be asked on the list, and I have forwarded it
there._______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
