-
Notifications
You must be signed in to change notification settings - Fork 593
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
Pass userProperties to midpoints and vertices #964
base: main
Are you sure you want to change the base?
Conversation
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.
LGTM!
@asheemmamoowala thanks for the review, much appreciated! What would be the next steps to get this merged? I can see #944 is also in a similar state. Would be amazing to get these two approved PRs merged if possible as they'd be very beneficial for us and the community at large 😄 |
@kkaefer thanks for merging the other PR. I saw you merged master into this PR, so thanks for keeping this up to date too. Any update on the steps that need to happen to get this merged? :) |
+1 |
Has this PR been put on hold? There has been pull requests for this since 2018 and they always get stuck. Are you waiting for something specific before it can be merged and released? Or is this a feature Mapbox don't want to support? |
+1 |
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.
Thanks for your contributions @JamesLMilner and @drewbo ! This PR is working well on a few small test cases I put together locally, and I agree that having the ability to style midpoints and vertices via userProperties
is a great feature.
However, before moving forward with merging, I believe it's worth considering the performance implications introduced. Since parent.properties
is actually being copied to child vertices and midpoints, the amount of duplicated data associated with each feature can grow quickly as midpoints are "recursively" added between vertices. This likely won't have too much of a negative impact if a relatively small number of userProperties
are introduced. However, since any given GeoJSON feature can have an arbitrary number of user-defined properties
added, performance could be noticeably affected when a large number of midpoints + vertices are combined with many userProperties
.
Perhaps the same result can be achieved by still passing only the parent ID to midpoints and vertices, and then looking up the relevant parent.properties
when needed (i.e. when styling relevant layers). Do you see this approach as a valid solution for your intended use case?
type: Constants.geojsonTypes.FEATURE, | ||
properties: { | ||
...parent.properties, |
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.
It's worth noting that, per MDN's browser compatibility docs, IE does not support spread syntax.
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.
That's a good spot, I think a for ... in
loop might cover it for IE support
Hi @adrianababakanian, thanks for your follow up, really happy to hear you had a chance to test it locally. Performance isn't something I had considered as I'd mostly taken @drewbo code and brought it in line with I am pondering about your suggestion about looking up the parent properties using the ID, and the one thing I'm not sure about is if that would be possible using the Mapbox GL style specification? Maybe an alternative solution is to keep the parent as a reference to the parent object then you could do a |
@adrianababakanian I experimented with using a {
id: 'gl-draw-polygon-and-line-midpoint-halo-parent-prop',
type: 'circle',
filter: [
'all',
['match', ['geometry-type'], 'Point', true, false],
['match', ['get', 'meta'], 'midpoint', true, false],
['match', ['get', 'parentProperties', ['get', 'someParentProp'], true, false]
],
paint: {
'circle-radius': 5,
'circle-color': '#FFF'
}
} You can check it here: Perhaps this would be a more performant approach as we don't copy properties in this instance? |
This approach doesn't allow us to do dynamic style. Mapbox GL style specification doesn't allow to get properties in another geojson. It means that you can't get user's properties in a vertex while they are defined in (a parent) feature (linestring) for example. Copy properties seems the only way |
Would it be feasible to use |
Thanks for looking into this further @JamesLMilner . I agree that trying to make this work with only a reference to the parent ID adds more complexities than just copying the parent's In my opinion, introducing the Feature State API to GL Draw will be beneficial in the long term. Starting to use feature state will involve a larger refactor of GL Draw as a whole, but will bring many additional benefits beyond just the feature in this PR. I opened #994 to start a discussion around a few of these benefits. Using feature state would enable giving child features (i.e. midpoints and vertices) the same |
Is it correct to assume this same issue exists with 'Points' also? I'm trying to use: |
One year later... Can we merge this and add a warning in the md that adding a larger number of properties could introduce performance problems, especially with complicated shapes that render many midpoints and vertices? Not being able to style midpoints and vertices is holding us back. |
@adrianababakanian Can you please merge this PR? |
@adrianababakanian @asheemmamoowala Need this PR for my project as well 🙏 Could you merge and release it please ? |
@adrianababakanian @asheemmamoowala This PR would also be very useful for my project ! 🤩 |
This would be amazing for us as well |
This PR brings @drewbo PR for this issue (#847) up to speed with master. The aim here is to pass userProperties to midpoints and vertices, and in turn allow them to be styled.
Resolves #846