Leaflet OMS——小叶标记在蜘蛛化后具有不同的堆叠顺序 我们的设置

Leaflet OMS——小叶标记在蜘蛛化后具有不同的堆叠顺序 我们的设置,leaflet,maps,oms,markerspiderfier,Leaflet,Maps,Oms,Markerspiderfier,我们有一个L.map,其中包含了从跨越一个月周期的动态事件数组加载的不同层L.markers。许多列出的场馆在任何给定的时间段内都会举办许多活动,因此我们最终会有许多标记共享位置,这些位置使用我们从CDN运行的OMS传单插件(0.2.6)进行了很好的蜘蛛化 根据一周中的某一天或事件是否已确认/到期,将每个标记放入多个标记层中的一个,例如,以下是一个周末: markerWeekEnd = L.marker([lat, lon], { %options% }); markerWeekEnd.addT

我们有一个L.map,其中包含了从跨越一个月周期的动态事件数组加载的不同层L.markers。许多列出的场馆在任何给定的时间段内都会举办许多活动,因此我们最终会有许多标记共享位置,这些位置使用我们从CDN运行的OMS传单插件(0.2.6)进行了很好的蜘蛛化

根据一周中的某一天或事件是否已确认/到期,将每个标记放入多个标记层中的一个,例如,以下是一个周末:

markerWeekEnd = L.marker([lat, lon], { %options% });
markerWeekEnd.addTo(map);
weekend.addLayer(markerWeekEnd);
oms.addMarker(markerWeekEnd);
我花了一段时间才弄明白如何将标记正确地堆叠起来,以便它们以特定的顺序出现(1.即将出现的标记,2。其他未来日期标记和3。任何过期的标记(如果适用))使用zIndexOffset作为bringToFront()方法不支持L.标记

问题 我们已按要求装载和堆放了所有物品,一切正常,直到我们未设计/蜘蛛侠。当标记重新蜘蛛化时,最终位于顶部的标记不是最初显示的标记

我查看了所有OMS问题,不仅仅是OMS传单(也就是说,谷歌地图API v3的OMS版本),还发现了两个似乎暗示类似问题的已关闭问题:

z-指数重置#117(之前的修复关闭此)

现在,据我所知,这些的相关修复似乎已经应用于OverlappingMarkerSpiderfier/1.0.2/oms.js(我现在想象也是1.0.3),但可能不是OverlappingMarkerSpiderfier传单/0.2.6/oms.js版本

无论如何,我们随后为解决上述问题所做的努力似乎在一定程度上解决了zIndex问题,但并没有克服与OMS spiderfy相关的堆叠问题

我们尝试了什么 决定调整我的标记选项以保留原始的zIndexOffset设置
L.marker([lat,lon],{…zIndexOffset:mIndex,mDay:mDay})
并查看使用保留值重置zIndex是否可以解决我的堆叠问题

