Well, the answer is not intended to be definitive, just a pointer to where to get started as there are, indeed, very many topics involved. But Style is where this seems to end up, so starting with the many Style topics as entry points to drill into all the many other topics is not a bad approach. The OP will have to learn how to construct the values (shown as fields in the illustration the OP attached) that will be used to drive Style: the "See Also" topics encountered in reading the many Style topics are likely to point the way. In this case, I agree, those values that drive Style are likely to be channels computed using some SQL expression. Respectfully (with puckish humor intended), noting that "The way to do this correctly is by SQL" is not exactly definitive, either. It would be interesting to see what a definitive, step by step guide would be for what the OP wants. That would have to start, I suppose, with understanding that what ArcGIS calls a raster attribute table in fact seems to be a vector construction, that essentially creates a grid of points behind the scene and saves in a .dbf the attributes for each point that corresponds to a "cell" in the raster. You can certainly do that in Manifold, creating a grid of points or area objects and then using join to join the value of each pixel into the vector object, using the various join operators like "count" to do that in a single step if you like. Given that Arc's "raster attribute table" is limited to only 65,536 "values" (I suppose they mean records) by default, it's not a big deal to do the same thing in 9. You could certainly have far larger tables like that in 9 , which would choke Arc if you optionally increased the allowed size in Arc. But that's a different thing than keeping it a truly 100% raster thing, which apparently Arc cannot do but which Manifold could do. So is the right way to meet the OP's desire to duplicate the Rube Goldberg approach used by Arc? Or is it better to use genuinely native raster approach that is possible in 9 but not in Arc? After all, doing it in a genuinely native raster way would be far faster for very large rasters, so that's a fair question. There's also the question that often comes up with a new user who may be trying to make progress with 9 by reasoning by analogy with something already known, to try to duplicate known workflow in 9: that's the question of whether it would make more sense to apply a more efficient 9 approach instead of duplicating an alien approach. For that, it would be helpful to know why the OP wants to see a presentation that pretends a raster is not a raster but is a regular grid of vector points. What's the ultimate goal for using such presentations, and is there a more direct, more efficient way of using 9 to accomplish that goal? When I see such tables that are clearly the results of spatial joins between rasters and a behind-the-scenes vector, I get the strong feeling that what's really going on is a need for a spatial join between raster and vector to generate some end result. Arc can't do spatial joins like that, but 9 can, so it doesn't need a pseudo-vector intermediate display. It could well be that an understanding of the OP's ultimate goal might point the way to a much faster and easier 9 workflow, which could work with vastly bigger rasters, than what ends up being used in Arc. It could be, of course, that the OP is learning 9 and is just curious about the differences in approaches to values within rasters used by 9, Arc, and Q. That's also a good thing to discuss, but it covers a lot of ground so maybe it's best to discuss it in the context of specific tasks.
|