lastools - return codes on exit.

[Michael Perdue]

Hello All,

One of our guys recent ran a batch file on the server and tripped over a landmine in the process. The batch file had two commands; laszip -i *.las followed by DEL *.las. It turns out that laszip wasn't on the search path for that computer so laszip failed to run, but DEL ran like a champ and did a great job! Fortunately the data was saved in the server snapshot so it wasn't a big problem. When I found about it I discouraged the team from putting the DEL command in batch files, especially when using wildcard expansion. However, I also suggested that the only way I could recommend using laszip and DEL together in a bat file was to use a conditional && operator as below.

FOR %%i IN (*.las) DO laszip.exe -i %%i && DEL %%i

 

Because the DEL command requires an exit code of 0 from the preceding command, I can't think of any potential landmines to running the command in this way. But the down side is you can't parallelize the process by using multiple cores and it delves into realms of DOS that most people become seriously uncomfortable with. However there are other ways that the conditional && operator could be used and I ended up discouraging it because I don't know enough about how lastools collects and reports errors to the shell on exit. So, my question is;

How does Lastools handle error reporting to the shell. Is is a return code of 0 from main () provided if the last iteration/child process completes successfully or does lastools collect errors from previous iterations/children and return an exit code with intelligent design to signify special meaning to the user? For instance;

laszip -i *.las && DEL *.las

or

laszip –cores 8 –i *.las && DEL *.las

If there were 1000 tiles in the directory and the first 999 fail for unknown reasons but the last file zip's successfully, what exit code does laszip (or other tool) return. If the program returns 0, all the las files would be deleted upon exit (maybe bad). A value of 1 would prevent DEL from being executed, but it's conceivable that additional codes could be returned to indicate the nature and quantity of errors encountered (best, but may be of limited practical use).

Cheers,

Mike

[Martin Isenburg]

Hello Michael,

it would see to me that - rather than you experimenting with DEL in the batch script you could just as well use the (currently non-existing) '-delete_after_processing' option that would only perform the delete operation if the file was successfully processed. I would probably - just to be safe that this is really wanted - require the user to also add the '-really' option into the command line. (-:

Alternatively I could see adding this - as a slightly safer option - into a seperate tool, most likely lasdiff, that will delete either the compressed or the uncompressed file once it was determined that they are - in fact - identical (in a second pass). Would this be sufficient / better than your current approach?

Martin

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[Evon Silvia]

I concur with the idea of a -delete_after_processing -really (haha) option for laszip, with the caveat that it'd be better to have it run the success check and delete each individual LAS file, rather than a binary question for the entire dataset. That would make it much easier to isolate the individual LAS files that failed, since they'd be the only surviving ones.

Evon

[Michael Perdue]

Hi Martin,

If you are willing to add a new switch, then I would be all over that. As Evon mentioned, it would make it much easier to isolate and investigate the LAS files that failed.

I think that the '-delete_after_processing -really' is probably the best option. It would be safer in lasdiff, but I fear that the extra time and step would prevent it from being used.

Cheers,

Mike

[Jorg M Hacker]

Hello Martin,

In this same context - is there any option to return a DOS exitcode when a lastools utility completes execution? That could then be intercepted by a batching routine (like my own one which I use to batch sequential lastools utilities) and prevent the batch process to continue.

Cheers,

Jorg.