New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] MultiPolygons with holes #8340
Conversation
Given that the New Glyph approach does not intersect with any existing codepaths, I am sorely tempted to consider this as a late add for 1.0, but "done" also means tests, a user's guide section, a contour plot example, and geojson example.... I think that's probably more than can be accomplished in a few days. Also, I am not sure more work isn't really needed before this is truly useful for Geo work. I was trying to add a tile source under a GeoJSONDataSource scatter earlier today and gave up because one used lat/lon and the other web-mercator. We'd need to figure out how to make things work well together without users having to do alot of conversions by hand. Most importantly, though: this is fantastic to finally be close to having, thanks for putting things together @jsignell |
Questions:
|
@bryevdv I'd be happy to push on this and try to get it in for 1.0, I'll just probably need some more help :) |
That sounds correct to me.
It seems like intersection per se isn't a problem, e.g. a pattern like this has lots of intersections but still seems valid: The same hole intersecting more than once could be a problem, depending on how it's done, but I'm not sure how to characterize what would be legal and what shouldn't be. |
Let's keep things simple at least for now, the center of the exterior ring
I don't think we are using the spatial index at this point? If you put all MBB of all exterior rings for each MPgon in the index in an https://github.com/bokeh/bokeh/blob/master/bokehjs/src/lib/models/glyphs/patches.ts#L74-L98 EDIT: looks like
It's a DataSpec, it can either be a fixed value or a reference to a CDS column
I think just check that it is in the exterior ring but not the holes. If you spatially index the exterior rings then that will narrow down the candidates to brute force this way. More sophisticated approach might spatially index the holes too but thats complex enough that it would need to be justified.
Let's say no, for now at least
I think interior overlap is an error, if that is easily detectable. Tho feel free to console.log any situation that you think might have unexpected or ambiguous results for users. |
I'm available, then. Let's try to shoot for EOB Friday, and if not no worries we will have a follow on release soon. |
1a573fc
to
24f97cd
Compare
function traverse_data(v: any, buffers: [any, any][]): [Arrayable, any] { | ||
// v is just a regular array of scalars | ||
if (v.length == 0 || !(isObject(v[0]) || isArray(v[0]))) { | ||
return [v, v.length] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bryevdv, is there a reason why we weren't setting shape
to v.length
in this case where v
is an array?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original code that only handled 1d arrays just didn't require it (checked the length directly) So it simply was not added due to lack of necessity. I am not opposed to adding it to make things consistent, but let's make an issue and do that after 1.0 since I can't say with certainty that nothing ever conditions on the presence or absence of shape
to deduce array dimension, and adding it now might beak such paths.
Merging now to get in rc3, more docs/examples to follow |
Adding a new MultiPolygons glyph as outlined here https://github.com/bokeh/bokeh/wiki/Polygons-Patches-with-Holes#new-glyph.
Example: