Pull to refresh
216
0
Владимир Агафонкин @Mourner

User

Send message
А какими местами слишком легковесный, чего явно не хватает?
У Leaflet есть одно неоспоримое преимущество, которое Яндексу будет трудно преодолеть: открытый исходный код и open-source-сообщество.
А я уже скучаю по недавней первоапрельской котозаменялке. :)
Учитывая, что автор Mapnik теперь в команде MapBox, думаю, что скоро и без TileMill будет просто засетапить. :)
А вот event-driven системе при отсутствии необходимости пить стакан с водой не понадобится.
iBooks, там есть настройка яркости.
При чтении других штук (например RSS или Instapaper) меняю яркость самого айпада в «быстрых» настройках, которые выплывают при жесте 4-мя пальцами вверх.
У меня есть и iPad, и Kindle, и при чтении с первого страшным образом устают глаза, даже при низкой яркости. Так же, как и при продолжительном чтении большого кол-ва текста с монитора. В течении рабочего дня постоянно приходится отвлекаться, чтобы отдохнули глаза — пойти попить чайку, поиграть в настольный теннис, просто пройтись туда-сюда, позвонить кому-то, да и за монитором — отвлечься на какие-то картинки, что-то, на чём не нужно так концентрировать зрение, и т.д… А вот читать с Киндла ну очень комфортно при достаточном освещении, и делать это можно часами непрерывно.
А еще в Эклипсе совершенно ужасная поддержка JavaScript. Я ей пользовался много лет, терпел, но после очередной их выходки в новой версии с неотключаемой подсветкой ошибок несоответствия типов, которые во многих случаях не ошибки вовсе, начал пользоваться WebStorm и с тех пор Eclipse не запускал даже ни разу.
Я в своём Leaflet сейчас использую jake — аналог rake под node.js. Очень просто, удобно, и к тому же приятно описывать билд-скрипты и зависимости для JS-проекта на JS же, без лишних сторонних языков.
Не реализовывал до этого времени такую возможность, т.к. не знал, что она востребована. Теперь буду знать, спасибо. :)
Спасибо за анонс!

Как автор библиотеки, буду рад в комментариях ответить на любые вопросы о ней. :)
Добавил возможность включения режима максимального качества, при котором дрожания нет (можете посмотреть и сравнить потери точности с потерями производительности): mourner.github.com/simplify-js/
Даже при самопересечении не могу придумать случая, когда алгоритм себя плохо поведёт. :) В случае совпадения первой и последней он поведёт себя правильно засчёт того, что расстояние рассчитывается не к прямой, а к отрезку — если перпендикуляр на него не попадает, то берётся меньшее из двух расстояний к краям.
Почему неверную? Можно самый простой тест-кейс, в котором неправильно срабатывает? По моему опыту, отлично работает и на полигонах.
Я понял, о чём вы говорите. Но это имеет практическую пользу только в случае, если у нас есть в распоряжении громадное количество вычислительного времени, чтобы провести упрощение без предварительного отсеивания точек с минимальным порогом. Там, где нужна быстрая обработка в реальном времени, такой подход не работает.
Думаю, что полигоны и полилайны с KML/YML в Google/Яндекс-картах упрощаются на каждом зуме отдельно — массив точек с минимальным зумом вычисляются не одним общим алгоритмом, а запуском обычного 19-20 раз с разными наборами спроецированных точек.

Общим алгоритмом можно вычислять только в том случае, если он является алгоритмом локальной обработки, т.е. отклонение в каждой точке меряется относительно фиксированных других (например, соседней левой и правой) и не зависит от предыдущих итераций. Но такие алгоритмы, хоть и линейные, насколько я понял из прочитанного в этой научной работе (pdf), очень неточные и производят множество артефактов в разных крайних случаях.

Зато за счёт того, что вы натолкнули меня на более подробное изучение вопроса, нашёл еще два интересных алгоритма — Лэнга и Жао-Сэлфелда, которые обязательно попробую.
Хороший вопрос… Если речь идёт об упрощении перед отображением на экране, то при не очень большом пороге разницей на стыках можно пренебречь — ее не будет видно. А вот если серьёзно подходить к вопросу, нужно придумывать алгоритм…

Мне представляется следующий — перебрать каждую точку каждого полигона, храня хэш с ключём по координатам и значением — кол-вом раз, которые точка встретилась. Потом пройтись по каждому полигону и при каждом изменении кол-ва в точке разбивать в этом месте полигон на части (скажем, первые 100 точек встречаются один раз, потом вдруг пошли точки по 2 — разбить на стыке). Потом упрощаем каждую «часть» каждого полигона. Алгоритм упрощения на одинаковых частях будет работать одинаково.
Мне тоже мат. опыта не хватало, но, к счастью, Гугл многое знает по запросу «polyline simplification». :)
Насчёт округления — во-первых, каким образом округление координат ускорит алгоритм? Проходить по всем точкам с O(n) для отсеивания нужно и в одном, и в другом случае, только вместо проверки dx * dx + dy * dy > tolerance (как делается сейчас) будет round(dx) === 0 && round(dy) === 0 (и даже не факт, что с округлением не будет медленнее).

Во-вторых, вершины-то схлопнутся в одну точку, а вот рёбра будут рисоваться по-разному — можете сами проверить на канвасе. От дробной части координат зависит, как будет работать антиалиасинг ребра. И на моём демо это хорошо видно — проследите за тем, как меняется вид кривой в диапазоне tolerance до 1 пикселя.

Насчёт второго этапа — буду очень удивлён, если действительно можно рассчитать такую независимую от порога меру и вы сможете описать такой расчёт. Мне это кажется невозможным, т.к. каждая итерация алгоритма Дугласа-Пекера зависит от выбора точек в предыдущих.

Что касается вашего примера — к сожалению не могу оценить, насколько эффект хорош, т.к. ссылка на демо нерабочая (404). А это вами придуманный алгоритм или есть какая-то статья, его описывающая, с примерами и сравнением? Было бы здорово почитать.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity