Комментарии 11
Молодцы. Интересно и полезно.
Особо не к чему даже придраться, кроме ненужных закрывающих ?> пхп тегов :)
Особо не к чему даже придраться, кроме ненужных закрывающих ?> пхп тегов :)
Очень круто. Понравилась реализация «подкластеров», когда после клика на круговой кластер, открываются его дочерние «подкластеры» и анимированный маркер с лейблом на ховер, все аккуратно и красиво.
Не приходили в голову варианты: а) позволить пользователю самому выбрать для интересующего его города картографическую основу из списка, б) для отдельных городов, где у google карта оставляет желать, использовать на детальных масштабах карту других сервисов?
Ну и баг-репорт: FF13 win32, при большой скученности групповых маркеров детали нижележащих могут перекрывать детали вышележащих. А при наведении курсора на нижележащий одиночный маркер, находящийся под групповым, «всплывает» только его правая часть, левая так и остается частично скрыта вышележащим. z-индексы стоит присваивать всему маркеру, а не частям.
Ну и баг-репорт: FF13 win32, при большой скученности групповых маркеров детали нижележащих могут перекрывать детали вышележащих. А при наведении курсора на нижележащий одиночный маркер, находящийся под групповым, «всплывает» только его правая часть, левая так и остается частично скрыта вышележащим. z-индексы стоит присваивать всему маркеру, а не частям.
Оба варианта приходили в голову. Если память не изменяет, альтергео в один момент пошел по первому пути.
Мы рассуждали вот как:
Сорри. Не привык, что по «Enter», сохраняется коммент и его нельзя отредактировать:)
Итак, мы рассуждали вот как:
1. Конечно, классно иметь разные карты, между которыми можно переключаться;
2. Переключение лучше делать автоматом, чтобы пользователь не задумывался ни о чем особенно;
3. Это может иметь обратный эффект: например инициализация карты занимает несколько секунд, а при частом переключении между картами, это может убить кое-какие браузеры (показывать пальцем на IE не буду);
Ну и есть тех. вопрос: как оценить, на сколько хорошо прорисован населенный пункт? На первый взгляд, приходит в голову только одно: определять, какой максимальный зум доступен для центра этого города. Если не большой, то карта плохо прорисована.
Хотя, тот же Мадрид на Яндексе: зум максимальный, улицы есть, домов нет вообще:)
Про баг большое спасибо! «Мы уже в курсе и занимаемся этим»:)
Проблема в том, что гугловский движок карт размещает маркеры в одном div-е (и вообще canvas-ом), а все overlay-и — в другом. Как я писал в посте, мы используем MarkerWithLabel, который размещается на карту как overlay.
Тут вообще отдельная история про то, какие z-index давать маркерам. В нашем случае z-index — это функция от координаты Y на карте.
Кстати, о проблеме, которая возникла по ходу, и мы ее пока не смогли решить: эти overlay-и иногда отстают от самого маркера на +-1 пиксель по oX или oY. Т.е. при попытке широту и долготу перевести в координаты этого конкретного view карты, возникают небольшие погрешности.
Итак, мы рассуждали вот как:
1. Конечно, классно иметь разные карты, между которыми можно переключаться;
2. Переключение лучше делать автоматом, чтобы пользователь не задумывался ни о чем особенно;
3. Это может иметь обратный эффект: например инициализация карты занимает несколько секунд, а при частом переключении между картами, это может убить кое-какие браузеры (показывать пальцем на IE не буду);
Ну и есть тех. вопрос: как оценить, на сколько хорошо прорисован населенный пункт? На первый взгляд, приходит в голову только одно: определять, какой максимальный зум доступен для центра этого города. Если не большой, то карта плохо прорисована.
Хотя, тот же Мадрид на Яндексе: зум максимальный, улицы есть, домов нет вообще:)
Про баг большое спасибо! «Мы уже в курсе и занимаемся этим»:)
Проблема в том, что гугловский движок карт размещает маркеры в одном div-е (и вообще canvas-ом), а все overlay-и — в другом. Как я писал в посте, мы используем MarkerWithLabel, который размещается на карту как overlay.
Тут вообще отдельная история про то, какие z-index давать маркерам. В нашем случае z-index — это функция от координаты Y на карте.
Кстати, о проблеме, которая возникла по ходу, и мы ее пока не смогли решить: эти overlay-и иногда отстают от самого маркера на +-1 пиксель по oX или oY. Т.е. при попытке широту и долготу перевести в координаты этого конкретного view карты, возникают небольшие погрешности.
Ну и есть тех. вопрос: как оценить, на сколько хорошо прорисован населенный пункт? На первый взгляд, приходит в голову только одно: определять, какой максимальный зум доступен для центра этого города. Если не большой, то карта плохо прорисована.
Вот потому я и говорил о том, чтобы позволить пользователю делать выбор самому. Метод по zoom level — негодный совершенно. Более того, даже подробность не всегда означает качество. Карта может быть устаревшей, «фантастической» и так далее. Оценить можно только визуальным сравнением. При том, могу сказать, что ситуация с качеством может меняться как в лучшую, так и в худшую сторону (скажем, тот же Гугл после смены поставщика основы может получить куда более поганую в реальности карту).
С маркерами — да, понимаю, сочувствую (с gmaps api знаком хуже, чем с OL).
Вот потому я и говорил о том, чтобы позволить пользователю делать выбор самому. Метод по zoom level — негодный совершенно. Более того, даже подробность не всегда означает качество. Карта может быть устаревшей, «фантастической» и так далее. Оценить можно только визуальным сравнением. При том, могу сказать, что ситуация с качеством может меняться как в лучшую, так и в худшую сторону (скажем, тот же Гугл после смены поставщика основы может получить куда более поганую в реальности карту).
С маркерами — да, понимаю, сочувствую (с gmaps api знаком хуже, чем с OL).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы делали картографические сервисы