Pull to refresh

Comments 46

Вот бы еще можно было использовать оффлайново карты и POI из OpenStreetMap! Я бы купил такую версию.
Навител именно оттуда и берет данные, нет?
Вроде OsmAnd для андроида именно их и использует (офлайново)
Ну вот я его и использую вместе с 2GIS.
Уважаю вашу компанию за внимательное отношение к быстродействию работы. Хотя в плане скорости меня больше всего поражает зум на карте в десктопной версии 2ГИС (например, плюсиком на клавиатуре или колёсиком мышки). Даже на моём довольно старом железе он настолько плавный, что хочется прыгать от счастья!
Зато плавность зума и скролла у меня на андроиде явно оставляет желать лучшего.
Скоро это будет пофиксено, т.к. появится аппаратное ускорение графики.
Новая версия qt стала это поддерживать? Немного непонятно, почему раньше это не добавили.
Qt в целом поддерживает OpenGL уже давно (на «родных» платформах), но именно под Андроидом всё не так просто и work in progress. Мы затащили в свой порт Qt наработки из QPA и Necessitas и долго пилили их напильником. И ещё пилим и будем пилить и после релиза.
Движок карты не использует Qt.
Вообще и Qt, и наш движок карты (см. iphone) уже давно умеют работать с OpenGL, просто до GL-версии для андроида руки добрались только сейчас.
Спасибо за оперативный ответ! Пользуюсь случаем напишу про ещё один досадный недостаток.

Процесс обновления карт выполняется в треде Activity, поэтому когда ставишь обновления (а это минут 5, не меньше), то он может прерваться при переключении на другое приложение. По хорошему такие вещи нужно переносить в сервис и показывать в notification area ход обновления. На практике я даже почти каждый месяц карты обновляю со 2-3 попытки (хорошо ещё, что не начинается с начала).
UFO just landed and posted this here
Кстати, да. Тот же OSMAND с весьма детальными картами OpenStreet работает без подтормаживаний на моем Nook Color с CM 10.1
Графическое ускорение будет на уровне всего интерфейса, не только карты.
Спасибо за детальное описание. Только про эвристику оценки как раз ничего и не написано. Кстати, abs(dx) + abs(dy) — это как-то уж совсем плохо, т.к. в таком случае в качестве результата можно получить чуть ли не первый попавшийся маршрут.
Это же оценочная часть стоимости в А*. Пройденная вычисляется точно.
Ну утрированный случай: между начальной и конечной точкой есть только 2 ребра — прямое и кривое. Первым попадается кривое, но его длина меньше abs(dx) + abs(dy). Я так понимаю, что после этого алгоритм А* останавливается.
В этом случае оба ребра попадут в «кучу» кандидатов на просмотр,
работа продолжается, пока в куче что-то есть и пока это что-то потенциально лучше уже найденных кандидатов.
Т.е. будут просмотрены оба ребра и выбран лучший вариант.
Попробую свою мысль на картинке пояснить:
Картинка

Рёбра 1 и 2 лежат в куче. Сначала достаем ребро 1. Оно выдает готовый маршрут, то есть попадает в кандидаты.
Потом достаём ребро 2. «Потенциально» оно обеспечит маршрут, нарисованный пунктиром. То есть «потенциально» оно хуже имеющегося кандидата, поэтому дальше считаться не будет.
Попробую пояснить подробнее.
Нужно различать эвристику и отсечение. Эвристика определяет, в каком направлении будет распространяться волна на следующем шаге. Отсечение определяет, когда закончится алгоритм. Евклидову меру (обычное человеческое расстояние по прямой) можно использовать в обоих случаях, равно как и приближённое вычисление корня (сверху).
В общем же случае для эвристики и для отсечения можно использовать разные меры, причём некоторые работают только для эвристики, а некоторые подходят для отсечения, но куда менее эффективны для эвристики.
В случае с манхэттоновской мерой отсечение можно делать по максимальному из расстояний по осям, которое, кстати, не вызывает условный переход, «ломающий конвейер», т.к. реализуется эффективнее.
Более того, такую меру нельзя использовать для отсечения, только для эвристики. Но в статье же сказано, что эвристики могут быть разные, нужно подбирать. Например, можно использовать максимальное из расстояний по осям, или же реализовывать приближённые алгоритмы вычисления корня.
На самом деле сейчас в релизной версии и для эвристики и для отсечения используется эвклидово расстояние.
Мы проводили эксперименты с манхеттеновским (dx+dy), чебышева (max(dx, dy)) и эвклидовым. Последнее дало наилучшие результаты и наименьшее число ошибочных маршрутов.
Были опасения за производительность на мобилках, но там уже в подавляющем большинстве стоят математические сопроцессоры, так что сейчас в итоге — эвклид.
Ну, ИМХО, тестировать эти метрики для отсечения довольно странно, а про скорость в случае эвристики — довольно интересно. Приближённые методы по идее должны быть быстрее, но если и так всё быстро, то и смысла нет, да.
Хорошее, правильное и вполне себе практичное решение, респект!
Правда у меня есть подозрение, что оптимальность выбора маршрутов можно повысить — хотя бы за счет статистики о пробках (по той же москве расстояние — не лучший критерий для оценки скорости).
Есть, есть такая буква :)
В Н-ске предсказатель пробок работает довольно точно, постепенно это будет везде.
Критерием является не расстояние, а время.
В Новосибирске и Санкт-Петербурге используется реальная статистика (упакованные данные из обычно), для остальных городов — синтетические скорости по классам дорог.
Вот оно как. Глядя на поезд через Москву сомнения возникли, что оптимизируют расстояние)
Совсем скоро должны быть уже реальные статистические данные — тогда станет значительно лучше…
Поставил я на iPad 2gis. Пока был в wi-fi сети, все было нормально. Приехал в деревню к Маме — «ТРЕБУЕТСЯ ОБНОВЛЕНИЕ БАЗЫ»!