// for both spiderfy & unspiderfy
oms.addListener('spiderfy', function(markers) { 
   markers.forEach(function(marker) { zIndexCheck(marker); });
}
function zIndexCheck(marker){
   L.setOptions( marker, { zIndex: mIndex, zIndexOffset: mIndex });
}
不幸的是,尽管在非标准化/蜘蛛化之前和之后似乎保留了标记的zIndex值,但最终保持在顶部的标记不是之前的标记,也不是提供的zIndex计数最高的标记(spiderfy的addListener)

我已经在以下jsfiddle控制台上重新创建了站点功能的精简版本,并在spiderfy前后记录了初始标记的zindex

Marker Title: 'London Socials #1 (1/2)' startTime:ENDED: 1st Feb zIndex:-10
Marker Title: 'London Socials #2 (14/2)' startTime:Fri 14th Feb zIndex:5054 (Active)
Marker Title: 'London Socials #3 (28/2)' startTime:Fri 28th Feb zIndex:2026
#2
最初是活动项

Spiderfy

[London Socials #1 (1/2)]  index:990
[London Socials #2 (14/2)]  index:5027
[London Socials #3 (28/2)]  index:5013
[London Socials #1 (1/2)]  index:990
[London Socials #2 (14/2)]  index:5027
[London Socials #3 (28/2)]  index:5013 (Active)
非标准化

[London Socials #1 (1/2)]  index:990
[London Socials #2 (14/2)]  index:5027
[London Socials #3 (28/2)]  index:5013
[London Socials #1 (1/2)]  index:990
[London Socials #2 (14/2)]  index:5027
[London Socials #3 (28/2)]  index:5013 (Active)
#3
现在是spiderfy/unsiderfy之后的活动项

最终标记元素

<div class="awesome-marker-icon-blue awesome-marker leaflet-zoom-animated leaflet-interactive" 
title="London Socials #2 (14/2)" tabindex="0" style="margin-left: -17px; margin-top: -42px; width: 35px; height: 45px; transform: translate3d(83px, 218px, 0px); 
z-index: 5218;"><i class=" fa fa-moon  icon-white"></i></div>

<div class="awesome-marker-icon-blue awesome-marker leaflet-zoom-animated leaflet-interactive" 
title="London Socials #3 (28/2)" tabindex="0" style="margin-left: -17px; margin-top: -42px; width: 35px; height: 45px; transform: translate3d(83px, 218px, 0px); 
z-index: 5218;"><i class=" fa fa-moon  icon-white"></i></div>

这就是我所能做到的,无法理解之前zIndex较低的第3项(与第2项相比)是如何以一个新的z-index:5218居于首位的,这恰好是第2项相同的新z-index值

​​​ 我在gitHub上发布了一个bug,但现在我不太确定这是OMS传单上的bug。所以我也在这里发布。下面是显示问题的提琴:

​​​ 特定于环境的版本: 传单.js(1.6.0)、传单.awesome-markers(2.0.2)、重叠标记Spiderfier传单(0.2.6)

事实证明,这并不完全是OMS传单上的一个bug,而是一个更大的问题 使用传单以及它如何处理z索引

这是我在上面发现的一条线索的摘录,这条线索在2014年10月2日得到了回答,今天仍然非常相关:


除非有人找到更好的解决方案,否则我会这么做

正如您所注意到的,传单使用像素位置来设置zIndex(在Marker.js中)

我建议使用setZIndexOffset()撤消传单zIndex

假设您想要设置zIndex=100,您可以这样做

var pos = map.latLngToLayerPoint(marker.getLatLng()).round();
marker.setZIndexOffset(100 - pos.y);
有一点小故障:每次缩放地图时都必须这样做。:(
[编辑:在我们的例子中是蜘蛛侠!]

下面是一个注释(注释adjustZindex()中的代码以查看差异)


对于我的OMS Spiderfy案例,通过添加:

function adjustZindex() {
    var markers = oms.getMarkers();
    for (var i = 0, len = markers.length; i < len; i ++) {
      var marker = markers[i];
      var latlng = marker._latlng, mIndexOffset = marker.options.mIndexOffset ;
      var pos = map.latLngToLayerPoint(latlng).round();
      marker.setZIndexOffset(mIndexOffset - pos.y);
    }
  }
  adjustZindex();
因此,我想OMS传单的版本中是否解决了这个问题是无关紧要的,因为它很可能不会解决我们的问题

事实证明,这并不完全是OMS传单上的一个bug,而是一个更大的问题 使用传单以及它如何处理z索引

这是我在上面发现的一条线索的摘录,这条线索在2014年10月2日得到了回答,今天仍然非常相关:


除非有人找到更好的解决方案,否则我会这么做

正如您所注意到的,传单使用像素位置来设置zIndex(在Marker.js中)

我建议使用setZIndexOffset()撤消传单zIndex

假设您想要设置zIndex=100,您可以这样做

var pos = map.latLngToLayerPoint(marker.getLatLng()).round();
marker.setZIndexOffset(100 - pos.y);
有一点小故障:每次缩放地图时都必须这样做。:(
[编辑:在我们的例子中是蜘蛛侠!]

下面是一个注释(注释adjustZindex()中的代码以查看差异)


对于我的OMS Spiderfy案例,通过添加:

function adjustZindex() {
    var markers = oms.getMarkers();
    for (var i = 0, len = markers.length; i < len; i ++) {
      var marker = markers[i];
      var latlng = marker._latlng, mIndexOffset = marker.options.mIndexOffset ;
      var pos = map.latLngToLayerPoint(latlng).round();
      marker.setZIndexOffset(mIndexOffset - pos.y);
    }
  }
  adjustZindex();
因此,我猜OMS传单的版本中是否解决了问题是无关紧要的,因为很可能它不会有问题