#814 Allows input from binary data for 'splot with polygons'
This patch allows input from binary data in 'splot with polygons'.
A polygon consists of sequence of points. When multiple polygons are given as data, the point sequence data must be delimited in some way. In text data, the delimiter is a blank line. For binary data, there is no correct rule, maybe.
I usually give NaN to (x,y) data as a delimiter when passing data in binary. This has worked well for polygons in plotting with boundary lines or single color fills for polygons. However, when I try to use "lt variable" or "fc rgb variable" to colorlize each polygon, it does not work.
The comment on the line 989 of plot3d.c says
/* Version 6: Store all available info even if one of the
* FIXME: However, the datatype of the datatype is not available.
* FIXME: However dgrid3d cannot deal with z = NaN or Inf.
* Fall back to ignoring it as version 5 did.
*/
As the comment saying, the point sequence data passed to plot3d_polygons() is not split, even if NaN is included, and all point sequences, including NaN, are passed as a single isocurve.
In this patch, the behavior is changed so that the point sequence passed to 'plot3d_polygons()' is divided into polygons by separating the point sequence by records containing NaN in x or y, and each is passed to the drawing routine ('pm3d_add_polygon') independently. I believe this will work as in the previous implementation for data that does not contain NaN.
This method may be just a work-around.
I would be happy to hear your opinion, including whether this method is appropriate.
In any case, it is my hope that 'splot with polygons' will allow binary input.
Attached files
test_polygons.gp : test script
data.txt : text data for test_polygons.gp
data.bin : binary data for test_polygons.gp
_6.0.png : results for version 6.0
_6.1.png: results for current version with this patch
test script was not attached. I used a variant of the one for patch #813.
First thoughts
Rearranging the data inside the plotting routine for 3D polygons strikes me as being way too late. I think it would be better to make the binary input path more parallel to the ascii input path.
If there were a condition that the binary input recognized as equivalent to a blank line, df_readbinary() could simply return DF_FIRST_BLANK and everything would "just work". That's tricky, however, because NaN is valid input for many plot modes so it is not sufficient to test NaN without checking other things like the plot style and. I suppose this is possible but I didn't try it.
Backing off one level, plot2d:get_data() and plot3d:get_3ddata() could test for NaN input under appropriate conditions and substitute DF_FIRST_BLANK for the actual return value. I created a proof-of-principle patch for plot3d.c that seems to work on the attached test case. But it only checks for
splot ... binary with polygonsand I only tested withbinary format="%3f%2i". I'd be happier if the test were replaced with something that applies to many/most/all non-image plot styles. I have not thought deeply about how this would interact with other binary file options likebinary matrixbinary recordand so on. These may or may not be relevant to plotting with polygons.What do you think? Do you use binary input for other plot style where a binary equivalent to "blank line" would be useful?
Sorry. Attached is my test script.
I was over-thinking this. Yes it's hard for the program to know when it is or isn't appropriate to treat a NaN value as indicating a blank line. But we can leave that up to the user.
This patch to datafile.c introduces a new binary file keyword option
blank=NaN. If that option appears in the plot command then a NaN value in the first field of a binary record is treated as a blank line. This only applies to general binary input, and only if the user requests it. No changes are necessary to higher level routines. Given that it is only applied if the user requests it, I don't expect any unpleasant side effects.Your test script would use, e.g.
Thank you for working on this matter.
Your solution with the keyword option blank=NaN is preferable and sufficient for me. I like the fact that this method is only valid when a break line with NaN is required and has no side effects in other cases. Another good part is that it can be applied to cases other than polygons.
There are certainly plotting styles that treat NaN as valid data (hsteps), so I agree with the solution by introducing this keyword option.
"binary_blank_if_NaN.patch" has been applied to my environment and confirmed to work.
So if the first column contains NaN, the record is considered a blank row.
I am satisfied with this behaviour, without the need to modify plot3d_polygons!
Now in git.
The associated documentation section is under "binary general".