Closed rsaccon closed 2 years ago
Your analysis is correct. There are duplicated or near-duplicated points in the bounding box as outcome of the closing/clipping process.
This probably needs to be done after all clipping/closing is done. I believe this only happens on the edges of the bounding box, so perhaps one way to dedup is to sort the points on each one of the edges and merge if their distances is less than some epsilon multiplier.
Ideally this would be an improvement added to the library. so consumers do not need to do this every time. Certainly I would welcome a PR to address this, if you are interested!
Ok, thanks, I will try to approach the dedup as you suggested.
Lastest changes to master include an improvement to deduplicate all clipped voronoi edge vertices.
Great, thanks, will update and see wether I can get rid of my dedup hack.
if I look at the
voronoi.vertices()
of a random voronoi diagram with bounding box from (-3000,-2000) to (3000, 2000) and three sites, I see this:Now this seem to be a lot of vertices. Let me try to understand this: 0) is somewhere in the middle, 1) 2) 3) 4) are the corners of the bounding box and 5) 6) 7) are outside the bounding box. This looks all fine to me. 8) to 13) are on the boundary but they contain contain duplicates: 8) 11) are quasi duplicates, 9) 12) are quasi duplicates, 10) 13) are quasi duplicates.
Did I mess up something to end up with this kind of data ? Or is the user supposed to dedup this duplicate-vertices-on-boundary by himself, if needed ? Or are these duplicates there for a reason ?