Multiple markers with one icon#2068
Conversation
|
Looks good to me. |
| # this makes sure it is added only once | ||
| self._parent.add_child(icon, name=icon.get_name(), index=0) | ||
| self.icon = icon | ||
| self.add_child(icon) |
There was a problem hiding this comment.
Why did the above code not work?
There was a problem hiding this comment.
It worked I think, but it's not necessary. Figure.script is an OrderedDict, so we are already guaranteed that multiple renders of the same Icon object will result in only one entry in Figure.script.
- Multiple markers may now have the same Icon object as child.
- In the first rendering pass, of
MacroElement.render, that one Icon object is rendered multiple times - Those multiple renders are added to
Figure.scriptwith the Icon object name as key. So each render overwrites the previous one, and the result is the Icon object appears in the final output only once.
| raise ValueError( | ||
| f"{self._name} location must be assigned when added directly to map." | ||
| ) | ||
| for child in list(self._children.values()): |
There was a problem hiding this comment.
This looks strange to me. A marker can have only one Icon, correct? Why do we need to look through all the children? Would it not be easier to use self.icon?
There was a problem hiding this comment.
Would it not be easier to use self.icon?
That would not work for the case where the icon is added using marker.add_child(icon) or icon.add_to(marker).
By looking through the children, we catch the icon whichever way it was added.
|
In general I have no objections, but I do have two comments that you may want to look at. |
|
Thanks for the review! I replied to your comments, let me know if you have further questions or suggestions! |
#2084 is caused by this as per commit history. So this is indeed a breaking change, at least for geopandas. |
Based on the comments on #2053 I made a new version that sets the icon from the markers perspective. This is also similar to how
Layerworks.Tested it with this case:
If this approach looks good, I'll generate some test cases.
Not sure how much of a breaking change this is. From a direct user perspective, I don't think there's an issue. Not sure about packages that use Folium internals though.