[pdal] The problem of multiple, same-named dimensions

Howard Butler hobu.inc at gmail.com
Tue Mar 6 14:48:24 EST 2012


All,

After I removed the explicit, enumeration-based Dimension::Id, it is now possible to have a pdal::Schema with multiple same-named dimensions on them. This is commonly needed for something like pdal::filter::Scaling that simply takes the dimension and adjusts the scaling of the data within it. The problem, however, comes when you want to ask the schema to give you one of those same-named dimensions -- there's now two or three of them with the same name, which one do you want?

The pipeline approach models things as a "before" and "after" with respect to stages, and for derivative dimensions of the same name, there's essentially a before and after picture too. Imagine a end point LAS writer asking for the "X" dimension that has come through a pipeline that has produced it, and applied a scaling filter to it. There will now be two X dimensions in the schema of the PointBuffer that the LAS writer sees -- drivers.las.X and filters.scaling.X.  With the new ability, the scaling filter can now say filters.scaling.x.setParent(drivers.las.X);  When Schema::getDimension("X") is called, it now respects these relationships and gives you the ending child (filters.scaling.X) by default.  You will of course be able to explicitly as for Schema::getDimension("X", "drivers.las.X") too, but this approach means that the end stage doesn't have to worry about intermediate changes -- it only needs to care about an "X" dimension.

An implementation has been pushed to master to implement this approach.  I'm looking for feedback or gotchas that people might see with it.

Thanks,

Howard






More information about the pdal mailing list