chris, i can't answer all your questions, but here's some extra info which may help.
in general, fields should NOT have both invalid positions & connections. i remember spending a few sessions at the whiteboard trying to decide exactly what it would mean if they weren't completely consistent with each other. we finally decided that the rule for a well formed field was that the invalid component should match the data dependency. so if the data was dep positions, it was invalid positions. dep connections meant invalid connections. a field with no data could pick but just one. i know strange things happen when you have both, and Include goes out of its way to make sure it doesn't produce them. i'm not sure but an interesting experiment might be to run your field with both components through Include w/ no parms set and see what comes out. i can't find the code right now, but my guess on the Replace() causing both components to show up is this: Replace() calls EndField() to do processing like computing a new bounding box, or adding missing attributes if it can tell what they should be, or computing the neighbors components. i can't find the call so maybe it's not in EndField(), but somewhere i am sure that there is code in the invalid processing which looks at the invalid component and decides based on the number of invalid items whether it's more efficient to store them as an integer index list or as a byte-map. perhaps somewhere in that processing it's generating the opposite invalid component. is the one which is newly added the same as the data dependency of the field? i'm no help with why Band would treat data values of 0 as special. nancy [EMAIL PROTECTED] > > > Date: Fri, 3 Dec 1999 13:39:37 -0500 > From: Chris Pelkie <[EMAIL PROTECTED]> > Subject: Re: [opendx-users] Band and invalid data > > Regarding Simon's problem with Band, I spent some time yesterday working on > it and discovered something odd that I've never seen before in DX. I > haven't finished working on this, but I thought Donna or Nancy or others > might have thoughts. > > In the test file Simon sent, there are both "invalid positions" and > "invalid connections". I thought this was weird, and probably bad, but this > is what Export output. > > I did the following: > 1. Remove "invalid positions", to Band, Autocolor, Image: this works. > 2. Remove "invalid connections", B-A-I: error that Simon reported about > dependent array must be scalar bytes > > 3. Checked and in fact, using Compute, forced "invalid positions" to scalar > bytes of only 00 and 01, then B-A-I: Didn't fix it (same as Test 2). > > 4. Remove both "inv pos" and "inv conn", B-A-I: this works. In fact, it > doesn't look a whole lot different than when you leave "invalid > connections" in. There are some subtle differences. (Simon, did the > invalids result from processing to remove the "0" data in the net that > Exported this test?) > > 5. Ran the original data through Autocolor-Image (no Band): works without > complaint. Of course, this shows a regular grid eroded by invalids. > > 6. Removed both invalids, A-I: works and of course shows the whole regular > grid with lots of blue "0" areas. > > 7. Reconstructed a field from Extracted "positions", "connections", "data", > and various permutations of the "invalid"s in the original data using > Construct and Replace. This is where is gets weird: > > I Extract the "invalid positions", and Print them, and see a Generic array > of scalar bytes as expected. But the simple act of Replacing these into my > constructed Field, then Print that output shows that the field now > miraculously has both "invalid positions" and "invalid connections". I > don't think I've ever seen this happen. Richard and I started to poke > around in some likely source code like helper.c and invalid.c (whew: that's > a monster!) but didn't find the answer before other duties called. > > Now, as remarked earlier, the output of Band when the input field has no > invalids shows the original regular grid with large holes in it and a > variety of sliver triangles within the original grid cells (in some areas). > These holes apparently occur wherever the data was "0". I guess I don't > understand why Band should throw away all the "0" data. But clearly it is > and therefore internally it is generating its own "invalids", then > apparently culling them. > > So my tentative hypothesis is that the weird combination of a field with > both invalid positions and connections, run through Band which tries to do > its own invalidating, caused DX to barf trying to resolve who is more > invalid. It may be the order that invalids are applied: if positions are > invalidated first, but don't mesh perfectly with the polygons that invalid > connections say are invalid, then I can imagine that the field internal > structure may be corrupted and some error message generator deep down > inside is spewing an error that isn't exactly the cause but a side-effect > of the real problem. > > 8. Reminded by Donna's remarks on "ref" invalidity, I played with the idea > that the "invalid connections" are processed first, then, somehow the > "invalid positions" are being internally recast as "ref" rather than "dep". > This didn't seem to pan out. > > So, what do you think? > Why does Replace instantly generate "invalid connections"? > Is it OK and I just never noticed it, to have a field with both invalids at > the same time? > Am I guessing right about Band's internals? > Why does Band cull "0" (Simon might want to see all the 0 data!). > > Chris Pelkie > Vice President/Scientific Visualization Producer > Conceptual Reality Presentations, Inc. > 30 West Meadow Drive > Ithaca, NY 14850 > [EMAIL PROTECTED] > (607) 257-8335 or (607) 254-8794 >
