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

[Michael P. Gerlek]

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.

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

-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