[pdal] Metadata/Option vs naked property_tree

[Michael P. Gerlek]

Nuts -- I was afraid we'd come back to this. :-(    Yes, I wound up not exposing the raw property trees, but I can't recall why right now. At least part of it was I wanted to a tighter/cleaner/simpler interface than property_tree gives, but more than that I don't recall.

When you write "path.to.data" does that imply this structure

	Key: "path"
	Value: <a ptree>
		Key: "to:"
		Value: <a ptree>
			Key: "data"
			Value: <an actual string or int or something>

as opposed to just this:

	Key: "path.to.data"
	Value: <an actual string or int or something>

?
-mpg


> -----Original Message-----
> From: pdal-bounces at lists.osgeo.org [mailto:pdal-bounces at lists.osgeo.org] On Behalf Of Howard Butler
> Sent: Tuesday, April 24, 2012 7:27 AM
> To: pdal at lists.osgeo.org
> Subject: [pdal] Metadata/Option vs naked property_tree
> 
> Michael,
> 
> If we want to be able to say metadata.get<std::string>("path.to.my.metadata.entry") how should that be anything other than a
> naked property_tree?  As far as I can tell, the only thing we want to do different is to serialize name/attributes when going to XML
> (like in PipelineWriter). Maybe we can get rid of Option/Options and Metadata/Entry altogether and simply have property_trees.
> Downsides?  Do you remember what moved you toward a custom class when you cooked up Option/Options?  Can you make the
> case for keeping these as custom classes rather than having them either be a simple string-serialized property_tree?
> 
> Howard_______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal