[pdal] Re: Gist notes

[Howard Butler]

Whatever the boost::uuids::string_generator constructor can take in? :)

I don't have a strong preference, and to be honest rather hate GUIDs, but I cannot think of something more universally supported that's better.  If I had to choose, I'd choose a) because that's how Python works with them.

On Dec 9, 2011, at 1:50 PM, Michael P. Gerlek wrote:

> Syntactically, what does a GUID look like to you?
> 
> a. 3F2504E0-4F89-11D3-9A0C-0305E82C3301
> b. {3F2504E0-4F89-11D3-9A0C-0305E82C3301}
> c. urn:uuid:3F2504E0-4F89-11D3-9A0C-0305E82C3301
> d. other?
> 
> _mpg
> 
> 
> -----Original Message-----
> From: Howard Butler [mailto:hobu.inc at gmail.com] 
> Sent: Friday, December 09, 2011 11:34 AM
> To: mpg at flaxen.com
> Cc: pdal at lists.osgeo.org
> Subject: Re: Gist notes
> 
> Putting this discussion on the PDAL list if anyone cares.  We're discussing a proposal to change how Schema work with Stage and PointBuffer.  In short, Stage will no longer have a Schema, and only a PointBuffer will have a Schema.  Stage will advertise dimensions it consumes or produces, and PointBuffer is left to compose them into a Schema however it wishes.
> 
> https://gist.github.com/1406139
> 
> 
> On Dec 9, 2011, at 1:06 PM, Michael P. Gerlek wrote:
> 
>> The gist document on Dimensions makes more sense to me now, thanks...  Here's my comments:
>> 
>> Line 35:  note sure what "nonunique type/name" means -- or is this referring to the case where you have a "before" and "after" version of a field that gets modified, such that you'd use the guid to distinguish (lines 65-67)?
> 
> A ScalingFilter might take a las.X and scale it to scale.X.  Their type/name are both the same, X, and they can be distinguished by both their different GUID and different fully qualified names.  A call to schema.getDimension("X") is going to throw an exception because there's two of them.  They need to call schema.getDimension("las.X") (or schema.getDimension(las_x_guid)) to fetch the one they want.
> 
>> 
>> Line 41, 42: when you say "to read" do we also mean "to write"?
> 
> yes. You cannot use free-standing dimensions to interact with a PointBuffer.  You need to fetch references from the buffer.getSchema() and pass them into getField/setField to operate.
> 
>> 
>> Line 47-48: not sure I understand this about "casting only happens" if the sizes are different.  What about int32 and float32?
> 
> good point.  I'll fix this if the type or size is different.  If the signing is different, however, I'll leave it alone.  Maybe you *wanted* that :)
> 
>> 
>> Lines 53-55: let's find another word instead of "default"?
> 
> Agreed.
> 
>> 
>> Line 67: yes, good idea
>> 
>> Line 72: mm, okay, I'll modify my expression parser to support periods (".") in variable names?
> 
> 
> And GUID strings. I expect the natural way in nearly every case is to use the fully qualified dimension name, but I can craft artificial situations where you could potentially have two equal fully qualified names. The GUID thing would allow someone to version dimensions for specific PDAL versions.  I plan to use these inside of XMLSchema instances in addition to the fully qualified name in case some driver needs to change its behavior for a specific dimension.
> 
> For example, if the PDAL QFIT driver mis-interpreted qfit.X in a specific version, another subsequent version could compare the XMLSchema GUID of that qfit.X to its current one and potentially smooth things over. The GUIDs allow us to precisely say  "I want the X dimension from the drivers.las.Reader stage with guid XXXX" if we wanted to. In *most cases*, however, we only care about schema.getDimension("X").
> 
> Howard=
>