Visual glitches with open=FALSE

[jmw86069]

I love this package, such a cool idea! For what it's worth, I'm intending to use it to render polygons with inner and/or outer borders. (I'm surprised mapping tools sf don't have options to render inner border to colorize adjacent countries, or counties.) Anyway this package seems like the ideal choice, so I'm converting my previous kludge to use grid and vwline. Winning. :)

I'm posting the issue to make sure you've seen it. I have a workaround - TL;DR use linejoin="bevel"

Test case is below, starting with linejoin="bevel":

library(vwline);

# make a hexagon
aseq <- seq(from=0, to=300, by=60);
xbox <- (cos(aseq/180*pi)/2.2 + 0.5);
ybox <- (sin(aseq/180*pi)/2.2 + 0.5);

# define fixed line width
w <- rep(0.04, length(xbox));

# plot the test case
grid.newpage()
grid.vwline(x=xbox, y=ybox, w=w,
   linejoin="bevel",
   open=FALSE, gp=grid::gpar(col="gold", fill="darkorange"))
grid.path(x=xbox, y=ybox, gp=gpar(lwd=3, fill=NA))

That works fine. But if using linejoin="round" (default) or linejoin="mitre", they produce graphical glitches:

grid.newpage()
grid.vwline(x=xbox, y=ybox, w=w,
   linejoin="round",
   open=FALSE, gp=grid::gpar(col="gold", fill="darkorange"))
grid.path(x=xbox, y=ybox, gp=gpar(lwd=3, fill=NA))

(It looks even odder with linejoin="mitre".)

I dug around a bit, and it appears to affect a specific edge case - a common one, but specific.
For my testing, it only occurs with counter-clockwise points, closed polygons open=FALSE, only (or mostly?) on the outer portion of the line, and only for linejoin="round" and linejoin="mitre".
If I reverse the order of points (so it draws clockwise), the problem appears to be gone:

xbox2 <- rev(xbox);
ybox2 <- rev(ybox);
grid.newpage()
grid.vwline(x=xbox2, y=ybox2, w=w,
   linejoin="round",
   open=FALSE, gp=grid::gpar(col="gold", fill="darkorange"))
grid.path(x=xbox, y=ybox, gp=gpar(lwd=3, fill=NA))

However, it doesn't fully avoid the problem, the bottom-right corner is "bevel" and not "round". (Confirmed by drawing the same with linejoin="mitre" it still shows "bevel" in that corner.) Frankly, I can live with that, if that's as intended.

Fully love the package - I'm going to use "bevel" for time being, but wanted to post some positive feedback from a user, and let you know about the graphical artifacts. And if I've done something wrong on my end, sorry for taking your time!

(PS - Is there an equivalent to grid::grid.path()?)

[pmur002]

Thanks very much for the report! This is just to let you know I have seen it - it may take a little while to investigate.

[pmur002]

In case it is a useable workaround, have you seen the {gridGeometry} package? That makes use of the {polyclip} package to generate polygon offsets. If you only require fixed width offsets, that should do the job for you. {gridGeometry} is explained here and the polygon offset stuff in particular here.

[jmw86069]

Thank you for the suggestion, it looks quite promising and may solve my situation. I'll try in the next couple days (+/- life's priorities) and post back.

[jmw86069]

Do have a feel for 0.4.0 may be released to CRAN?

And wow this package is also just brilliant! I think it's going to work for my use cases.

I briefly chased an issue with orientation of nested polygons... then realized you have the argument rule in polyoffsetGrob() because you've thought of everything. Haha. Nice.

I'll keep on with it from here. Thanks again for the spot-on suggestion!

[pmur002]

I believe the original problem with {vwline} is now solved. Interestingly, the seemingly small problem with one of the "round" corners being "bevel" was the clue; the final corner on closed lines was not being used properly. {vwline} version 0.2-3 (with this fix) has been submitted to CRAN.

[pmur002]

{gridGeometry} version 0.4-0 has also been submitted to CRAN.

[jmw86069]

Holy moly, {vwline} is version 0.2-4, and {gridGeometry} is version 0.4-0, both on CRAN already!
That is a seriously fast turnaround! Thank you sir. You have the fast track, haha.

Alright, I know what I need to do now. I think gridGeometry is slightly better for my case. I don't have to determine if the right/left side of a path is inside/outside. Instead, I always expand for outer border, and shrink for inner border. I also tested rule="evenodd" and it works polygons with internal holes without me having to reverse the orientation of points. Nice.

My use case (driven by another project) in case you've crossed this idea in past, is inspired by maps, which sometimes color the border inside the boundary (below):

Anyway, I will test your vwline changes - I have a test case that looks odd, but might be my fault. Probably my fault.