Решение для "переполненных" мест на карте #462
Replies: 8 comments 9 replies
-
|
Эта идея, естественно, не отменяет и на заменяет необходимости замены версий #75 , но может как-то пересекаться с задачей поддержки "вариантов" (ранее не специфицировалась). Также (косвенно) м.б. связанно с задачей - #164 (Дополнительная типизация изображений) |
Beta Was this translation helpful? Give feedback.
-
|
@anvaruk предлагает "просто увеличить зум". Подход, подкупающий своей простотой. То есть я обеими руками "за" увеличить зум ;) Но это не решение. |
Beta Was this translation helpful? Give feedback.
-
|
Ещё одноо дополнение от @anvaruk - не только "жесткое" изменение статуса модератором, но и через инструмент "рейтинга" (лайки/дизлайки, причем с разным "весом", в зависимости о статуса и стажа/вклада участника). |
Beta Was this translation helpful? Give feedback.
-
|
Я бы предложил ограничивать количество точек на карте:
В дополнение, как предлагает @anvaruk - включаем зум до 22 (с незначительным размытием плиток карты ввиду интерполяции). |
Beta Was this translation helpful? Give feedback.
-
|
Это идет вразрез с применяемой сейчас технологией "объединения в кластеры".
По факту, это не позволит использовать никакие зумы кроме максимальных.
Повторюсь, проблема не в зуме, а в том, что в принципе далеко не все
снимки, которые есть на сайте, всегда и всем нужно видеть на карте (но и
удалять их тоже нет оснований).
Где-то это не критично, а где-то - уже да.
пн, 14 февр. 2022 г. в 22:59, Ruslan Kabalin ***@***.***>:
… Я бы предложил ограничивать количество точек на карте:
1. Ставим лимит на количество показанных снимков на единицу площади
карты (подобрать так, чтобы количество не затрудняло навигацию).
2. Если в базе количество изображений превышает лимит - появляется
уведомление о том, что показаны не все снимки из имеющихся для данного
фрагмента карты, предлагающее пользователю уточнить временной период для
показа всех изображений или увеличить зум. Уведомление убирается в момент
когда количество снимков с учетом фильтра становится ниже лимита.
В дополнение, как предлагает @anvaruk <https://github.com/anvaruk> -
включаем зум до 22 (с незначительным размытием плиток карты ввиду
интерполяции).
|
Beta Was this translation helpful? Give feedback.
-
Кластеры останутся как есть. Я о лимите показываемых фотографий, который вполне может решить проблему "переполненных" территорий на мой взгляд.
Решение с "дополнительными" снимками действительно на какое-то время уменьшит число показываемых фотографий популярных мест, но, как мне кажется, фундаментально проблему не решит, просто с ростом числа загрузок в критерий "дополнительные" начнут попадать те, что прежде бы считались "основными". На самом деле все предложенные решения могут решить проблему большой плотности в той или иной мере. Мы можем исходить из того, как проще ее решить уже сейчас. Зум и лимит точек не сложно добавить. Разделение на "основные" и "дополнительные" - идея хорошая, но реализация потребует больше времени. |
Beta Was this translation helpful? Give feedback.
-
Кто-то из нас не догоняет ;) Или такие (16): Что будет происходить в случае реализации твоего предложения? В какой именно момент "появляется уведомление о том, что показаны не все снимки из имеющихся для данного фрагмента карты"? |
Beta Was this translation helpful? Give feedback.
-
Когда плотность точек (а возможно и кластеры тоже можно считать за точку на карте, так как они влияют на загруженность карты) будет черезмерная, как например тут: К примеру, пользователь ставит фильтр 1970-1980, новый результат не требует ограничений, навигация более не затруднена: Оценивать плотность стоит от зума 17 и выше (когда в ответе сервера появляются отдельные фото). На самом деле все немного сложнее, ведь запрос не может гарантировать равномерное распределение расстояния между точками в ответе, поэтому рассчет необходимости лимитирования и скрытие избыточных точек нужно будет делать уже на стороне клиента, когда получен ответ. |
Beta Was this translation helpful? Give feedback.
-
Мне кажется, что это не решает никакую реальную проблему, при этом создает для пользователя новые искусственные ограничения. Реальная проблема в том, что по умолчанию части точек на карте быть вообще не нужно, ни при каких фильтрах. В общем, в виде дополнения к моему варианту, это всё годится. Но не как самостоятельное решение. Частичным решением, кстати, был бы фильтр по направлениям, в дополнение к фильтру по датам - #240. Вот это было бы мегаудобно. |
Beta Was this translation helpful? Give feedback.
-
|
И главное - ты преложил "ограничивать количество точек на карте". А какие, собственного говоря, точки будут показаны-то? Какие именно? По какому принципу движок их отберет? |
Beta Was this translation helpful? Give feedback.
-
|
Я вообще думал случайно выбирать, но можно рассмотреть идеи принципа выборки, если дойдет до реализации. |
Beta Was this translation helpful? Give feedback.
-
|
Не, давай лучше не будем в эту сторону двигаться... Нас распнут за "случайную выборку". И за любую другую тоже. |
Beta Was this translation helpful? Give feedback.
-
|
Я посмотрел более внимательно - при больших значениях зума (>=17 aka localWork) кластеры формируются на стороне клиента. Может быть перенастроить функцию так, чтобы большее число точек попадало в кластеры, тем самым уменьшить насыщенность точек для данного значения зума? Критерием может быть любое соприкосновение изображений точек. Чтобы проиллюстрировать, на фрагменте стрелками показано где должен быть кластер (там больше соприкосновений, я не все показал, но идея я думаю понятна).
|
Beta Was this translation helpful? Give feedback.
-
|
Да, так будет лучше - вместе с добавлением уровней зума до 22 это мягко принудит пользователей увеличивать зум для плотно забитых локаций. Это не решение проблемы как таковой, но улучшение UX. Раз это на клиенте, то, думаю, стоит это просто сделать (в той же задаче, что и расширение шкалы зума). |
Beta Was this translation helpful? Give feedback.
-
|
Отдельный вариант решения проблемы для карты в режиме показа фотографии. Может быть временной диапазон на боковой карте по умолчанию ставить равным текущей датировки фотографии (или диапазону +-N лет от датировки), таким образом число точек значительно снизится. Может даже показаться удобнее - заинтересовал, скажем, меня снимок 50-х годов, я его открыл и все соседние точки на карте тоже отражают этот же период. |
Beta Was this translation helpful? Give feedback.
-
|
Согласен. Стоит вынести это в отдельную задачу. Я считаю разумным диапазон +/- 10 лет (т.е. для снимка 1955 года это будет 1945-1965). Но это лучше вынести в отдельную настройку, чтобы пользователь мог сам для себя выбрать этот дефолтный интервал (причем отдельно "назад", и отдельно "вперед"). |
Beta Was this translation helpful? Give feedback.
-
|
(Ремарка; боковую карту в режиме показа фотографии мы вроде бы решили называть "мини-картой". Предлагаю придерживаться этого термина) |
Beta Was this translation helpful? Give feedback.
-
Предлагаю обсудить здесь возможные технические пути решения проблемы "переполненных" фотографиями точек на карте (типа Красной площади в Москве и других подобных мест) . Пример, актуальный для большинства крупных и мелких городов б. СССР - однотипные фотографии демонстраций.
Когда проектировался сайт, эта задача, вероятно, считалась не самой приоритетной. Однако за минувшие годы она назрела, созрела, и, кажется, даже перезрела.
Никакими орг.вопросами (заменять/не заменять, удалять/оставлять варианты, что публиковать, что отклонять) эта проблема полностью не решается. Но для той же Красной площади, даже если удалить все дубли и варианты, число снимков на квадратный метр всё равно окажется чрезмерно большим. И оно всё время будет расти. Попытки сдерживать этот напор, просто не публикуя все фото, которые кажутся не несущими ничего нового, дает только временную передышку, и только в одном месте.
Нужно именно техническое решение, которое позволит всем относительно спокойно в этой ситуации существовать.
Моя идея такова:
Ввести новый статус изображений - "дополнительное".
В момент публикации модератор может выбрать, публиковать изображение как "основное" или как "дополнительное".
Модератор в любой момент может переводить изображения из статуса "основное" в статус "дополнительное" и обратно. Это отражается в истории снимка.
Текущий статус "опубликовано" по-прежнему остается основным статусом публичных изображений, и присваивается по умолчанию.
На карту добавить новый переключатель - "показать дополнительные изображения" (или короче, - "показать все").
5.1. По умолчанию он выключен, при этом дополнительные изображения на карте не отображаются - по умолчанию отображается "основной" слой.
5.2. При включенной опции "показать все", кроме "основных" на карте отображаются ещё и точки "дополнительных" изображений. Опции "показ только дополнительных" я не предполагал - считаю нецелесообразным.
5.3. Переключатель активен (доступен для выбора), только если на отображаемой части карты есть хотя бы одно изображение в статусе "дополнительного".
5.4. Этот же переключатель добавляется в фильтр галерей.
Под мини-картой, где сейчас мини-галерея "Ближайшие изображения", добавляется ещё одна галерея "Дополнительные изображения"
Если у кого-то есть другие идеи, предлагайте их прямо здесь, или на ГитХабе - где кому удобнее. Через неделю примерно я вынесу какой-то набор вариантов уже для публичного обсуждения.
Дополнения:
7. не только "жесткое" изменение статуса модератором, но и через инструмент "рейтинга" (лайки/дизлайки, причем с разным "весом", в зависимости о статуса и стажа/вклада участника).
Beta Was this translation helpful? Give feedback.
All reactions