OGC Testbed-14: Point Cloud Data Handling Engineering Report

By providing a workable set of point cloud web service requirements, this report gives follow-on efforts direction in regard to the challenges that future standardization efforts must tackle. The report also links together a survey snapshot of the current industry software situation in regard to both prevalent formats and web services.

Before standardization of any web services approaches can be undertaken, exploration of the software requirements that such a service must meet would provide helpful background to achieve the task for the widest implementation audience possible. This report seeks to accomplish this task in five ways. First, a description of point cloud web service requirements is presented in Chapter 6 along with how they relate to current industry software usage. Second, existing point cloud web service approaches are contrasted in Chapter 7 to the requirements list and discussion about their consequences is provided. Third, discussion about the approaches, the consequences of some of their design choices, and their relationship to the requirements presented in Chapter 6 is provided in Chapter 8. Lastly, the results of a short industry survey in Industry Survey provide background on the niche for point cloud web services, point cloud formats, and the desire for compression on both topics.

Point cloud data management techniques could greatly benefit from a web services approach, due to their imposing bulk and fundamental difference versus typical raster and vector geospatial data. A point cloud web service provides an opportunity for application developers to offload the challenges associated with data compression, partitioning, and information extraction. A web service approach also provides opportunity for applications to leverage the same data access and organization approach, which allows applications to focus on providing upstream value such as feature extraction, data fusion, and monitoring.

Questions that were addressed by research efforts into point cloud web services include the following:

A service-based approach to point cloud data access and dissemination is a missing capability required for interoperability within the point cloud data industry. A service-based approach has the potential to allow for separation of concerns, by especially making distinct the problem of point cloud data organization from access challenges.

This report describes and discusses requirements for point cloud web services, it contrasts them in relation to five point cloud web service implementations, it highlights the technical details of an example specification, and it provides the results of an industry survey on the topic of point cloud web services and formats.

Specific recommendations that could follow the information provided in this report include:

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The primary challenge of point cloud data is simply their storage volume. Capture rates for geospatial point cloud data, in the form of actively-captured LiDAR or passively-captured coincidence-matched imagery are still accelerating in 2018 as sensors, storage, and processors continue their rapid increase in capability and decrease in cost.

The data type does not lend itself to convenient compression, storage arrangement, or access mechanisms – especially in relation to other typical geospatial data types. The data behave as not quite vector and not quite imagery, and point cloud data need to employ data management techniques that address the unique challenges they present – specifically the requirement of per-point storage of coordinates and attributes.

Point cloud data are often treated as raw measurements in support of upstream data extraction and production scenarios. These subsequent usages include other domains such as:

In nearly all scenarios, point cloud data are processed into a derived product for exploitation or information extraction. For example, it is common to rasterize point cloud data to a two-and-half-dimensional (2.5D) surface model to allow the data to be exploited by typical landscape morphology operations. Alternatively, feature extraction algorithms might segment and construct solid surfaces by connecting points together. In the first scenario, simple range query support is sufficient to allow an application to quickly produce the derived output. In the second, hierarchical spatial indexing with accelerated per-point access is needed to support the neighborhood searching required for the segmentation and classification process.

A typical scenario for data processing is to take a full density subset of a larger point cloud collection, process or extract information from it, and continue to the next processing step. Because the data are typically so large, transmission of subsets over networks is a critical requirement that most applications require – even in cloud computing scenarios. Data organization properties that can improve transmission of point cloud data include efficient compression, idempotent responses that allow repeated requests to return the same data, and service architectures that do not require significant computing to respond to each request.

Network protocols for point data transmission must account for hierarchical data access with a query pattern that supports requesting level-of-detail subsets of data. Without this ability, full-density computation operations have a tendency to consume extra computation due to the fact that individual points in a larger point cloud do not contribute significant informational weight. By selecting for data at specific resolutions, applications can balance their need for precision with network and processing performance.

While many organizational approaches are possible, two indexing patterns are prevalent in point cloud data operations – a k-style index, which supports rapid access neighborhood lookups and quadtree or octree indexes, which support range queries by depth. While each have their use, octree indexing patterns provide the widest applicability and utility for services that seek to do partial extraction of spatial windows of data. Query patterns that require neighborhood searches can be achieved by a multi-pass or sub-window secondary indexing.

