спасибо! увидел другие библиотеки для решения серьезных задач, но с ними придется повозиться чуть подольше. В любом случае это увлекательный процесс. Здесь хотел опровергнуть свою же гипотезу о том, что химические задачи по-прежнему решают на листочке.
преимущество хотя бы в том, что мне не нужен PostGIS. Функции действительно совпадают, и это хорошо как и возможность использовать привычный аналитику SQL API. Почему вы решили, что медленнее и возможности меньше, я не понял.
можно и вашими методами считать, альтернатив много. Здесь нужно понимать, что кластер мы развернули не для одной конкретной задачи, а показали как можно сделать расчет без дополнительного копирования данных из существующего хранилища данных Hive в PostGIS (и прочее) в привычной среде Apache Spark, с которой взаимодействуем на ежедневной основе.
В отличие от PostGIS, Sedona производит пространственные расчеты «на лету», создавая пространственный индекс каждый раз заново, когда идет преобразование из spark dataframe в spatial rdd. Другими словами, пространственные данные нигде не хранятся в случае Sedona.
Выбор инструмента для обработки пространственных данных зависит от способа хранения и от их объема. Условно для работы с мегабайтами данных осваивать и настраивать новую среду Apache Spark+Sedona не имеет смысла, того же PostGIS будет вполне достаточно. Преимущество описанного метода расчета именно в возможности работы с большим объемом данных (гигабайты).
Помимо Scala есть варианты установки с Python (PySpark) и R (SparkR).
Выбор инструмента для обработки пространственных данных во многом зависит от способа хранения данных и от их объема. В нашем случае это несколько гигабайт только для одного дня для одного региона, которые хранятся в распределенном хранилище данных (Hive). Метод, описанный в статье, позволяет произвести нужные расчеты на кластере, не прибегая к дополнительным действиям по выборке, копированию данных на другие сервисы (PostrgeSQL/PostGIS и т.п.), созданию пространственного индекса на них.
Точных замеров по времени и скорости запросов в данной работе мы не проводили, и они напрямую зависят от текущей загруженности кластера. Вы можете ознакомиться с уже проведенными исследованиями, где рассчитаны метрики эффективности запросов, разобраны планы их обработки, приведены сравнения при использовании разных пространственных индексов здесь https://jiayuasu.github.io/files/paper/GeoSpark_Geoinformatica_2018.pdf
спасибо за комментарий! согласен, что твое решение компактнее, сам c модулем collections только недавно познакомился. У меня идет вызов функции h3.polyfill_resample() через h3pandas. В общем код не оптимизирован достаточно - это было мое первое знакомство с упомянутыми библиотеками, я пытался начинать с простого
здесь все зависит от фокуса тренировок конечно, можно попробовать делать и RAMP в течение сезона - он не такой изматывающий. Про 4V не слышал, можете ссылку скинуть?
пробовал, но только один раз, поэтому сравнивать было не с чем. RAMP тест короче, чем FTP и может переоценивать потенциальную мощность для длинных дистанций, больше подходит для оценки подготовки к коротким дистанциям.
FTP/kg - хорошая и наиболее распространенная метрика для оценки текущей физической формы спортсмена, я упомянул об альтернативных метриках, так как они не требуют максимальных усилий в день теста и соответственно более простые в исполнении
спасибо за интересную статью! попробовал использовать упомянутый метод с гексагонами для поиска своих популярных треков тренировок в пределах города - все работает и результаты корректные. Единственное вместо h3 ипользовал аналогичную H3-Pandas, так как она позволяет работать с мультиполигонами без дополнительных манипуляций
Спасибо за комментарий! Идея в основном заключалась в том, чтобы определить популярные участки без сторонних приложений и без полноценных ГИС программ. Согласен, что практического применения не так много, и это скорее ради картинки, но можно использовать как дополнительное средство поиска похожих тренировок или заездов (опять же не прибегая к помощи сторонних приложений или их платных функций, которые могут быть условно не доступны к примеру)
спасибо за комментарий! В этой статье я хотел рассказать только о том, как получить данные и подготовить их к дальнейшему анализу в удобных мне интерфейсах. Первое предложение только раскрывает для чего я все это начиная делать.
Собственно сам анализ и методы я постараюсь описать в следующих статьях. Та часть с графиком была исключительно для понимания адекватно ли выглядят подготовленные данные.
В любом случае спасибо за идеи и предложения, я возьму их на заметку
спасибо за внимательность! вы правы, я действительно пропустил двойку в уравнении. Должно быть так:
спасибо! увидел другие библиотеки для решения серьезных задач, но с ними придется повозиться чуть подольше. В любом случае это увлекательный процесс. Здесь хотел опровергнуть свою же гипотезу о том, что химические задачи по-прежнему решают на листочке.
добавил для удобства, если рассматривать каждую задачу отдельно
в университете уже был принцип Паули и правило Хунда, но в школе учили по "правилу трамвая"
в PostGIS мы тоже работаем и очевидно, что он распространен и популярен не просто так, но материал совсем не про это
преимущество хотя бы в том, что мне не нужен PostGIS. Функции действительно совпадают, и это хорошо как и возможность использовать привычный аналитику SQL API. Почему вы решили, что медленнее и возможности меньше, я не понял.
можно и вашими методами считать, альтернатив много. Здесь нужно понимать, что кластер мы развернули не для одной конкретной задачи, а показали как можно сделать расчет без дополнительного копирования данных из существующего хранилища данных Hive в PostGIS (и прочее) в привычной среде Apache Spark, с которой взаимодействуем на ежедневной основе.
В отличие от PostGIS, Sedona производит пространственные расчеты «на лету», создавая пространственный индекс каждый раз заново, когда идет преобразование из spark dataframe в spatial rdd. Другими словами, пространственные данные нигде не хранятся в случае Sedona.
Выбор инструмента для обработки пространственных данных зависит от способа хранения и от их объема. Условно для работы с мегабайтами данных осваивать и настраивать новую среду Apache Spark+Sedona не имеет смысла, того же PostGIS будет вполне достаточно. Преимущество описанного метода расчета именно в возможности работы с большим объемом данных (гигабайты).
Помимо Scala есть варианты установки с Python (PySpark) и R (SparkR).
Выбор инструмента для обработки пространственных данных во многом зависит от способа хранения данных и от их объема. В нашем случае это несколько гигабайт только для одного дня для одного региона, которые хранятся в распределенном хранилище данных (Hive). Метод, описанный в статье, позволяет произвести нужные расчеты на кластере, не прибегая к дополнительным действиям по выборке, копированию данных на другие сервисы (PostrgeSQL/PostGIS и т.п.), созданию пространственного индекса на них.
Точных замеров по времени и скорости запросов в данной работе мы не проводили, и они напрямую зависят от текущей загруженности кластера. Вы можете ознакомиться с уже проведенными исследованиями, где рассчитаны метрики эффективности запросов, разобраны планы их обработки, приведены сравнения при использовании разных пространственных индексов здесь https://jiayuasu.github.io/files/paper/GeoSpark_Geoinformatica_2018.pdf
спасибо за комментарий! согласен, что твое решение компактнее, сам c модулем collections только недавно познакомился. У меня идет вызов функции h3.polyfill_resample() через h3pandas. В общем код не оптимизирован достаточно - это было мое первое знакомство с упомянутыми библиотеками, я пытался начинать с простого
Лично беговые тренировки пока не анализировал, но думаю можно ориентироваться на соотношение пульса и темпа и отслеживать прогресс. Видел статью с анализом прогресса здесь https://towardsdatascience.com/analysis-of-runing-activities-from-garmin-watch-using-python-99609f83314e
Есть такая функция у гармина для некоторых устройств, когда он вычисляет время восстановления перед следующей тренировкой, учитывая результаты текущей и как организм с ней справился https://support.garmin.com/en-US/?faq=8ImmxVkZMh4EYYq5Zp2bR8#:~:text=Recovery time provides an estimate,your device has this feature.
стоит попробовать, спасибо за совет!
https://cyclingindoors.co.uk/the-sufferfest-full-frontal-4dp-test/
https://www.dcrainmaker.com/2017/10/hands-on-with-the-sufferfests-new-4dp-platform.html
здесь все зависит от фокуса тренировок конечно, можно попробовать делать и RAMP в течение сезона - он не такой изматывающий. Про 4V не слышал, можете ссылку скинуть?
пробовал, но только один раз, поэтому сравнивать было не с чем. RAMP тест короче, чем FTP и может переоценивать потенциальную мощность для длинных дистанций, больше подходит для оценки подготовки к коротким дистанциям.
FTP/kg - хорошая и наиболее распространенная метрика для оценки текущей физической формы спортсмена, я упомянул об альтернативных метриках, так как они не требуют максимальных усилий в день теста и соответственно более простые в исполнении
спасибо за интересную статью! попробовал использовать упомянутый метод с гексагонами для поиска своих популярных треков тренировок в пределах города - все работает и результаты корректные. Единственное вместо h3 ипользовал аналогичную H3-Pandas, так как она позволяет работать с мультиполигонами без дополнительных манипуляций
Спасибо за комментарий! Идея в основном заключалась в том, чтобы определить популярные участки без сторонних приложений и без полноценных ГИС программ. Согласен, что практического применения не так много, и это скорее ради картинки, но можно использовать как дополнительное средство поиска похожих тренировок или заездов (опять же не прибегая к помощи сторонних приложений или их платных функций, которые могут быть условно не доступны к примеру)
спасибо за комментарий! В этой статье я хотел рассказать только о том, как получить данные и подготовить их к дальнейшему анализу в удобных мне интерфейсах. Первое предложение только раскрывает для чего я все это начиная делать.
Собственно сам анализ и методы я постараюсь описать в следующих статьях. Та часть с графиком была исключительно для понимания адекватно ли выглядят подготовленные данные.
В любом случае спасибо за идеи и предложения, я возьму их на заметку