[Pointdown] Welcome and Charter

[Howard Butler]

All,

I would like to welcome you to the Pointdown effort. Started at the OSGeo 2015 Philly Code Sprint [1], Pointdown is an effort to openly describe and develop a service definition for point cloud data consumption on the web. I will try to articulate what the current challenge that Pointdown is to address, and then our first task will be to have participants attempt to describe what they think the scope of this effort should be. After that, willing participants will develop wiki pages that describe some of the processing, access, and storage techniques they are using to deliver data to web browsers and other clients. Finally, I will lead the effort to come up with some sort of draft, which I expect will be properly crapped upon before iterating toward some kind of satisfactory point where software validation will illustrate whether or not we are moving the right way.

The current challenge is there is no regularized protocol, format, or service that is specified to allow the separation of concerns regarding the development of point cloud streaming technology. Whether the data is delivered to a WebGL client like http://plas.io or http://potree.org or CesiumJS, a native tablet app like Glob3 [2], or native client software like CloudCompare [3], someone who wants to get data from point A to point B in a progressive way must develop all pieces of the puzzle. While this gives an individual the most development control, it does not allow for much specialization, and the development of the entire stack is somewhat imposing. There are tons of formats that are linear in nature (LAS, LAZ) or database'y (pgpointcloud, PDAL's sqlite implementation), but very little that is a) openly specified, b) supports progressive streaming,  c) efficient enough to be useful, and d) simple enough to implemented across many language stacks. 

Like the many who have tread before (W3C, IETF, ISO, OGC, etc), there is some value to be realized in collaboration and standardization of some kind of interface, but growing from a kernel of an idea to an ecosystem of interoperating software is a significant challenge. I propose we follow the same successful methodology of specification development as GeoJSON. The principles of which include:

1) Civil public discussion on an open mailing list that any interested party can join
2) A full history of the discussion, available in list archives
3) An open wiki and workspace, to be hosted on github
4) Illustration, experimentation, and persuasion through open source code and openly testable examples
5) An example-driven final document of limited scope that is available for all

A crucial distinction of the GeoJSON effort was open source software provided validation and testing of arguments along the way. Instead of communicating through "Track Changes", we will communicate through public demonstration of software, pull requests, and mailing list exchange. Should the effort be successful, the record that we produce along the way will give those who come behind us the opportunity to answer WTF. We value a straightforward document that can be implemented, followed, and leveraged through cargo cult programming. We value simplicity. Dumb is better than clever.

I don't know if we're developing a format (mbtiles-like for point clouds), a server protocol (WMTS-like for point clouds), or what (something special). Let's figure that out given the challenges we've technically solved already. Let's show how our code works. Let's do it in the open. 

Howard 


[1] wiki.osgeo.org/wiki/Philadelphia_Code_Sprint_2015
[2] https://github.com/glob3mobile/g3m
[3] https://github.com/cloudcompare