такие решения с GPS есть, про них упоминалось мельком в статье. Но GPS в условиях стадионов работает плохо, погрешность может доходить до десятков метров. Мы решили пойти по пути работы с видео, т.к. это более универсально и позволяет получить больше данных + можно сопоставить каждый элемент статистики с моментом на видео, для дальнейшего анализа тренером и командой.
вести съемку сверху в теории можно, но сложнее/дороже технически + требует своего решения под архитектуру каждого стадиона. Текущий сетап с 4 камерами позволяет получить очень широкий угол обзора по каждому игроку и пока устраивает нас
для бекенда Java/Spring, ML часть в основном на питоне, софт для работы с видео – C++. Выпуск фреймворка в формате SDK пока не планировали, не видим пока тут большой потребности у рынка, но в планах много новых продуктовых решений на базе этих технологий
по этому матчу мы считали только фитнес (дистанция/скорость). Номера были различимы, поэтому все прошло успешно) Но в целом есть сложные матчи, где из-за снега/ветра невозможно различить игрока на поле. В таких условиях могут быть проблемы. Но пока такие матчи скорее исключение, чем правило
Какие технические параметры можете раскрыть? СУБД/Расчет статистики/Объем данных за матч(видео/обработанные данные)
на базу сейчас супер нагрузки нет, используем Postgresql. Каждый матч – это порядка 500Gb видео
Что включаете в аналитику? Тепловые карты, касания мяча, фитнес вижу. Анализ передач, показатели прессинга, xG? По вратарям какую статистику даёте?
сейчас автоматически считаем дистанцию/скорость, строим тепловые карты передвижений, количество рывков, время в разных скоростных режимах. В ближайших планах добавить автоматический расчет статистики по передачам/голевым моментам/единоборствам/навесам/etc. По вратарям сейчас ту же, что и для других игроков, но работаем надо добавлением параметров
В последнем проекте использовал haml и словил оргазм. На сайте haml ссылка на scss, я посмотрел и скоро перепишу свой css с его помощью.
А вопрос возник потому что вы написали про compass, как я понял из беглого прочтения Readme на github, эта штука тоже работает с CSS. В чем отличие sass-lang.com/ от compass?
>> Когда пишется админка, модели и тесты для них, как правило, уже имеются, скаффолдинг тут каким боком?
Пример из жизни — я разрабатываю финансовую программу в которой много однотипных справочников: сотрудники; должности; автомобили; модели автомобилей; типы кузовов автомобилей и т.п. Идея скаффолдинга отлично вписывается в этот проект.
>> Мне ближе подход, когда я генерирую минимальный функционал и дописываю его, чем допиливаю скаффолд.
Тоже отличный подход, оправданный на многих проектах. В этом случае на помощь приходят кастомные генераторы.
Скаффолдинг может оказаться полезным когда вы создаёте много однотипных страниц, например при написании админки к большому информационному порталу.
Что касается TDD — это хорошая практика использовать генераторы при написании кода. Например вы пишете тест, потом генерируете необходимые файлы, немного кастомизируете и вуаля.
Пример того как это выглядит в жизни, можно посмотреть здесь railscasts.com/episodes/155-beginning-with-cucumber.
Да, на эти данные тоже есть запрос, в следующих версиях думаем про добавление автоматического расчета и этих параметров.
Со Спартаком работаем, да)
такие решения с GPS есть, про них упоминалось мельком в статье. Но GPS в условиях стадионов работает плохо, погрешность может доходить до десятков метров. Мы решили пойти по пути работы с видео, т.к. это более универсально и позволяет получить больше данных + можно сопоставить каждый элемент статистики с моментом на видео, для дальнейшего анализа тренером и командой.
вести съемку сверху в теории можно, но сложнее/дороже технически + требует своего решения под архитектуру каждого стадиона. Текущий сетап с 4 камерами позволяет получить очень широкий угол обзора по каждому игроку и пока устраивает нас
для бекенда Java/Spring, ML часть в основном на питоне, софт для работы с видео – C++. Выпуск фреймворка в формате SDK пока не планировали, не видим пока тут большой потребности у рынка, но в планах много новых продуктовых решений на базе этих технологий
по этому матчу мы считали только фитнес (дистанция/скорость). Номера были различимы, поэтому все прошло успешно) Но в целом есть сложные матчи, где из-за снега/ветра невозможно различить игрока на поле. В таких условиях могут быть проблемы. Но пока такие матчи скорее исключение, чем правило
на базу сейчас супер нагрузки нет, используем Postgresql. Каждый матч – это порядка 500Gb видео
сейчас автоматически считаем дистанцию/скорость, строим тепловые карты передвижений, количество рывков, время в разных скоростных режимах. В ближайших планах добавить автоматический расчет статистики по передачам/голевым моментам/единоборствам/навесам/etc. По вратарям сейчас ту же, что и для других игроков, но работаем надо добавлением параметров
Исправил.
Добавил несколько фишек в свой арсенал.
А вопрос возник потому что вы написали про compass, как я понял из беглого прочтения Readme на github, эта штука тоже работает с CSS. В чем отличие sass-lang.com/ от compass?
Нет не доводилось, можете описать его суть в двух словах?
Пример из жизни — я разрабатываю финансовую программу в которой много однотипных справочников: сотрудники; должности; автомобили; модели автомобилей; типы кузовов автомобилей и т.п. Идея скаффолдинга отлично вписывается в этот проект.
>> Мне ближе подход, когда я генерирую минимальный функционал и дописываю его, чем допиливаю скаффолд.
Тоже отличный подход, оправданный на многих проектах. В этом случае на помощь приходят кастомные генераторы.
Что касается TDD — это хорошая практика использовать генераторы при написании кода. Например вы пишете тест, потом генерируете необходимые файлы, немного кастомизируете и вуаля.
Пример того как это выглядит в жизни, можно посмотреть здесь railscasts.com/episodes/155-beginning-with-cucumber.