[libpc] The specialness of X, Y, Z dimensions

[Howard Butler]

On Apr 13, 2011, at 10:53 AM, Michael P. Gerlek wrote:

> Yes: the filters that assume X is a double are broken, based on the current
> getField() model.  This is really my fault, as I was just whipping out the
> "demo" filters to see if they'd function at all.
> 
> If I understand what you are asking, your idea is to add a new function
> getFieldAs<Tsrc,Tdst>(), which would know how to convert the actual
> underlying type Tsrc (in this case an int) to the desired type Tdst (in this
> case a double).  This is more than just a simple conversion, because the
> source type in this case is "special", in that it is scaled, so the function
> would have to "know" this.

Can't we determine the output type from the return type of the function?  I'm not so template aware though ...

Tdst getField<Tsrc>(index, fieldIndex);

> 
> Closely related, I wonder if the enum Int is the wrong type for X -- maybe
> it should be a special enum ScaledInt?

Isn't that implicit by the existence of a scale/offset value for the dimension?


> 
> -mpg
> 
> 
> 
>> -----Original Message-----
>> From: libpc-bounces at lists.osgeo.org [mailto:libpc-bounces at lists.osgeo.org]
>> On Behalf Of Howard Butler
>> Sent: Wednesday, April 13, 2011 7:49 AM
>> To: libpc at lists.osgeo.org
>> Subject: [libpc] The specialness of X, Y, Z dimensions
>> 
>> Michael,
>> 
>> One of the things I've struggled with is a lot of the filters have
> X::Double etc
>> baked in as the X dimension for their operations, but my reader is
> producing
>> X::Int32+scaling.  What should the filters be doing?  Looking for Field_X
> plus
>> every combination of DataType?  This seems silly.  The crop filter *wants*
>> XYZ data as a <double>, but some other filter might want unscaled data to
>> work with (if it is available).
>> 
>> What if we were able flip around the getField call to return what you
> wanted
>> instead of what you have?
>> 
>> // Return you the *first* X dimension in the schema, regardless of
> DataType
>> Dimension const& xDim = schema.getX(); int fieldIndex =
>> schema.getDimensionIndex(xDim);
>> 
>> double x = buffer.getField<double>(index, fieldIndex); // Would implicitly
>> apply scaling if the dimension had it uint32_t x =
>> buffer.getField<uint32_t>(index, fieldIndex);
>> 
>> A challenge is getField currently gives you direct access into the buffer,
> so
>> there's no need to worry about differing type sizes.
>> 
>> What do you think?
>> 
>> Howard
>> 
>> 
>> _______________________________________________
>> libpc mailing list
>> libpc at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/libpc
>