[pdal] The problem of multiple, same-named dimensions
Michael P. Gerlek
mpg at flaxen.com
Fri Mar 23 16:50:00 EDT 2012
(this has been sitting in my inbox for a while, sorry...)
The remaining problem is how to handle to multiple filters of the same name, e.g. if you have field "X" that goes through two filter.crop stages -- either because you do the crop twice for some reason in a linear pipeline, or because you have two crop filters sitting "behind" a multistage filter.
On IRC this morning I suggested this be handled by assigning DFS (depth-first search) numbers to each stage in the pipeline and somehow using them. Better, though, I also suggested we give add an Option to each Stage which allows the user to provide an explicit, custom stage name that he can refer to.
-mpg
> -----Original Message-----
> From: pdal-bounces at lists.osgeo.org [mailto:pdal-bounces at lists.osgeo.org] On Behalf Of Howard Butler
> Sent: Tuesday, March 06, 2012 11:48 AM
> To: pdal at lists.osgeo.org
> Subject: [pdal] The problem of multiple, same-named dimensions
>
> 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
>
>
>
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal
More information about the pdal
mailing list