Sorry I missed the earlier discussion of the -i flag [for ignoring
malformed lines in the data stream]; I had been out of town.
In general my plan for r.in.xyz was to keep the interface (and code) as
simple as possible. The idea is to keep the methodology clean + light, and
so the code bug free + fast.
The code for the -i flag won't slow down the module any (vs prior) and
doesn't really add program complexity, so I don't have a technical problem
with it. Still, for reducing methodology mistakes & encouraging a hands-
on approach to data management, I consider it preferable that the user
should be forced to do something to fix their broken input files rather
than hack their way around them without careful study of what the problem
really is. If there are many files to process they could filter the stream
through any number of UNIX tools like sed or awk and then pipe the result
to r.in.xyz's stdin in some automated way.
--
A zscale= option seems like a reasonable request. Is the purpose that the
elevation data comes in feet and you want it in meters?
I will review the patch, run some speed tests, and take care of committing
as soon as time allows.
I would appreciate if you don't revert the -i flag. It's a major PITA to
manually fix files as in the indicated case (with Lidar, you often have
hundreds of tiles to process).
The purpose that the elevation data comes in feet and you want it in
meters or you want centimeters or whatever. Data often come in a different
way than desired.
Don't worry, I don't mean to revert the -i flag, but I did want to make
clear my design philosophy. If the input file is that badly broken then a
million WARNINGs should be disincentive enough to discourage lazy abuse of
the flag.
FWIW, to chop off the last row of a file, use head with a negative index:
head -n -1 filename.txt | r.in.xyz in=- out=foo ...