Numerous data formats are prevalent in the point cloud data domain, and they tend to be segmented between "geospatial" point cloud formats and those that are unconcerned with world positioning. As confirmed by the question in Figure 9 of Appendix A, the OGC Community Standard ASPRS LAS format is likely the most commonly used format in the geospatial community. Its compressed, open source content encoding is called LASzip (or LAZ). Combined, these two formats dominate the marketplace for interchange and archive of geospatial point clouds.

Software should meet the following list of requirements to provide a credible capability stack for a point cloud web service. "Required" features share the property that downstream client applications expect to be able to depend upon them to support their application’s usage of point cloud data through a point cloud web service. While some of the requirements may be more important than others, no distinction is made in this report beyond describing their need.

A checklist of every requirement may not be achievable for a point cloud web service. Depending on client requirements, some design choices may be in opposition in such a way as to not allow them to both be implemented. The following section discusses a list of "Optional" requirements that represent a list of useful features that point cloud web services should strive to possess. If these options were available, they could certainly help with the utility and capability of web services focused on point clouds.

Esri I3S, is available as an OGC Community standard, but the initial specification was not complete for point clouds. In February 2018, Esri released documentation for the point cloud portion I3S specification on GitHub at https://github.com/Esri/pointcloud.

The point cloud portion of I3S represents a static tile set with data organized in separate files by attribute type. It is expected to be consumed by web clients over the internet, it is suitable to feed a browser-based renderer or data processing software, and it can be configured to store data in a lossless configuration. A complimentary package encoding called SLPK is also used to store I3S data in a form suitable for single-file disk storage or archival network transit.

PotreeConverter is an open source software project from Markus Schütz originally of Technische Universität Wien (TU Wien) that was developed in support of the Potree browser-based point cloud renderer. It is available online at PotreeConverter. PotreeConverter innovated a number of features in support of browser-based point cloud rendering. These include the notion of a pre-built, static hierarchy that defines the shape of the tree, storage of LASzip data objects that were friendly to cloud object storage scenarios, and a point data structure that conveniently maps to rendering capabilities.

Greyhound is an open source point cloud web service server that allows users and developers to interact with raw point cloud data. Because it is an active server, rather than a static tile set like the rest of the approaches contrasted, it provides many convenient features at the cost of server activity, maintenance, and complexity.

Greyhound was developed with a goal of supporting browser-based online rendering of point clouds. While other activities, such as processing support and data interrogation are supported by Greyhound, its design choices were made in support of rendering activities using a REST-style HTTP interface. These choices include a query interface that allows clients to make simple idempotent requests for data using a bounding cube and tree depth.

Unlike the tile-based approaches described in this section, clients need not adapt their query structure to the data source with Greyhound. They can control the pace and attribute composition of the returned data through the Application Programming Interface (API). A corresponding consequence of this flexibility is data caching can be more difficult, data redundancy and distribution requires specialized support, and an active server must be deployed to respond to requests at all times.

The Entwine Point Tiles (EPT) format is a formalization of the Entwine data organization approach which was constructed in support of Greyhound. EPT removed the server requirement of Greyhound in exchange for mandating that clients query against a fixed data structure. The fixed structure is more convenient for data management scenarios, and requires simpler infrastructure.

3D Tiles is a specification from Analytical Geographics Inc. currently incubating in the OGC Community Standard process as of fall 2018. The current specification can be found at https://github.com/AnalyticalGraphicsInc/3d-tiles, and it is expected to be available via the OGC Community Process sometime in 2019. Like I3S, 3D Tiles contains a data structure organized in support of streaming and rendering 3D geospatial content, and it includes support for textures, solids, triangles, and point clouds. In this section we will contrast the point cloud support of 3D Tiles and describe how it achieves support of properties required of point cloud web services.

We define a simple categorization to allow some gradation in defining a particular software suite’s support for a particular requirement. A value of 0 states no support for the requirement and essentially no work-arounds are possible. A value of 3 states that full support for the requirement is available in all software configurations.

This section defines a simple categorization to allow some gradation in defining a particular software suite’s support for a particular requirement. A value of 0 states no support for the requirement and essentially no work-arounds are possible. A value of 3 states that full support for the requirement is available in all software configurations.

The following section concentrates on two specific topics for the web services contrasted in Chapter 7 – content encoding and tree hierarchy. These two topics are critical to a static point cloud web service and future testbed activities should focus on describing the need and arrangement of these two features for any point cloud web service that OGC seeks to standardize.

As of September 28th, 2018, the online point cloud survey had 97 respondents. The submission window was held open for about two weeks, it was advertised in the Stuttgart OGC Technical Committee (TC) meeting on September 11th, 2018, and it was circulated on a number of mailing lists and social media channels.

