Работал в разных типах структур — бюджетные, муниципальные, коммерческие.
В среднем в коммерческих работается более комфортно.
Сейчас наиболее комфортное (хотя по степени загруженности интенсивности опять же самое-самое) место работы из всех что были до этого — 100% коммерческий банк из списка «системообразующих»
Тут возможно незаконное собирание и нарушение п.3 ст.18 153 ФЗ:
Если персональные данные получены не от субъекта персональных данных, оператор, за исключением случаев, предусмотренных частью 4 настоящей статьи, до начала обработки таких персональных данных обязан предоставить субъекту персональных данных следующую информацию:
1) наименование либо фамилия, имя, отчество и адрес оператора или его представителя;
2) цель обработки персональных данных и ее правовое основание;
3) предполагаемые пользователи персональных данных;
4) установленные настоящим Федеральным законом права субъекта персональных данных;
5) источник получения персональных данных.
Я не про законы и сертификаты, а про реальную жизнь. С точки зрения тех, кто с этим сам сталкивался по работе. Мне немного (всего-то лет 20) довелось поработать с системами мониторинга и управления, в том числе распределенными, но не в самых критичных областях обеспечения жизнедеятельности. Посему имею общее представление, но хотелось бы конкретики.
Вот честно — возможность читать оппозиционные сайты, писать в фейсбук гневные посты про кровавую гебню и постит в инстаграм «вот я кушаю, а вот я какаю» не волнует ну совершенно.
А возможность малыми затратами парализовать системы управления энергоснабжением в масштабах региона (например) волнует весьма.
Кто переживает «чтобы не было как в китае» скажу — для тех, у кого недостаточный уровень образования все необходимые для жизни сервисы реализованы внутри. Кто хочет большего — придется чуть напрячь мозг (чтобы самостоятельно настроить vpn хотя бы) и все будет. Работа через vpn со всеми мировыми ресурсами там вполне реальна. Ну кроме отдельных районов, где вообще блокируется все и вся.
А вот интересно два момента
1. Оборудование на узлах маршрутизации чье? И кто гарантирует отсутствие в нем закладок, позволяющих превратить в кирпич все внутренние маршрутизаторы суверенного рунета?
Это как бы с одной строны посмотреть.
С другой стороны взгляд
2. Кто из отметившихся тут комментаторов занимался разработкой в области распределенных систем, так или иначе связанных с обеспечением жизнедеятельности? Ну скажем, управление большими энергосистемами, хотя бы на уровне МРСК. Какими мерами вы обеспечиваете надежность функционирования системы в случае проблем с маршрутизацией?
Честно говоря, больше волнует это, а не возможность смотреть порнокотиков или читать откровения очередного либерального блоггера.
Что касается получения информации — жизнь всегда найдет лазейку. И в кровавом совке вражьи голоса сквозь глушилки слушали и во время путчей 90-х годов информация в регионы летала помимо официальных каналов (а рунет тогда был в зачаточом состоянии).
Для власти самое страшное — потерять иллюзию своей легитимности и выборности. По крайней мере пока это так.
Посему, избирателей на выборы заманивают всеми возможными способами.
Ваш пример не является показательным. Для линейной регрессии есть прямые формулы без матричной арифметики.
А вот когда параметров станет 7-10 и более, то градиентный спуск для функции [среднеквадратичного отклонения] многих переменных может стать весьма ресурсозатратным.
А если еще выбранная модель будет нелинейной по параметрам, то станет совсем весело — появляется риск попасть на локальный минимум.
В общем случае регрессия сводится к решению задачи по оптимизации — нахождению экстремума функции. Линейной или нелинейной относительно параметров. И одним градиентным спуском там не ограничивается.
В общем, советую поискать серьезную литературу на эту тему — учебники, лекции. Может быть еще будет полезно поискать по теме «обработка экспериментальных данных». Там и статистический и регрессионный анализ используется.
Очень и очень поверхностно.
Рекомендую почитать Весьма доходчиво написано. Хотя и «много буков».
На самом деле, тема намного сложнее чем тут описано. Все сказанное выше хорошо и справедливо в том случае, когда есть данные и есть готовая модель (уравнение), которая их описывает и вопрос только в том, чтобы найти коэффициенты этой модели.
Но модели может и не быть как таковой. И типичная ситуация такова — вот вам результат и вот вам десяток факторов, которые могут на него влиять. А могут и не влиять. И для начала нужно определить что влияет на результат, а что нет — какие факторы нужно учитывать при построении модели, а какие можно отбросить. Это и есть регрессионный анализ.
Я вообще-то употребил термин «разработчик». Человек, разрабатывающий некий конечный продукт.
Естественно хорошего алгоритма нет — откуда ему взяться, когда у вас даже надёжной формализации «целенаправленного движения» нет?
Правильно. Сначала нужно проанализировать куеву хучу треков чтобы понять по каким признакам выделять участки направленного движения, а по каким участки дрифта.
И это тоже работа для разработчика в общем смысле. Да, бывают ситуации, когда эту часть на себя берет аналитик. А бывает когда нет.
А потом еще прогнать эту кучу треков через тесты чтобы понять насколько оно получилось работоспособно. Может быть тут тестировщик поможет. А может и нет.
Если вы не понимаете, что бизнес-задача, описанная обычным языком — это тоже вполне себе ТЗ — то ой.
«Ой» — это если вы не представляете себе что при решении таких задач может потребоваться что-то сложнее правильно составленного запроса в гугл и скачивания готовой формулы.
В том и дело, что я видел на треках нереальные скорости и не на прямых.
А с высотой — да. В силу особенностей технологии точность ее определения сильно хуже точности определений координат. Тут спасает наличие барометрического альтиметра, но его нужно калибровать каждый раз перед использованием и он может вносить погрешность при резких изменениях давления (когда погода меняется резко и сильно).
Если не нужны абсолютные значения высоты, а просто оценка относительных разностей я обычно заменяю высоты, определенные прибором на высоты из SRTM таблиц (они доступны в сети) по координатам. Там тоже погрешность, но, по крайней мере если через час пришел на ту точку, где уже был, высота будет та же самая :-)
Ну или более сложные алгоритмы с усреднением высот в одинаковых точках, коррекция высоты прибора с привлечением высот из таблицы (с эвристикой какая из высот точнее) и т.п. Но тут опять математика, которая «не нужна» и без которой «можно замечательно обойтись потому что все уже до на придумано» :-)
В любом ТЗ написано «возьми то и положи туда» (да и задачи в вольной постановке тоже формулируются именно таким образом). Разница только лишь в объеме пропущенных шагов.
Хорошо когда так. А когда «ТЗ» формулируется в виде «нам нужно разработать систему, которая позволит управляющей компании, обслуживающей объекты по всему городу и в города-спутниках, держать всего одну диспетчерскую куда сходятся все сигналы со всех объектов, представляются в наглядном виде, логируются и т.д. и т.п.». В команде есть координатор, есть схемотехник, есть разрабочик под микроконтроллеры и два разработчика на верхний уровень.
Да, тут нет математики. Это просто пример из реальной практики когда ТЗ как такового нет. Есть бизнес-задача которую надо решить. Дальше строится архитектурное решение, разрабатываются протоколы обмена данными, выделяются логические блоки и дальше каждый уже в рамках своего блока ищет наиболее оптимальное решение.
И любая задача решается именно так. просто где-то есть аналитик, которрый решает вопросы с бизнесом и превращает их хотелки в FSD той или иной степени подробности для разработчика.
А где-то аналитика нет и разработчику приходится начинать разработку с чистого листа — выбора архитектуры построения системы. И далее по списку.
Вторая задача из личной практики. Нужно отфильтровать «дрифты» в GPS треках с минимальной потерей данных. Дрифт — это ситуация когда прибор неподвижен, а координаты точки «гуляют» в результате чего трек выглядит как будто прибор хаотично перемещали туда-сюда во все стороны с амплитудой, доходящей до нескольких десятков метров. Дополнительное условие — нужно максимально точно отслеживать момент как остановки, так и начала целенаправленного движения.
Никаких указаний как это можно сделать от заказчика, естественно, не поступило. Просто хотелка — удалить.
Гугль выдает обескураживающие результаты — более-менее надежного алгоритма нет. Нужно изобретать самому. Тут уже без математики туго.
Я не делю задачи по сложности. Я делю их по степени подготовки для кодирования (которое является конечным этапом любой разработки). И на практике приходилось сталкиваться с очень широким спектром от ТЗ в стиле «сделайте мне красиво» до полностью прописанного алгоритма, который остается только выразить в виде собирающегося кода.
Для решения конкретно вашей задачи давно уже существует proj_lib Но беда в том, что не существует ни одной 100% адекватной проекции. Да и системами координат и геоидами не все так просто. А для выбора правильной проекции под задачу иногда бывает важно понимать какая из существующих будет лучше.
Ну и еще один аспект. Бывает что программист работает по ТЗ. Где написано «возьми то и положи туда». Это работа не разработчика а кодировщика. Тут действительно ничего особо знать не нужно кроме как нарисовать семь красных линий одной строкой кода.
А бывает что разработчику дается полноценное FSD — «на входе имеем то, на выходе нужно получить это». А выбор алгоритма и его реализации уже полностью на совести разработчика. И очень часто необходимость разработки нового возникает потому что ни один из 100500 существующих продуктов не устраивает по каким-то критериям. А это значит, что нужно придумывать что-то новое, а не то что выдается гуглем в первых пяти строках поиска.
Впрочем, это отдельная тема про различия разработчика и кодировщика.
Тут дело в другом. GPS достаточно точно измеряет скорость (измерения основаны на эффекте Доплера, подробности можно нагуглить — статей на эту тему достаточно много) при условии прямолинейного равномерного движения. Например, на автомобиле, когда прибор лежит на передней панели (например) и машина движется примерно с одинаковой скоростью. Тогда погрешность измерения невелика — порядка 0.1 м/с.
При катании на лыжах ситуация радикально иная. Во-первых, лыжник все-таки движется дугами т.е. постоянно меняет направление. Во-вторых, прибор обычно лежит в кармане где-то в верхней половине корпуса. Т.е. при перекантовках и смене ангуляции прибор вместе с корпусом совершает резкое движение перпендикулярно траектории.
Все это резко повышает погрешность измерения скорости и в максималку может попасть не скорость лыжника, а вот эта скорость самого прибора в момент перекантовки.
Я накопил достаточно большую коллекцию треков, записанных логгером (он тупо пишет nmea поток с чипа с частотой 5 точек в секунду на карту памяти). Просмотр таких треков по точкам показывает кратковременные рывки скорости именно в такие моменты, как указано выше.
Методика спидсерферов такая — в зачет идет усредненная на 5-10 секунд скорость на прямолинейном отрезке. Это более адекватный параметр. Возможно, там еще отбрасываются «хвосты» по правилу трех сигм. У них есть специальный софт для анализа треков и участники просто присылают свои треки, а результаты уже выдаются софтом.
У мобильных приложений далеко не у всех заложена хоть какая-то фильтрация. Многие выводят напрямую то, что прилетело с чипа.
Я далеко не все смотрел, из точно фильтрующих видел meRun (для андроида, для Blackberry пользуюсь ей же, там называется CascaRun). Правда, описания алгоритма фильтрации не знаю. Но какие-то настройки фильтров там есть.
Для компа сам писал анализатор треков. Там много всяких фильтров для прочистки треков и удаления недостоверных (в т.ч. и по скорости) точек и подсчета статистики.
Значит просто не попадалось еще соответствующих задач… Вот поставят задачу написания какой-нибудь навигационной системы — придется и с проекциями разбираться и с системами координат и с переводом из одной проекции в одной системе координат в другую в другой системе координат (скажем, от меркатора в WGS84 к Гаусс-Крюгеру в Пулково-1942). Тут придется немножко математику вспомнить. А если потребуется еще сохранять треки, то потребуется фильтрация — фильтр Калмана хотя бы понять как работает и как им пользоваться. Или обосновать что более простые аналоги типа двойного экспоненциального сглаживания в некоторых ситуациях работают не хуже. Как можно использовать сплайн-сглаживание или прикрутить фильтр Ходрика-Прескота (который придумывался совсем не для того). Ну про прореживание фильтром Дугласа-Пеккера как-бы и неудобно говорить — это азы.
А если потребуется еще и маршруты строить, то тут теория графов в полный рост…
Так что или не зарекаться что никогда не понадобиться, или заранее исключить для себя определенные области разработки.
Сам до недавнего времени пользовался связкой планшет — кнопочная звонилка. Сейчас, увы, опопсился и перешел на смартфон (ну, правда, тут тоже не без «нестандартности» :-)
Так что более чем понимаю такое решение :-)
Правда, я равнодушен к визуальным финтифлюшкам, не люблю писать интерфейсы, люблю глубокий backend и получаю удовольствие от отладки системным отладчиком в зеленом экране (эмулятор терминала IBM5250)
Речь не о субметровой точности (там нет зконодательных ограничений, насколько я в курсе, там ограничения технического характера), речь о бреде, который эти программы выводят на экран.
Есть мобильные приложения — спортвные трекеры. Например, катаемся на горных лыжах, на телефоне запущено такое приложение. По итогу оно нам показывает суммарный набор-потерю высоты, сколько по расстоянию накатали, максимальную скорость на спуске. Так вот периодически люди (обычно новички) в профильных форумах начинают хватстаться что у них где-то там максимальная скорость была аж 120км/ч (порядок величин такой). при том, что такая скорость характерна для спортсменов на соревнованиях по скоростному спуску на этапах КМ. Но те-то едут в обтекаемых комбезах в низкой аэродинамической стойке на 2+ м спусковых лыжах и по очень жесткой трассе. Для любителя в куртке и широких штанах на обычных лыжах такое в принципе недостижимо.
Да, такая цифра может придти с чипа, но надо понимать откуда она взялась и как соотносится с реальностью. На тему измерения скорости с помощью GPS написано много статей с разбором в каких ситуациях какая погрешность возможна. Есть сообщество спидсерферов (speedsurfing), которые измеряют скорость с помощью GPS и сравнивают ее с другими — у них разработаны методики записи и обработки треков для получения адекватных сравнимых величин.
Но во все это надо вникать, разбираться. А в мобильную разработку пришло огромное количество… даже не знаю как назвать… людей, которые больше озабочены проблемами монетизации, чем реальной полезностью своей разработки.
Второй пример, с теми же трекерами. Велсипед. Человек покатался по парку (условно) и хвастается что у него суммарный набор высоты аж полтора километра. Ага. На 30-50 километров пути. Родной, откуда? Ты в Альпах через перевалы катался?
Опять нужно понимать, что точность определения высоты в силу физики процесса в GPS на порядок ниже точности определения координат. И в отсутствии барометрического альтиметра в приборе высота даже стоя на месте будет «плавать» и накручивать «суммарный набор». А при наличии оного его нужно регулярно калибровать.
Кроме того, суммарный набор неплохо накручиватеся на мелких кочках. Метр туда, метр сюда, глядишь и полтора километра набежало.
Все это нужно фильтровать и указывать что набрал столько-то при таких-то настройках (скажем, не учитывал наборы на уклонах меньше одного градуса, не учитывал единичные перепады менее полутора метров и т.п.)
Меня больше всего поразило, что научные статьи по физике и химии были написаны без единой математической формулы и практически без расчётов
Это как раз не удивительно. Физика суть наука описательная. И в ней главное понимать как оно все между собой взаимодействует на некотором интуитивном уровне, чем уметь на каждый случай написать формулу для получения нужного ответа.
Есть у меня знакомый, занимается репетиторством по физике. Так вот у него методика сторится на том, что сналала все описывается «на пальцах», без формул. Затем вводятся понятия «базовых величин» (расстояние, время, температура, масса...) Затем переход от базовых к величинам производным (как из рассотяния и времени получить скорость и т.п.). А затем уже то, что описано на пальцах описывается формулами.
Когда он эту методику начал применять на практике, то был сам поражен насколько быстро те, кому физика в школе ну совсем никак не лезет в голову, начинали понимать ее суть и прогрессировать.
Необходимость математики лучше доказывать на реальных задачах из личной практики. С разбором как она решается (или скорее не решается) человеком не знающим математики и как она решается (успешно) человеком, способным применять математический аппарат на практике.
В среднем в коммерческих работается более комфортно.
Сейчас наиболее комфортное (хотя по степени загруженности интенсивности опять же самое-самое) место работы из всех что были до этого — 100% коммерческий банк из списка «системообразующих»
Вот честно — возможность читать оппозиционные сайты, писать в фейсбук гневные посты про кровавую гебню и постит в инстаграм «вот я кушаю, а вот я какаю» не волнует ну совершенно.
А возможность малыми затратами парализовать системы управления энергоснабжением в масштабах региона (например) волнует весьма.
Кто переживает «чтобы не было как в китае» скажу — для тех, у кого недостаточный уровень образования все необходимые для жизни сервисы реализованы внутри. Кто хочет большего — придется чуть напрячь мозг (чтобы самостоятельно настроить vpn хотя бы) и все будет. Работа через vpn со всеми мировыми ресурсами там вполне реальна. Ну кроме отдельных районов, где вообще блокируется все и вся.
1. Оборудование на узлах маршрутизации чье? И кто гарантирует отсутствие в нем закладок, позволяющих превратить в кирпич все внутренние маршрутизаторы суверенного рунета?
Это как бы с одной строны посмотреть.
С другой стороны взгляд
2. Кто из отметившихся тут комментаторов занимался разработкой в области распределенных систем, так или иначе связанных с обеспечением жизнедеятельности? Ну скажем, управление большими энергосистемами, хотя бы на уровне МРСК. Какими мерами вы обеспечиваете надежность функционирования системы в случае проблем с маршрутизацией?
Честно говоря, больше волнует это, а не возможность смотреть порнокотиков или читать откровения очередного либерального блоггера.
Что касается получения информации — жизнь всегда найдет лазейку. И в кровавом совке вражьи голоса сквозь глушилки слушали и во время путчей 90-х годов информация в регионы летала помимо официальных каналов (а рунет тогда был в зачаточом состоянии).
Посему, избирателей на выборы заманивают всеми возможными способами.
А вот когда параметров станет 7-10 и более, то градиентный спуск для функции [среднеквадратичного отклонения] многих переменных может стать весьма ресурсозатратным.
А если еще выбранная модель будет нелинейной по параметрам, то станет совсем весело — появляется риск попасть на локальный минимум.
www.sociologos.ru/metody_i_tehnologii/Razdel_Analiz_dannyh/Regressionnyj_analiz_i_korrelyaciya/Prikladnoj_regressionnyj_analiz_Drejper_Smit
Дрейпер, Смит. Прикладной регрессионный анализ.
Одно время была настольной книгой.
В общем случае регрессия сводится к решению задачи по оптимизации — нахождению экстремума функции. Линейной или нелинейной относительно параметров. И одним градиентным спуском там не ограничивается.
В общем, советую поискать серьезную литературу на эту тему — учебники, лекции. Может быть еще будет полезно поискать по теме «обработка экспериментальных данных». Там и статистический и регрессионный анализ используется.
Рекомендую почитать Весьма доходчиво написано. Хотя и «много буков».
На самом деле, тема намного сложнее чем тут описано. Все сказанное выше хорошо и справедливо в том случае, когда есть данные и есть готовая модель (уравнение), которая их описывает и вопрос только в том, чтобы найти коэффициенты этой модели.
Но модели может и не быть как таковой. И типичная ситуация такова — вот вам результат и вот вам десяток факторов, которые могут на него влиять. А могут и не влиять. И для начала нужно определить что влияет на результат, а что нет — какие факторы нужно учитывать при построении модели, а какие можно отбросить. Это и есть регрессионный анализ.
Правильно. Сначала нужно проанализировать куеву хучу треков чтобы понять по каким признакам выделять участки направленного движения, а по каким участки дрифта.
И это тоже работа для разработчика в общем смысле. Да, бывают ситуации, когда эту часть на себя берет аналитик. А бывает когда нет.
А потом еще прогнать эту кучу треков через тесты чтобы понять насколько оно получилось работоспособно. Может быть тут тестировщик поможет. А может и нет.
«Ой» — это если вы не представляете себе что при решении таких задач может потребоваться что-то сложнее правильно составленного запроса в гугл и скачивания готовой формулы.
А с высотой — да. В силу особенностей технологии точность ее определения сильно хуже точности определений координат. Тут спасает наличие барометрического альтиметра, но его нужно калибровать каждый раз перед использованием и он может вносить погрешность при резких изменениях давления (когда погода меняется резко и сильно).
Если не нужны абсолютные значения высоты, а просто оценка относительных разностей я обычно заменяю высоты, определенные прибором на высоты из SRTM таблиц (они доступны в сети) по координатам. Там тоже погрешность, но, по крайней мере если через час пришел на ту точку, где уже был, высота будет та же самая :-)
Ну или более сложные алгоритмы с усреднением высот в одинаковых точках, коррекция высоты прибора с привлечением высот из таблицы (с эвристикой какая из высот точнее) и т.п. Но тут опять математика, которая «не нужна» и без которой «можно замечательно обойтись потому что все уже до на придумано» :-)
Хорошо когда так. А когда «ТЗ» формулируется в виде «нам нужно разработать систему, которая позволит управляющей компании, обслуживающей объекты по всему городу и в города-спутниках, держать всего одну диспетчерскую куда сходятся все сигналы со всех объектов, представляются в наглядном виде, логируются и т.д. и т.п.». В команде есть координатор, есть схемотехник, есть разрабочик под микроконтроллеры и два разработчика на верхний уровень.
Да, тут нет математики. Это просто пример из реальной практики когда ТЗ как такового нет. Есть бизнес-задача которую надо решить. Дальше строится архитектурное решение, разрабатываются протоколы обмена данными, выделяются логические блоки и дальше каждый уже в рамках своего блока ищет наиболее оптимальное решение.
И любая задача решается именно так. просто где-то есть аналитик, которрый решает вопросы с бизнесом и превращает их хотелки в FSD той или иной степени подробности для разработчика.
А где-то аналитика нет и разработчику приходится начинать разработку с чистого листа — выбора архитектуры построения системы. И далее по списку.
Вторая задача из личной практики. Нужно отфильтровать «дрифты» в GPS треках с минимальной потерей данных. Дрифт — это ситуация когда прибор неподвижен, а координаты точки «гуляют» в результате чего трек выглядит как будто прибор хаотично перемещали туда-сюда во все стороны с амплитудой, доходящей до нескольких десятков метров. Дополнительное условие — нужно максимально точно отслеживать момент как остановки, так и начала целенаправленного движения.
Никаких указаний как это можно сделать от заказчика, естественно, не поступило. Просто хотелка — удалить.
Гугль выдает обескураживающие результаты — более-менее надежного алгоритма нет. Нужно изобретать самому. Тут уже без математики туго.
Я не делю задачи по сложности. Я делю их по степени подготовки для кодирования (которое является конечным этапом любой разработки). И на практике приходилось сталкиваться с очень широким спектром от ТЗ в стиле «сделайте мне красиво» до полностью прописанного алгоритма, который остается только выразить в виде собирающегося кода.
Ну и еще один аспект. Бывает что программист работает по ТЗ. Где написано «возьми то и положи туда». Это работа не разработчика а кодировщика. Тут действительно ничего особо знать не нужно кроме как нарисовать семь красных линий одной строкой кода.
А бывает что разработчику дается полноценное FSD — «на входе имеем то, на выходе нужно получить это». А выбор алгоритма и его реализации уже полностью на совести разработчика. И очень часто необходимость разработки нового возникает потому что ни один из 100500 существующих продуктов не устраивает по каким-то критериям. А это значит, что нужно придумывать что-то новое, а не то что выдается гуглем в первых пяти строках поиска.
Впрочем, это отдельная тема про различия разработчика и кодировщика.
При катании на лыжах ситуация радикально иная. Во-первых, лыжник все-таки движется дугами т.е. постоянно меняет направление. Во-вторых, прибор обычно лежит в кармане где-то в верхней половине корпуса. Т.е. при перекантовках и смене ангуляции прибор вместе с корпусом совершает резкое движение перпендикулярно траектории.
Все это резко повышает погрешность измерения скорости и в максималку может попасть не скорость лыжника, а вот эта скорость самого прибора в момент перекантовки.
Я накопил достаточно большую коллекцию треков, записанных логгером (он тупо пишет nmea поток с чипа с частотой 5 точек в секунду на карту памяти). Просмотр таких треков по точкам показывает кратковременные рывки скорости именно в такие моменты, как указано выше.
Методика спидсерферов такая — в зачет идет усредненная на 5-10 секунд скорость на прямолинейном отрезке. Это более адекватный параметр. Возможно, там еще отбрасываются «хвосты» по правилу трех сигм. У них есть специальный софт для анализа треков и участники просто присылают свои треки, а результаты уже выдаются софтом.
У мобильных приложений далеко не у всех заложена хоть какая-то фильтрация. Многие выводят напрямую то, что прилетело с чипа.
Я далеко не все смотрел, из точно фильтрующих видел meRun (для андроида, для Blackberry пользуюсь ей же, там называется CascaRun). Правда, описания алгоритма фильтрации не знаю. Но какие-то настройки фильтров там есть.
Для компа сам писал анализатор треков. Там много всяких фильтров для прочистки треков и удаления недостоверных (в т.ч. и по скорости) точек и подсчета статистики.
А если потребуется еще и маршруты строить, то тут теория графов в полный рост…
Так что или не зарекаться что никогда не понадобиться, или заранее исключить для себя определенные области разработки.
Так что более чем понимаю такое решение :-)
Правда, я равнодушен к визуальным финтифлюшкам, не люблю писать интерфейсы, люблю глубокий backend и получаю удовольствие от отладки системным отладчиком в зеленом экране (эмулятор терминала IBM5250)
Есть мобильные приложения — спортвные трекеры. Например, катаемся на горных лыжах, на телефоне запущено такое приложение. По итогу оно нам показывает суммарный набор-потерю высоты, сколько по расстоянию накатали, максимальную скорость на спуске. Так вот периодически люди (обычно новички) в профильных форумах начинают хватстаться что у них где-то там максимальная скорость была аж 120км/ч (порядок величин такой). при том, что такая скорость характерна для спортсменов на соревнованиях по скоростному спуску на этапах КМ. Но те-то едут в обтекаемых комбезах в низкой аэродинамической стойке на 2+ м спусковых лыжах и по очень жесткой трассе. Для любителя в куртке и широких штанах на обычных лыжах такое в принципе недостижимо.
Да, такая цифра может придти с чипа, но надо понимать откуда она взялась и как соотносится с реальностью. На тему измерения скорости с помощью GPS написано много статей с разбором в каких ситуациях какая погрешность возможна. Есть сообщество спидсерферов (speedsurfing), которые измеряют скорость с помощью GPS и сравнивают ее с другими — у них разработаны методики записи и обработки треков для получения адекватных сравнимых величин.
Но во все это надо вникать, разбираться. А в мобильную разработку пришло огромное количество… даже не знаю как назвать… людей, которые больше озабочены проблемами монетизации, чем реальной полезностью своей разработки.
Второй пример, с теми же трекерами. Велсипед. Человек покатался по парку (условно) и хвастается что у него суммарный набор высоты аж полтора километра. Ага. На 30-50 километров пути. Родной, откуда? Ты в Альпах через перевалы катался?
Опять нужно понимать, что точность определения высоты в силу физики процесса в GPS на порядок ниже точности определения координат. И в отсутствии барометрического альтиметра в приборе высота даже стоя на месте будет «плавать» и накручивать «суммарный набор». А при наличии оного его нужно регулярно калибровать.
Кроме того, суммарный набор неплохо накручиватеся на мелких кочках. Метр туда, метр сюда, глядишь и полтора километра набежало.
Все это нужно фильтровать и указывать что набрал столько-то при таких-то настройках (скажем, не учитывал наборы на уклонах меньше одного градуса, не учитывал единичные перепады менее полутора метров и т.п.)
Это как раз не удивительно. Физика суть наука описательная. И в ней главное понимать как оно все между собой взаимодействует на некотором интуитивном уровне, чем уметь на каждый случай написать формулу для получения нужного ответа.
Есть у меня знакомый, занимается репетиторством по физике. Так вот у него методика сторится на том, что сналала все описывается «на пальцах», без формул. Затем вводятся понятия «базовых величин» (расстояние, время, температура, масса...) Затем переход от базовых к величинам производным (как из рассотяния и времени получить скорость и т.п.). А затем уже то, что описано на пальцах описывается формулами.
Когда он эту методику начал применять на практике, то был сам поражен насколько быстро те, кому физика в школе ну совсем никак не лезет в голову, начинали понимать ее суть и прогрессировать.