Explicitly add entwine as a dependency

[rmam-spinworks]

Although greyhound's cmake build doesn't perform any version check on entwine, greyhound's source code includes header files from entwine that were removed from the project immediately after the v1.3.0 tag was set, which is in line with this announcement from entwine.

Currently, greyhound's Readme.md only mentions that "This repository is only in use for the Entwine 1.x releases", which implies that the latest release (v1.7.2) would also be supported.

Even if greyhound is bound to be mothballed, it would be helpful if greyhound's cmake project included checks for the supported version of entwine, and stated which package versions the project depends on.

[jo-chemla]

Hello, just needed a clarification. When you talk about mothballing greyhound, what will be the standard way to vizualize EPT tiled pointclouds? Same as today, plas.io or Potree or Cesium? Is there a preferred one - are potree and cesium more like Proof of Concepts today? Will greyhound still be used as mentionned on the repo more as a processing engine? And thanks a lot for the hard work!

[hobu]

what will be the standard way to vizualize EPT tiled pointclouds

Potree or PlasioJS will be two browser-based ways. We hope that others such as CloudCompare and commercial tools will implement the EPT API.

I made a note on scoping of the projects you can find at https://github.com/PDAL/PDAL/issues/2218#issuecomment-429851988

[rmam-spinworks]

@hobu sorry for going off on a tangent, but I've noticed you didn't mentioned Cesium. Are there any plans to support the EPT API in Cesium?

[hobu]

Are there any plans to support the EPT API in Cesium?

There is an entwine convert tool to convert EPT data to Cesium 3DTiles (requires a full data rewrite and probably doesn't scale past 10-20 billion points), and there is also https://github.com/commaai/entium. One could write a Cesium patch to support EPT directly, but that is not a topic we are working on at the moment. Another option would be for Cesium to adopt EPT as its access pattern for "deterministic" or "implicit" point-only tree types. There has been some discussion with the Cesium team on that topic, but nothing has materialized yet.

Cesium+EPT is a topic where the community needs to step forward. Hobu is not going to generate the development momentum on it because we do not need it. We are available for hire to address the topic if someone wants to pursue that angle.

[rmam-spinworks]

@hobu yeah that's reasonable. Thanks for the headsup and keep up the good work.

[sunapi386]

I'm trying to build greyhound and ran into this issue as well, that greyhound has dependencies to entwine, despite not being mentioned on the administration page.

/home/jsun/workspace/greyhound/greyhound/main.cpp:3:10: fatal error: entwine/util/stack-trace.hpp: No such file or directory
 #include <entwine/util/stack-trace.hpp>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

It seems as greyhound is indeed getting mothballed/neglected.

I'm looking at greyhound to provide an API layer for supporting clients that may query TBs of points samples. I was thinking entwine can be a good alternative than to setup a complicated Geowave/Geomesa data store based on accumulo. The Geowave/Geomesa doesn't seem to natively support pointclouds but rather points() itself. These two data stores would need to be used with fixed and static tiling scheme. I'd like to request the level of detail sub-sampled points.