OMS - маркеры листовки имеют другой порядок стеков после spiderfy - PullRequest
Новая
       48

OMS - маркеры листовки имеют другой порядок стеков после spiderfy

1 голос
/ 14 февраля 2020

наша установка

У нас есть L.map с различными слоями L. markers , загружаемыми из динамического c массива событий, охватывающих месячный период , Многие из перечисленных объектов проводят многочисленные мероприятия в течение любого заданного периода, и, следовательно, мы получаем многочисленные маркеры, разделяющие местоположения, которые очень хорошо паукованы с помощью плагина OMS-Leaflet (0.2.6) , который мы запускаем из CDN

Каждый маркер помещается в один из нескольких слоев маркера в зависимости от дня недели или от того, было ли событие подтверждено / истекает, например, вот тот, который выпадает на выходные: 

markerWeekEnd = L.marker([lat, lon], { %options% });
markerWeekEnd.addTo(map);
weekend.addLayer(markerWeekEnd);
oms.addMarker(markerWeekEnd);

Это заняло у меня некоторое время, чтобы выяснить, как правильно расположить маркеры , чтобы они отображались в определенном порядке ( 1. будущие маркеры, 2 . другие будущие маркеры даты и 3 . любые маркеры с истекшим сроком действия, если применимо) с использованием zIndexOffset в качестве метода yieldToFront () не поддерживает L.markers.

выпуск

У нас все загружается и укладывается как требуется, и все работает нормально, пока we unspiderfy / spiderfy . Когда маркеры повторно паукообразуются , то, что заканчивается сверху, не отображается изначально .

Я рассмотрел все проблемы с OMS, а не только OMS- Листовка (т. Е. Также версия OMS для API Карт Google v3 ) и обнаружение нескольких закрытых, которые, по-видимому, предлагают аналогичную проблему:

OMS следует запомнить оригинальный zIndex маркера # 76 сброс z-индексов # 117 (предыдущее исправление закрывает это)

Теперь, насколько я могу судить, связанное исправление для них, похоже, применено к OverlappingMarkerSpiderfier / 1.0.2 / ом. js (также, сейчас я представляю 1.0.3), но, возможно, не OverlappingMarkerSpiderfier-Leaflet / 0.2.6 / ом. 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 для маркеров до и после unspiderfy / spiderfy , возможный маркер, который остается сверху, это , а не тот, который был там до , или , с самым высоким предоставленным счетчиком zIndex ( addListener for spiderfy).

Я заново создал урезанную версию функциональности наших сайтов на следующей консоли jsfiddle и , в которой zIndexes исходных маркеров ранее регистрировался и после паука: 

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

UnSpiderfy 

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

#3 теперь активный элемент после spiderfy / unspiderfy (см. заключительные элементы ниже)

конечный элемент маркера 

<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>

И это насколько я дошел до не может понять, как элементу 3 с ранее более низким zIndex (по сравнению с пунктом 2) удалось оказаться на вершине с новым z-index: 5218 которое, как оказалось, является таким же новым значением z-index , что и для item 2 !

Я опубликовал это как ошибку на gitHub, но теперь я не уверен, что это ошибка с OMS-Leaflet. Так что выкладываю здесь тоже. Вот скрипка, показывающая проблемы:

https://jsfiddle.net/magicmb/17j2z4gy/

Спецификации среды c версии: leaflet. js (1.6.0), Leaflet .awesome-маркеры (2.0.2), листовка с надписьюMarkerSpiderfier-Leaflet (0.2.6)

1 Ответ

0 голосов
/ 14 февраля 2020

Оказывается, это не совсем ошибка с OMS-Leaflet, а скорее проблема с Leaflet и его обработкой по z-индексам

Вот выдержка из нить, которую я обнаружил на gis.stackexchange , на которую YaFred еще 2 октября 1414 года ответил * 10000 * и все еще очень актуален сегодня:

Пока кто-то находит лучшее решение, вот что я бы сделал ...

Как вы заметили, листовка использует положение пикселя для установки zIndex (в маркере. js) 

pos = this._map._latLngToNewLayerPoint(this._latlng, opt.zoom, opt.center).round();
this._zIndex = pos.y + this.options.zIndexOffset;

Что я Предлагаем отменить листовку zIndex с помощью setZIndexOffset ()

Скажем, вы хотите установить zIndex = 100, вы бы сделали 

var pos = map.latLngToLayerPoint(marker.getLatLng()).round();
marker.setZIndexOffset(100 - pos.y);

Есть небольшая ошибка : вам нужно делать это каждый раз при увеличении карты :( [EDIT: Spiderfied in our case!]

Вот пример JSFiddle (прокомментируйте код в 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();

и затем вызову AdjustZindex () из моих слушателей spiderfy 

oms.addListener('spiderfy', function(markers) {
    layersBring2Front(); 
    adjustZindex();
  });

Так что я думаю, должен ли OMS запомнить исходный zIndex маркера # 76 , который был разрешен в версии OMS Листовка не имеет никакого значения, так как, по всей вероятности, она не решила бы нашу проблему.

...