И нет доступа к старой (вчерашней) базе. Вот спасибо, подлецы!
Старые базы не полностью совместимы с версией 2.9.0. Чтобы поиск работал офлайн, нужно обновить базу города до актуальной.
Недружественное поведение по отношению к пользователю заключалось в том, что по наступлению какого-то момента времени, ПРИ ОТСУТСТВУЮЩЕМ доступе к инету, 2гис перестал работать.
Ни карт, ни расписаний, ни телефонов.
ПЕРЕСТАЛ! И выставил невыполнимые (на тот момент) требования!
Да, но просьба сразу обновить базу города была прописана в аннотации к обновлению приложения.
Как бы сделал я:

1. При обновлении софта предупреждал бы пользователя.
2. Сохранял бы старую версию софта и баз до того, как пользователь подтвердит, что все «новье» загружено.
К сожалению, маркеты (AppStore и Google Play) по такому принципу просто не работают. Они работают извне и неуправляемо по отношению к приложению и просто обновляют его, при этом даже нет возможности гарантировать, что пользователь прочитал описание «Что нового». Какие-то пуш-сообщения также не панацея, их далеко не все получат, не все прочитают и не все «правильно» отреагируют. Держать две версии приложения в iOS и Android тоже нет технической возможности (разве что только зашить две версии в один пакет, соответственно, увеличив его размер). Так что это тоже решение не идеальное.
Ну что для пользователя критичнее — внезапно остаться без карт или скачать чуть больший пакет?
Что для пользователя удобнее — запускать одно приложение и выбирать город или иметь сразу пять? Хотя, конечно, большинство пользуется только одним городом.
Некорректная аналогия. Выбирать город приходится, потому что закачка карт требует (по сравнению с «двойным» apk) очень много трафика, времени и места.
У некоторых пользователей включено автообновление приложений. Проблемы бы в таком случае не возникло, если бы базы были опубликованы в маркете. А раз их там нет, было бы неплохо каким-либо образом уведомлять пользователя о несовместимости до (или хотя бы сразу после) обновления либо написать предупреждение о возможных проблемах в случае включения автоматического обновления 2GIS: так хотя бы часть пользователей будет предупреждена заранее.

P.S. Сам столкнулся с такой же ситуацией, но мобильный интернет был все же доступен. Пришлось лишь потратить немного времени на обновление базы.
Разместить базы в Маркете невозможно по техническим причинам, к сожалению. Их слишком много и они слишком большие. Кроме того, если их выкладывать туда как дополнительные файлы данных или как отдельные пакеты (это возможно для Андроида), то всё равно нет 100% гарантии их своевременного обновления вместе с оболочкой.
При обновлении на 2.9.0 и сохранении устаревших данных на онлайн переходит только поиск.
Карты, справочник с рубрикатором, поиск проезда и т.п. остаются полностью работоспособны.
Как раз на выходный использовал 2GIS в Питере. Отличное приложение, заменило все виды карт и справочников.

А теперь о минусах:
* Очень часто мне предлагался маршрут, который содержит 2 пересадки в метро. Тогда как в Питере в центре в половине случаев достаточно проехать на одну станцию дальше и обойтись одной пересадкой.
* Не обозначен подземный переход между станциями метро. Реально сбивает с толку, когда показывается, что я должен выйти из метро,
перейти оживлённую магистраль и затем сесть на другую станцию. Тогда как на самом деле переход находится под землёй в самом метро.
Описанные вами минусы относятся к несколько иному алгоритму — поиску проезда на общественном транспорте и над ним также идет активная работа.
Ну только рУтинг, а не рОУтинг, если уж не хотите по-русски называть прокладкой маршрутов. В целом — можно только позавидовать вашему объему данных, у нас граф на 2 порядка больше по размеру.
Приношу извинения за мой немецкий акцент.
Близкий по архитектуре р[о]утинг успешно работал на данных Teleatlas USA+Канада, это > 50 млн сегментов, так что на ближайшую перспективу мы мы спокойны за масштабирование.
Sign up to leave a comment.