[OSGeo-Standards] REPORT: my OGC membership slot

[Martin Isenburg]

Hello,

I have used my OGC membership slot to remote-attend the ad-hoc meeting on
Point Clouds at the OGC TC meeting in Boulder and give a presentation on
the 5 steps I consider necessary to avoid the LiDAR point cloud
fragmentation that the OSGeo had warned about in their Open Letter [1].
Because the quality of my Internet connection was so poor I re-recorded a
version of my talk [2] and submitted it as additional content for this
weeks OGC TC meeting in Nottingham where I became a charter member of the
newly formed Point Cloud Domain Working Group [3]. Due to INTERGEO I was
not able to (remote-)attend this in person but I have taken the time to
listen through the entire 2:40 hour long video recording and gave comments
to the presentations that I send to the OGC PC-DWG today. These are
included at the end. I do plan to attend the TC in Sydney in person.

Another curious thing is that I (and the open source license LGPL) was
attacked vehemently in a recent column called "Open Source Mania" by Lewis
Graham that was published in the LiDAR News magazine. Viewer discretion
advised and parental guidance suggested ... you will not like this FUD
attack:

http://www.lidarmag.com/PDF/LiDARNewsMagazine_Graham-OpenSourceMania_Vol5No4.pdf

Regards,

Martin

[1] http://wiki.osgeo.org/wiki/LIDAR_Format_Letter
[2] http://www.youtube.com/watch?v=n52E6OM68UE
[3] http://www.opengeospatial.org/point-cloud-dwg (older version)

-----
to:         pointcloud.DWG at lists.opengeospatial.org
date:     Fri, Sep 18, 2015 at 6:01 PM
subject: comments on Point Cloud DWG meeting at TC in Nottingham

Hello,

Sorry that I was not able to make it. The networks at INTERGEO were
overloaded and the show busy and loud. Remember, the main objective of the
OSGeo is to prevent the "spread" of large quantities of "pseudo open" point
clouds in closed proprietary formats such as RAR, MrSID, or zLAS using the
5 step plan outlined here to prevent format fragmentation by LAZ and zLAS:

http://www.youtube.com/watch?v=n52E6OM68UE

We have already "failed" the government of Slovenia that was either tricked
or misinformed about how to implement "open data" and is currently
distributing their entire national LiDAR data set in a closed point cloud
format.

I have just listened to the 2:40 hour long video of the Point Cloud DWG
meeting from the OGC TC in Nottingham. Than you for providing it. Below my
comments on some presentations.

1) "Serving_LiDAR_thru_existing_OGC_Services", Scott Pakula, Pixia

I agree that there are better ways to serve up LiDAR than ftp links and if
existing OGC protocols can enhance the user exprience that is great. But
too much of this talk seemed to advocate that we *need* a better user
experience and that sounds more like a business opportunity based upon the
distributed point data. I do not require my government to provide me
anything more than a functional area-of-interest query to access my
tax-payer collected point data - even if it as simple as some open layers
shapefiles pointing to a ftp site.
The download capability of the OpenTopography portal alone, for example, is
a great example for a simple, useful, and widely popular LiDAR portal.
Everything beyond that can be done by those that care about providing
better user experiences and those can be great business models. But I do
not see why the OGC needs to have any say in one particular user experience
over another other than advocating all of them to be based on open
standards. Also ... for future slides: It's capitalized LAStools and LASzip
... (-:

2) "The ASTM E57 File Format for 3D Imaging Data Exchange", Gene Roe,
Lidarnews

E57 is a great standard and heavily used in terrestrial LiDAR projects by
many in this industry. Adding compression to E57 is certainly useful. But
there are some inaccurate statements on slide 4. PTS and PTX are ASCII
formats and thus - by definition - *not* proprietary. Better examples would
have been MrSID and zLAS. Here a definition of what a proprietary format is:
http://en.wikipedia.org/wiki/Proprietary_format
That LAZ is not listed on the "How Do People Store 3D Data Today?" slide
despite the fact that pretty much all large LAS collection being hosted as
LAZ will not surprise anyone who followed the "LAZ clone" controversy. Over
the past two years I have regularly lamented that part of why ESRI seemed
to get away with forcing yet another proprietary format upon us was the
bias in the reporting of (sponsor-financed) geospatial media outlets that
was improperly informing their readership. Gene had the most notorius
record of all in reporting every incremental advance of the "LAZ clone" on
Lidarnews while ignoring the screaming controversy. The inaccuracies on
slide 4 suggest that this bias continues, so I have little choice but to
advise taking his statements on other formats with a grain of salt.
Another inaccuracy is the claim that LAS does not allow extensions. I have
been part of the process of adding the "extra bytes" concept into the LAS
1.4 specification that allows a user-defined and documented addition of new
per-point attributes.

That said, I really must complement Gene and his colleagues on their
amazing achievement with E57. It is of great use to the industry as I have
just witnessed first hand at INTERGEO. But I wish Gene could see the E57
format as a complement (not a competition) to the LAS/LAZ format for the
(many) situations where the much simpler LAS format is not sufficient -
such as storing multiple scans positions in a terrestrial project or
co-registered imagery.

3) "OGC WCS: Format-independent Point Cloud Services", Peter Baumann,
Jacobs University

Great presentation. Not much to add. Except that the coordinate resolution
in the GML encoding on slide 4 makes me really worry. Given their values
those seem to be projected xyz coordinates and writing them down with 15
digits after the decimal points (=> that is the unit of femtometers [fm], a
typical length-scale of nuclear physics as the radius of the gold nucleus
is approximately 8.45 fm) reminds me of this story:

http://rapidlasso.com/2015/09/02/england-releases-national-lidar-dem-with-insane-vertical-resolution/

4) IQumulus, Jan Boehm, UCL

Great presentation. Only comment. LASzip will also compress any additional
per-point attributes stored to a LAS file. How well depends on the
resolution and how coherent the attribute is stored. But compression will
not suffer as much as suggested.

5) "Point Cloud Photogrammetry", Jean-Baptiste Henry, Thales Group

Two small comments: (1) We can add "confidence values" to ech point to
LAS/LAZ via the "Extra Bytes" functionality. (2) Do not overestimate the
"suitfulness" of the ASPRS LAS Working Group (LWG) as a standardization
body to co-operate with. The current LWG is a notoriously untransparent
groups with an unratified working protocol written overnight that has no
established procedures such as record keeping / votings process  / regular
meetings / or anything else that are core to a normal standardization body.

6) "Management and direct use of massive point clouds". Edward Verbree, TU
Delft

I agree that we need a point cloud *Web service* that could potentially
offer multi-resolution access. This is a completely orthogonal to the OSGeo
request for distributing point clouds only in *open* formats. Such a
service could either operate from a data base but also a folder of point
clouds stored in either LAS / LAZ / E57 /PTS / XYZ files (optionally at
multiple resolutions) or some other open point cloud format current or
future.

There was a *wrong* statement at 2:20:25, some mumbling about a"full
commercial package"? That was quite missleading. LASzip is 100% and open
source but TU Delft has in addition decided to license rapidlasso's
LAStools software academically for some of the more complex operations but
the LAZ format has absolutely no dependence on that.

Regards,

Martin (to the best of my knowledge and on behalf of OSGeo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20150918/b225ddf5/attachment.html>