Внутри API Android, которое определяет геопозицию, есть функциональность, которая использует Wi-Fi для уточнения данных (Sensor Fusion) от GPS, помимо этого, если не изменяет память, там есть и возможность использования данных от базовых вышек.
«Тепловая карта», как раз это распространённый термин. Вы про LOS (Line of Sight)?
Про ЗПВ согласен, но это больше характеризует именно зону, нежели прямую.
Отвратительный перевод технически плохо написанная рекламной статьи.
Пытался правильно расставить запятые, не получилось.
Что касается перевода — от одного слова «псевдодистанция» — начинает тошнить. Реально используется термин «псевдодальность», причем псевдодальности по ГОСТ Р 52928-2010 бывают кодовые и фазовые. Для фазовых чащей говорят «псевдофаза.»
Каюсь, никогда не изучал ГОСТЫ по данной тематике, да и не было потребности, а при подготовке статьи нашёл упоминание «псевдодистанция» в русскоязычной научной литературе, от чего и отталкивался.
Непонятно, о каких приемниках речь: L1, L1/L2, L1, L5. На L1 многолучевость может дать ошибку кодовых измерений на одном спутнике до 75 метров, на L2 или L5 — до 7.5 метров.
В статье практически с самого начала чётко ведётся речь о мобильных устройствах на платформе Android, в виду доступности API для взаимодействия с приёмником напрямую. По поводу конкретики не могу дать точного ответа, возможно вам стоит обратиться к авторам оригинальной статьи, но смею предположить что ответ будет разниться в зависимости от конкретного устройства.
Непонятно, о каких системах речь — о получающих поправки через интернет или о неполучающих. Для систем с поправками через инет важнее высокоточные эфемериды и ионосферная коррекция. И лишь после них идет влияние многолучевости. Поэтому невозможно оценить ни влияние на точность, ни экономический эффект.
Если я правильно вас понял, то вы ведёте речь о самом низком уровне, с которым как раз и взаимодействует система Android, и возможно прошивка самого приёмника. Я думаю здесь стоит обратиться к исходному коду Android, либо, как вариант к статьям посвященным реализации API на определённой версии Android.
50 метров — это суммарная ошибка псевдодальности одного спутника. Она дает точность порядка 3 метров КВО-50 координат.
Можете сослаться на подтверждённый источник в литературе? Смущает контекст: «суммарная ошибка» и «одного спутника».
Если у спутника плохое отношение сигнал-шум, то он и так идет в решение с пониженным коэффициентом корреляции (или вообще исключается из решения). То есть метод из статьи — это лишь добавочная навигация по спутникам, не идущим в решение или идущим с пониженным коэффициентом корреляции.
Как раз в статье утверждается, насколько я смог уловить, о том, что классический подход, в том числе и с пониженным коэффициентом работает плохо в условиях многоэтажек, а авторы предлагают подход с трёхмерными картами, которые увеличивают точность в этих условиях.
Предложенный метод может дать результаты для Нью-Йорка, но малополезен для Питера. Потому что в Питере — дожди. И капля воды на одной стороне антенны = даст тот же результат. А антенна внутри салона — бесполезна для таких измерений, ибо больше всего снижает S/N крыша автомобиля.
Это уже детали реализации, и в целом сторонняя проблема. Насчёт дождей, возможно, но есть мнение, что в данном случае большую ошибку внесёт именно облачность. Поправьте, если я не прав. Чаще всего, телефон монтируется на лобовое стекло, и приёмник имеет прямую видимость через него. Но да, по поводу крыши я с вами согласен.
Непонятны экономические затраты на создание модели в сравнении с затратами на переход на двухчастотные приемники. Особенно с учетом того, что broadcom собирается в этом году выпустить дешевые двухчастотные чипы с точностью 30 см КВО-50
Речь о покрытии существующих и новых пользователей приложения Uber и не только. Вы предлагаете отказаться от 100% существующих устройств и поддерживать только те, в которых будут установлены эти новые чипы Broadcom? Это не та область применения, где возможно взять и просто внедрить передовые хардварные решения. В массовый рынок, например телефонов, эти чипы будут приходить год — два, как это обычно и бывает.
Огромный, даже за популярным картографическим софтом стоит очень большой теоретический пласт, в том числе и современный.
Проблемы на открытой местности связаны, как раз с описанными в статье вещами, так и помимо этого, с слабыми приёмниками в большинстве мобильных устройств. Скажем, последние разработки в области GPS, показывают точность порядка 40 сантиметров, что уже весьма и весьма неплохо. А если в свою очередь использовать методики Sensor Fusion, что с точки зрения современной инфраструктуры позволяет существенно уточнять геопозицию.
Как раз у Uber несколько другая философия в этом плане, то есть человек может двигаться пока ждёт такси, поправьте если не прав.
Высота (например над уровнем моря) в подобном классе задач редко рассматривается.
А в целом, да, любое улучшение данных GPS основано на некоторых предположениях (например объект автомобиль движется только по дорогам общего пользования, или объект движется со скоростью не больше заданного и т.д.).
Подход Uber очень интересен с точки зрения универсальности.
Согласен, что кратко, но увы это базис, с которого так или иначе можно отталкиваться. Если углубляться в подробности, то каждый из вариантов, в идеале расписать отдельным постом, и он будет совсем не коротким, и не каждому доступным.
По поводу самопиара "небольшого", дважды внимательно просмотрел статью и не увидел ничего такого. А если Вы говорите про ссылку в репозитории, то как раз за ней и находится небольшой разбор кода, который я думал уместить в следующем посте на хабр.
Зависит от потребностей, но в целом это 2 или 4 — ый. Я сам сейчас в разрабатываемом проекте остановился на втором, поскольку там уже были Яндекс Карты, в целом я сторонник векторного решения, как более состоятельного, но нужно потратить немного больше сил на бэкэнд, в идеале вообще была бы около микросервисная архитектура и использование готового решение на JS (да, на нём действительно очень много всего).
Вообще, для своей книги я готовлю это всё очень подробно и даю некоторые хинты по поводу организации процессов, если будет лишнее время упрощу, обрежу и выложу на хабр и/или в свой блог.
Функции вида «sub_*» — то, как вы их видите с перспективы IDA, то есть уникальное название, которое им присваивает сама IDA. В C/C++ всё, что компилируется без экспортирования функций, будет абсолютно с идентичными названиями.
Абсолютно защищённого софта не существует. Скажем, любой человек с познаниями равными вашим сможет проделать всё тоже самое, причём, есть ещё как минимум несколько путей с помощью которых вы можете добиться нужного результата.
Единственный беспроигрышный вариант — обработка всего сервером, но требует больше ресурсов и большей внимательности, поскольку уязвимые места могут быть и там.
Для общего развития достаточно читать классику вроде Стренга, Фихтенгольца и т.д., с одной стороны приходит осознание некоторых вещей, а с другой вы не полностью погружаетесь, что конечно не даёт вам постигать всё с той-же глубиной, что и студентам.
Хотя если быть откровенным, сегодня, желание понимать тот-же мат. анализ или линейную алгебру возникает далеко не у всех студентов, так что быть студентом — не такой уж и плюс.
Здесь нужно сделать уточнение. Её можно изучать, как предмет, который преподаётся в гуманитарных науках, скажем «Высшая математика», а можно изучать, как комплекс: «Математический анализ», «Линейная алгебра», «Аналитическая геометрия», «Дифференциальные уравнения», «Комплексный анализ», «Численные методы», «Теория Групп».
Я придерживаюсь мнения, что подробное изучение, как во втором варианте, в большинстве случаев, бесполезно, особенно в веб-разработке. Конечно при решении каких-то особых проблем, а так-же в другой сфере могут возникнуть проблемы, требующие хорошего фундаментального знания математики, но веб-разработку в целом, это не задевает.
Я встречал много примеров, когда «разработчики» не имеют глубоких познаний в математике и это не всегда так-уж плохо, хотя знание основ той математике, что преподаётся в университетах, даже не повредит, а наоборот позволит хорошо понимать, как работает вся эта «кухня».
Всё сравнилось с тем, что уже существует, например github.com/vladkens/VK. Если брать в качестве знаменателя «красоты» какие-либо хорошие практики, то эта библиотека их выполняет, следовательно, допустимо назвать её красивой. При написании, я руководствовался удобством и компактностью кода для исполнения некоторых операций, чего, как мне кажется, удалось добиться. И конечно-же, если вам кажется, что ваше понимание «красоты» ближе к истине, то никто не запрещает вам сделать аналогичное решение, как некоторое время назад поступил и я.
Пока что, не поддерживается. Загрузка изображений куда вас интересует? На самом деле, есть несколько различных мест куда их можно загрузить и каждое имеет свою специфику, за исключением конечно некоторых общих моментов. Если хотите, можете создать Issue на гитхабе и по возможности загрузки изображений будут реализованы.
Про ЗПВ согласен, но это больше характеризует именно зону, нежели прямую.
Пытался правильно расставить запятые, не получилось.
Каюсь, никогда не изучал ГОСТЫ по данной тематике, да и не было потребности, а при подготовке статьи нашёл упоминание «псевдодистанция» в русскоязычной научной литературе, от чего и отталкивался.
В статье практически с самого начала чётко ведётся речь о мобильных устройствах на платформе Android, в виду доступности API для взаимодействия с приёмником напрямую. По поводу конкретики не могу дать точного ответа, возможно вам стоит обратиться к авторам оригинальной статьи, но смею предположить что ответ будет разниться в зависимости от конкретного устройства.
Если я правильно вас понял, то вы ведёте речь о самом низком уровне, с которым как раз и взаимодействует система Android, и возможно прошивка самого приёмника. Я думаю здесь стоит обратиться к исходному коду Android, либо, как вариант к статьям посвященным реализации API на определённой версии Android.
Можете сослаться на подтверждённый источник в литературе? Смущает контекст: «суммарная ошибка» и «одного спутника».
Как раз в статье утверждается, насколько я смог уловить, о том, что классический подход, в том числе и с пониженным коэффициентом работает плохо в условиях многоэтажек, а авторы предлагают подход с трёхмерными картами, которые увеличивают точность в этих условиях.
Это уже детали реализации, и в целом сторонняя проблема. Насчёт дождей, возможно, но есть мнение, что в данном случае большую ошибку внесёт именно облачность. Поправьте, если я не прав. Чаще всего, телефон монтируется на лобовое стекло, и приёмник имеет прямую видимость через него. Но да, по поводу крыши я с вами согласен.
Речь о покрытии существующих и новых пользователей приложения Uber и не только. Вы предлагаете отказаться от 100% существующих устройств и поддерживать только те, в которых будут установлены эти новые чипы Broadcom? Это не та область применения, где возможно взять и просто внедрить передовые хардварные решения. В массовый рынок, например телефонов, эти чипы будут приходить год — два, как это обычно и бывает.
Думаю если буду переводить в следующий раз, прибегну к пересказу.
Проблемы на открытой местности связаны, как раз с описанными в статье вещами, так и помимо этого, с слабыми приёмниками в большинстве мобильных устройств. Скажем, последние разработки в области GPS, показывают точность порядка 40 сантиметров, что уже весьма и весьма неплохо. А если в свою очередь использовать методики Sensor Fusion, что с точки зрения современной инфраструктуры позволяет существенно уточнять геопозицию.
Как раз у Uber несколько другая философия в этом плане, то есть человек может двигаться пока ждёт такси, поправьте если не прав.
Высота (например над уровнем моря) в подобном классе задач редко рассматривается.
А в целом, да, любое улучшение данных GPS основано на некоторых предположениях (например объект автомобиль движется только по дорогам общего пользования, или объект движется со скоростью не больше заданного и т.д.).
Подход Uber очень интересен с точки зрения универсальности.
Согласен, что кратко, но увы это базис, с которого так или иначе можно отталкиваться. Если углубляться в подробности, то каждый из вариантов, в идеале расписать отдельным постом, и он будет совсем не коротким, и не каждому доступным.
По поводу самопиара "небольшого", дважды внимательно просмотрел статью и не увидел ничего такого. А если Вы говорите про ссылку в репозитории, то как раз за ней и находится небольшой разбор кода, который я думал уместить в следующем посте на хабр.
Вообще, для своей книги я готовлю это всё очень подробно и даю некоторые хинты по поводу организации процессов, если будет лишнее время упрощу, обрежу и выложу на хабр и/или в свой блог.
Абсолютно защищённого софта не существует. Скажем, любой человек с познаниями равными вашим сможет проделать всё тоже самое, причём, есть ещё как минимум несколько путей с помощью которых вы можете добиться нужного результата.
Единственный беспроигрышный вариант — обработка всего сервером, но требует больше ресурсов и большей внимательности, поскольку уязвимые места могут быть и там.
Хотя если быть откровенным, сегодня, желание понимать тот-же мат. анализ или линейную алгебру возникает далеко не у всех студентов, так что быть студентом — не такой уж и плюс.
Я придерживаюсь мнения, что подробное изучение, как во втором варианте, в большинстве случаев, бесполезно, особенно в веб-разработке. Конечно при решении каких-то особых проблем, а так-же в другой сфере могут возникнуть проблемы, требующие хорошего фундаментального знания математики, но веб-разработку в целом, это не задевает.
Я встречал много примеров, когда «разработчики» не имеют глубоких познаний в математике и это не всегда так-уж плохо, хотя знание основ той математике, что преподаётся в университетах, даже не повредит, а наоборот позволит хорошо понимать, как работает вся эта «кухня».
Опять таки, это просто примеры использования, никто не говорит, что это непреложная истина.