A straightforward first question was whether or not respondents even have software interoperability challenges. Curiously, 20% of respondents said they do not. We are left to wonder if this is due to completely vertical software toolchains, but it is a slightly surprising number of individuals that report not having issues.

Of those reporting having interoperability challenges, the topics of data fusion, analysis, coordinate systems, and storage lead rather evenly. We postulate this is likely a sign of an early maturity point cloud software industry, with tools that specialize in specific topics not always talking well with each other

Following that up, nearly 40% of respondents stated that data storage and management represents the least challenging problem segment as far as software interoperability. The smoother interoperability provided by data storage using ASPRS LAS and LASzip, which both have wide software implementation support, may be responsible for this largest category.

Data storage leads as a frustrating challenge with point clouds, which is to be expected given their overwhelming size and wide possibilities of storage format. While the wide availability of LAS and LAZ provides base capability for many softwares, storage and management is still a significant challenge, and the market is not satisfied with the available solutions.

Coordinate system changes interestingly rank next. Point cloud data represent measurements, and measurement frame description and coordinate system transformation is a big part of making point cloud data work well for users. That participants are complaining about the topic is an indication that more work is needed in industry software to ease the challenge for most users. Wider implementation of WKTv2 ([spec-12-063r5]) and open source software implementations provided by efforts such as GDAL https://gdalbarn.com will certainly help improve the story more widely, but specific software implementation in point cloud tools is also needed.

Those looking to exploit point clouds represent the largest pool of primary usage, with a wide diversity of other uses representing different tasks and segments. The response to this question highlights the need for data interoperability choices to be oriented toward exploitation needs as a primary constraint.

Point cloud data volume is always described as large but exactly how large is difficult to quantify. In this question, we wondered if the description of their largess was simply whether or not they exceed the capabilities of typical workstations or laptops. Unsurprisingly the answer was overwhelmingly affirmative.

The question also is an indicator of where point cloud processing is likely to see its growth in terms of capabilities – desktop-based tools are often not up to the challenge, and dynamically scalable cloud-based computation is quickly becoming a requirement for point cloud processing scenarios.

Related to the size of point clouds people typically work with is the definition of a data collection size that is perceived as large. More than half of the respondents stated that a big point cloud was between 100 million and a billion points. This is a size at which a typical workstation would start to feel its size in terms of memory and processing, especially without additional processing to organize, filter, or subset the data.

Questions about data formats for the survey mostly pertain to the most prevalent data model – ASPRS LAS – and its complimentary compression content encoding – LAZ. ASPRS LAS for geospatial point clouds as an interoperability mechanism for the storage and transmission of data has been wildly successful. Software implementations are widely available, and those implementations typically do not leak data or capability, especially for the basic features of the format.

Some missing features of LAS have become apparent as volumes of point clouds have grown and the variability of software tools have increased. Specifically, the lack of intrinsic spatial index in the format has steered applications into developing ad hoc solutions that work for specific applications, but do not work across the implementation ecosystem. Second, while LAS represents a massive storage efficiency improvement over basic text or ASCII transport of point cloud data, the LAS' lack of compression has meant that those wishing for the most widely supported interoperability story must sacrifice three to five times the data storage in contrast to a content encoding such as LASzip.

The survey confirmed the use dominance of LAS and its compressed LAZ content encoding. It is important to make the distinction that LAS is prevalent in geospatial point cloud domains, and other formats such as PLY are more common in non-geo situations.

A breakdown of possibilities breaks down just how widely prevalent LAS and LAZ are. The market is missing an interoperable storage format that is suitable for archive that provides compression and spatial partitioning features. Some of the formats that respondents provide do have those features, but they are not openly specified.

Responses agree with the statement that open formats are critical, and the responses about the wide use and consumption of LAS, the most available open format for geospatial point cloud data possibly color the enthusiasm for open formats.

The topic of web services for point cloud data has been frequently identified as a desire, but the market appears to be relatively immature at this time. It is quite likely that the survey did not draw a diverse enough audience on this topic, but Potree and its data conditioning tool PotreeConverter were most well known in the survey.

Visualization of point cloud data is an excellent data confirmation tool, but size constraints often make holistic visualization of large collections problematic. Curiously, both visualization and level of detail streaming are identified by respondents as topics that a point cloud web service should address. Presumably, this is due to the challenging nature of keeping data flowing at a visualization environment, and the market’s familiarity with visualization capable tools such as Potree.