Background: The company has a new requirement for Leaflet maps, as follows: The data returned by the back end is an array of objects, and each object may be a point, line, circle or area, which is rendered on the map through type differentiation. At the same time, zIndex is used to determine the level of each item

The process of finding information

1. It was quite easy when I first received this requirement, because I had seen that the zIndexOffset attribute could set the hierarchy in the configuration item of marker, but later I found that this attribute did not exist in polyline and other contents. Searching the scheme of polyline setting hierarchy on the Internet, I found that layerGroup was mostly used to wrap it, and layerGroup set zIndex scheme. So we decided to use marker zIndexOffse and Polyline layerGroup. The good times did not last long. In the actual use process, I found that it did not have the effect I imagined, and did not play the effect of hierarchical coverage. Give up!

2. When I searched for the problem in Github, I found two methods

BringToFront: Places this element above other Windows

BringToBack: Place this element below other Windows

It was not possible to set a hierarchy, but it gave me inspiration in subsequent solutions

To solve

1. Polylines, circle, the implementation of the geoJson level

Through git members’ interpretation of SVG’s lack of zIndex support and monitoring of Element, the hierarchy of the three is determined by who renders first. The first render is at the bottom and the last render is at the top. So the problem has already started to be solved, i.e. the back end will sort the returned data, and the one with the low zIndex will be added to the map first (render first)

The path rendered first is at the bottom

2. Implementation of marker level

The marker implementation was supposed to be the simplest, adding zIndexOffse, but the result was disappointing. When the icon size is large to a certain extent, the imaginary marker at the bottom is on the top, so the realization of zIndex of marker is studied

It was found that this value was used, and the guess was that fixed values such as zIndex: 1,2,3 of a certain marker could not be specified, but this practice did not take into account the overlapping of large icon markers. That is, the zIndex closer to the top of the window is smaller, and the zIndex closer to the bottom of the window is larger. Then, when the size of two markers both have window size, the one closer to the bottom of the window will be displayed, because its zIndex is larger.

At this point I set zIndexOffse to 1,2,3

ZIndex corresponds to 1,2,3. However, it is still useless for the previous problem, that is, if the marker is large enough, only the ones near the bottom will be displayed. Of course, this problem usually does not exist, after all, markers are usually not that large.

This problem bothered me for some time, during which I carried out a series of calculations for coordinates, Z-index and icon width and height. Finally, a more secure scheme was obtained.

Assuming that the largest markerA is 60px wide or high, its radius is 30px. In this case, any marker within 30px of it is overlapped. Suppose there is A markerB that happens to be 30px from it, then their transform distances are 400(B) and 430(A). Why is B at 400? Because this is the most extreme case of the design. The congenital condition zIndex of B is smaller than that of A, but the final result of B is larger than that of A.

So B is now returning me zIndex 1 from the back end, and A is 0. The formula I came up with is (radius times zIndex) the level set for zIndexOffse. B is now 400+(30 * 1)=430,A is 430+(30 * 0)=430; But it’s kind of the same hierarchy. Yes, but this is an extreme case. This result occurs only if the distance is just 30 and the zIndex of the two points is adjacent. There will be support for cracking this situation later (don’t necessarily remember to post on the blog).

The final formula is zero

LeafletMarker. SetZIndexOffset (zIndex * radius)Copy the code