[pdal] Pipeline XML as primary channel?

[Michael Gerlek]

One more rule:

The root element should always be Pipeline (not WriterPipeline), and
it must have exactly one child, which will be either a Writer or a
Stage.

.mpg

On Aug 18, 2011, at 6:20 PM, Michael Gerlek <mpg at flaxen.com> wrote:

> Actually the rules can be a bit tighter, I think, if we add a
> FilterType and a MultiFilter type...
>
> - Reader, Filter, and MultiFilter are all kinds of Stages
> - a Writer is not a Stage, however
>
> - Writers have exactly one Stage child
> - Readers have zero Stage children
> - Filters have exactly one Stage child
> - MultiFilters have one or more Stage children
>
> I'll make up some examples tomorrow.
>
> .mpg
>
> On Aug 18, 2011, at 5:28 PM, Pete Gadomski <pete.gadomski at gmail.com> wrote:
>
>> All,
>>
>> Sorry, I needed to set maxOccurs="unbounded" in for Option elements.
>> Attached is the updated .xsd
>>
>> Pete
>>
>> 2011/8/18 Pete Gadomski <pete.gadomski at gmail.com>:
>>> Howard,
>>>
>>> I've attached an .xsd (and a validating .xml) for a possible pipeline
>>> xml format.
>>>
>>> Cheers,
>>> Pete
>>>
>>> On Thu, Aug 18, 2011 at 15:25, Michael P. Gerlek <mpg at flaxen.com> wrote:
>>>> If we're going to push the xml a little further, I'd be inclined to relax my
>>>> initial position that it needed to be read/written via the ptree xml
>>>> serializer.
>>>>
>>>> I had the idea that we could serialize as json, etc, too, but I think it is
>>>> more important that we have flexible XML reading/writing (such as using
>>>> attributes and supporting xsd validation and such).
>>>>
>>>> -mpg
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Howard Butler [mailto:hobu.inc at gmail.com]
>>>>> Sent: Thursday, August 18, 2011 2:03 PM
>>>>> To: mpg at flaxen.com
>>>>> Cc: 'Pete Gadomski'; pdal at lists.osgeo.org
>>>>> Subject: Re: [pdal] Pipeline XML as primary channel?
>>>>>
>>>>>
>>>>> On Aug 17, 2011, at 5:40 PM, Michael P. Gerlek wrote:
>>>>>
>>>>>>> `//Filter[@type="filters.reprojection"]` seems cleaner than
>>>>>>> `//Filter/Type[text()="filters.reprojection"/..`.
>>>>>>
>>>>>> Wow, they both just look like so much @$#^@%$//! line noise to me...
>>>>>> :-)
>>>>>>
>>>>>>> * <opinion>Attributes work well for atomic values e.g. driver types
>>>>>>> and option names.</opinion>
>>>>>>
>>>>>> <opinion assertedas="fact">Agreed.</opinion>
>>>>>>
>>>>>>> <WriterPipeline>
>>>>>>>   <Writer type="drivers.oci.writer">
>>>>>>>       <Option name="debug">true</Option>
>>>>>>>       <Reader type="drivers.las.reader">
>>>>>>>           <Option name="filename">in.las</Option>
>>>>>>>       </Reader>
>>>>>>>   </Writer>
>>>>>>> </WriterPipeline>
>>>>>>
>>>>>> Yup, that's basically what I had when I started the project -- but
>>>>>> then I found out that boost::property_tree doesn't serialize to XML
>>>>>> attrs quite as cleanly as I'd like.  I'm going to revisit that issue
>>>>>> this afternoon, I think.
>>>>>
>>>>> I agree that our pipeline XML isn't optimal, and we should move it toward
>>>>> something sane earlier rather than later.  Pete, when you get some time,
>>>> can
>>>>> you help me cook up an XSD that we can use to externally validate our
>>>>> pipelines?  I'll work to implement it.
>>>>>
>>>>> Howard=
>>>>
>>>>
>>>
>>
>> <writerpipeline.xsd>