• Новая Украина на Яндекс.Картах
    0
    Простите, ложная тревога. :) У страницы был немного увеличен масштаб, сбросил и стало хорошо.
  • Новая Украина на Яндекс.Картах
    0
    JS-движок тоже наверное обновили? Почему-то карта у меня начала заметно тормозить (Firefox и Chrome под Windows 7). Раньше паннинг и зуминг работал на порядок плавнее.
  • Отчет о UA Web Challenge 2012
    +2
    Отличное получилось мероприятие! И воодушевляющее — много талантливых ребят среди участников.
    Выступал в роли жюри в номинации Front-End, думаю написать на Хабр статью о самых распространённых ошибках.
  • Kickstarter — это способ избежать финансовых рисков и не отдавать долю в своем проекте
    0
    "$7500 на запись альбома русского виолончелиста" — не виолончелиста, скрипача. :)
  • Болee 40 онлайн-курсов от Coursera и Udacity
    0
    Такое же ощущение от курсов MIT. Очень хорошо проделанная работа.
  • TodoMVC — «Hello, world» на стероидах
    0
    На то это и open source, чтобы в итоге получить идеальную и идентичную реализацию всех вариантов.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Вижу. А в чём именно проблема? В том, что Sutherland-Hodgeman вот такую самопересекающуюся белиберду плохо обрезает?
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Достаточно хорошо представляю — редактор графики появится в след. версии, пока реализован редактор полилайнов/полигонов, в несжатом виде 5кб. С кругами/прямоугольниками, возможностью перетаскивания и поворота будет больше, но появится достаточно скоро (скорей всего выделенное в отдельный плагин).

    Активные области — опять же эта штука service-specific, но вот, к примеру, есть надстройка поверх Leaflet от GisCloud, умеющая отображать миллионы интерактивных точек на карте.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Спасибо, записался, приду!
    А учитывать абсолютно всё для всех я считаю крайностью и пустой тратой ресурсов. Может, для Яндекса она оправдана, но Leaflet рассчитан на разработчиков с хотя бы минимальным уровнем сознательности. :)
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    max-width — единственный момент, который я позволил себе исправить с помощью !important и считаю это хорошим оправданным решением. А вот для всех дивов и картинок паддинги с марджинами устанавливать — это уже идиотизм какой-то, пускай разработчики сами исправляют, тем более что проблема в отличии от max-width лежит на поверхности.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Разъясни, пожалуйста. А еще лучше тест-кейс на jsfiddle.net/ — пока по этому поводу не жаловались.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Кстати, а зачем вызывать одни и те же методы по два раза?
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Насчёт сборки под конкретный браузер — в Leaflet'е кода с браузерными костылями от силы наберётся пару килобайт. Так что тоже несущественно.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Ты уверен насчёт алгоритмов? Cohen-Sutherland — это алгоритм для клиппинга сегментов, Leaflet его тоже использует. Sutherland-Hodgeman — для полигонов. Никаких проблем с многоконтурными полигонами нет.

    Насчёт краткости — она, как говорится, сестра таланта. :) Больше напильников — не значит умнее.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Кстати, спасибо за ссылку на Leaflet в первом комментарии — всегда рад куче трафика с Хабра. :)
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    В данном случае сложная архитектура с динамическими модулями нецелесообразна, т.к. в случае необходимости можно легко сделать статический билд с нужными компонентами и загрузить его весь сразу. Хотя на практике даже такой необходимости не возникает — весь запакованный JS-код Leaflet на данный момент занимает 22кб.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Я бы не сказал. Просто Leaflet — это только JS-библиотека (и сервисы к ней выбираются отдельно по вкусу — CloudMade, Mapbox, MapQuest, Bing, etc.), а API Яндекс.Карт — это JS-библиотека + сервисы в одном флаконе. Но если говорить только о библиотеках — они вполне сравнимы.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Но библиотеки для карт среди них всё-таки нет. :)
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    OSM-тайлы от MapQuest, кстати, без ограничений.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    Вообще-то да, как-то бедненько как для такой большой серьёзной компании. :)

    И открытый исходный код я имел в виду в широком смысле, а не прямом. Открытый для contribution'ов.
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    А какими местами слишком легковесный, чего явно не хватает?
  • JavaScript API Яндекс.Карт — версия 2.0
    0
    У Leaflet есть одно неоспоримое преимущество, которое Яндексу будет трудно преодолеть: открытый исходный код и open-source-сообщество.
  • Есть ли жизнь без AdBlock: а у вас стоит баннерорезка?
    0
    А я уже скучаю по недавней первоапрельской котозаменялке. :)
  • OpenStreetMap News №13: foursquare и скорая помощь используют OSM, OSM представлен в парламенте Франции, ЕС рекомендует OSM, новые спутниковые снимки, создан Совет Российского OSM
    0
    Значит не долго осталось ждать :)
  • OpenStreetMap News №13: foursquare и скорая помощь используют OSM, OSM представлен в парламенте Франции, ЕС рекомендует OSM, новые спутниковые снимки, создан Совет Российского OSM
    0
    Учитывая, что автор Mapnik теперь в команде MapBox, думаю, что скоро и без TileMill будет просто засетапить. :)
  • Психологическая деформация программистов. Взгляд с обеих сторон баррикад
    0
    А вот event-driven системе при отсутствии необходимости пить стакан с водой не понадобится.
  • eInk: польза или вред?
    0
    iBooks, там есть настройка яркости.
    При чтении других штук (например RSS или Instapaper) меняю яркость самого айпада в «быстрых» настройках, которые выплывают при жесте 4-мя пальцами вверх.
  • eInk: польза или вред?
    0
    У меня есть и iPad, и Kindle, и при чтении с первого страшным образом устают глаза, даже при низкой яркости. Так же, как и при продолжительном чтении большого кол-ва текста с монитора. В течении рабочего дня постоянно приходится отвлекаться, чтобы отдохнули глаза — пойти попить чайку, поиграть в настольный теннис, просто пройтись туда-сюда, позвонить кому-то, да и за монитором — отвлечься на какие-то картинки, что-то, на чём не нужно так концентрировать зрение, и т.д… А вот читать с Киндла ну очень комфортно при достаточном освещении, и делать это можно часами непрерывно.
  • Почему IDEA лучше Eclipse
    0
    А еще в Эклипсе совершенно ужасная поддержка JavaScript. Я ей пользовался много лет, терпел, но после очередной их выходки в новой версии с неотключаемой подсветкой ошибок несоответствия типов, которые во многих случаях не ошибки вовсе, начал пользоваться WebStorm и с тех пор Eclipse не запускал даже ни разу.
  • Чем плох GNU make?
    +1
    Я в своём Leaflet сейчас использую jake — аналог rake под node.js. Очень просто, удобно, и к тому же приятно описывать билд-скрипты и зависимости для JS-проекта на JS же, без лишних сторонних языков.
  • Вышла библиотека Leaflet версии 0.3
    +1
    Не реализовывал до этого времени такую возможность, т.к. не знал, что она востребована. Теперь буду знать, спасибо. :)
  • Вышла библиотека Leaflet версии 0.3
    +4
    Спасибо за анонс!

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

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

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

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

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

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

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