[pdal] PDAL Pipeline Extensibility

[Rob Emanuele]

I haven't had a need for it, but I'll comment on this: "application" is a
confusing term, and at first blush I read it as "shelling out to some
external application". Re-reading your description, I believe what this
feature would enable is to allow for JSON to be inserted into pipeline
stages that PDAL will completely ignore but not complain about. So in case
I was parsing the pipeline, or programmatically creating it/reading from it
in my own application outside of PDAL, I could insert any JSON I wanted to
and PDAL wouldn't have a problem with it (and not do anything with it). Is
that a correct read?

If that's correct, I would say instead of "application", some better terms
would be "tags", "userData", "userTags", or something along those lines.


On Wed, Dec 21, 2016 at 7:05 PM, Adam Steer <Adam.Steer at anu.edu.au> wrote:

> Just trying to unpack this idea: is the thinking around enabling some
> external program - for example some bespoke, super efficient, parallelised,
> on-the-fly classifer; or some other point modifier that isn’t, or
> won’t/can’t be in PDAL - to modify points as they’re read/written?
>
> Without having actually had a need to use such a capacity, it seems pretty
> handy and might open doors to a whole host of new capabilities in PDAL.
>
> So:
> q1: without having actually had a need to use such a capacity, it seems
> useful
> q2: keeping mind the answer to q1 - nope. ‘application’ seems to be a good
> label for that particular box
> q3: will need to defer to others - I consider myself a PDAL/JSON beginner
>
> Standing back a bit, probably being quite ignorant about a bunch of stuff,
> and thinking about supporting PDAL in N years time - I see a small risk of
> slowing some feature development in PDAL (maybe? can I think of a case of
> how? possibly developer X’s killer app never makes it into PDAL as a
> feature because it no longer needs to?) and based on this a small risk of
> making more dependency issues (using developer X’s killer app, now anyone
> deploying it has to maintain versions of two things). However, in this
> scenario it is also reasonable to expect that an organisation relying on an
> OSS project would contribute some resources in order to mitigate those
> issues.
>
> Hope that helps - and I hope more experienced folk chime in!
>
>
>
> >> {
> >>  "pipeline":[
> >>    {
> >>    "type" : "readers.las",
> >>    "filename" : "/data/255.laz”,
> >>    "application": {
> >>        "something": 42,
> >>        "something_else": {"key":"value"},
> >>        "lots_of_things":[1,2,4,8]
> >>    }
> >>    },
> >>    {
> >>        "type":"writers.gdal",
> >>        "radius":10.5,
> >>        "resolution":6,
> >>        "filename":"/data/dem.tif",
> >>        "application": {
> >>            "comment": "a string",
> >>            "my_app": {"key":"value"},
> >>            "user_who_made_this": "howard",
> >>            "center_point":{ "type": "Point", "coordinates": [100.0,
> 0.0] },
> >>            "box":{ "type": "Polygon", "coordinates": [[ [100.0, 0.0],
> [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0] ]]}
> >>        }
> >>    }
> >> ]
> >> }
> >
>
>
> > The idea is applications can use this 'application' node to transmit and
> communicate their own information through PDAL pipelines. I have three
> questions:
> >
> > 1) Is this useful enough to support?
> > 2) Do you have a better name than 'application'?
> > 3) Is the a standard convention that people use in JSON to do this kind
> of thing?
> >
> > Thanks,
> >
> > Howard
> > _______________________________________________
> > pdal mailing list
> > pdal at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/pdal
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20161221/e110d25b/attachment.html>