Hi Howard,
Howard Butler wrote:
On Oct 2, 2009, at 2:42 AM, Volker Wichmann wrote:
Hi,
as there's some discussion on "invalid points" on the list at
moment, I like to ask a question about the IsValid check which I
have for some weeks now.
Is this using las2las? You can use the --skip_invalid which despite
its terrible name, means "skip the invalid check" (I think :) )
no, I've stumbled over the problem using the isValid check in my own
code ... while importing MLS data to our software, I realized that some
points above the scanner were obmitted (e.g. bridges above the car on
which the scanner was mounted had dropouts)
IsValid checks (amongst others) the ScanAngleRank to be in the range
-90° to 90°. Our problem is now, that we have LAS files from MLS
(Mobile Laser Scanning) which have scan angle ranks ranging from
-128 to 128. So the check fails with this data.
Does anybody of you know if the ASPRS is discussing this issue for
the next LAS specification and will relax this constraint (-90/90)?
http://lidarnews.com/open-source-software-licensing contains a lot of
my thoughts on this subject, but I'll boil it down to this: The
specification is just a suggestion until there is a reference
implementation. libLAS isn't the reference implementation, and the
ASPRS committee doesn't seem so keen on proclaiming one, so each
vendor can pretty much do what they want and call it a "LAS" file
(and they do, too. Boy do they ever).
yeah, that's true - it seems the LAS format is getting THE format in
which you need to distribute your data (i.e. all customers expect to get
their data in LAS format) irrespective of what information is actually
available or useful. It's a pity - and I would like to see the libLAS
being the reference implementation. Thanks again for all your efforts to
provide such a nice library!
With regards to scan angle, the committee tried to outright through
it out for the 1.3 release before being beat back by complaints.
Evidently it isn't that useful.
ok ... let's see what the future will bring
As far as libLAS is concerned, I was willing to tilt at the windmill
of validation earlier, but without the committee's sanction, it's
just libLAS' word against whomever wrote the file. Being strict
contradicts libLAS' desire to be widely used in the industry,
especially if we can't read everyone's crappy LAS. To that end, I've
taken on maintaining a sample library <http://liblas.org/samples>,
which contains just about every file that a user comes on the list
complaining that libLAS can't read ;) My hope is the number of
permutations of bad files with asymptotically approach zero as time
goes by. Of course, the committee makes geometrically more
possibilities with every ridiculous (thank goodness 1.3 got scaled
back from its original form) specification release :)
Extending liblas to read crappy LAS seems somehow ok to me (how should
we handle these files otherwise?), but I think it is necessary to
establish a standard for LAS that is capable to deal with all sorts of
laserscanning data in a standarized way. I feel this is not possible
with the suggestions made for 1.3. I will take a more detailed look at
your thoughts on the format and will try to talk to some people who may
influence some of the vendors - hope against hope ;-)
Thanks,
Volker
BTW: Thanks for the 1.2.1 maintenance release - this simplyfies a lot
for us! ... and excuse my english, sometimes I'm unable to express my
thoughts corretly :-)
Howard
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
