> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/trips.md).

# Поездки

Записи о поездках транспорта, полученные из сырых телематических данных. Включают время начала и окончания, расстояние, статистику скорости и определение зон

Преобразование Поездки обрабатывает сырые телематические данные в отдельные записи поездок транспортных средств. Каждая строка в `processed_common_data.trips` представляет одну полную Поездка: где она началась и закончилась, сколько времени это заняло, какое расстояние проехало транспортное средство и из каких зон оно выехало или в какие прибыло.

Встроенное преобразование выполняется каждые 8 часов и охватывает скользящее 12-часовое окно Сырые данные. При каждом запуске ранее рассчитанные записи для этого окна заменяются новым расчетом, поэтому таблица всегда отражает последние доступные данные.

{% hint style="info" %}

* Данные в этой таблице могут быть давностью до 8 часов, отражая последний завершенный запуск.
* Все временные метки хранятся в UTC.
  {% endhint %}

## Выведите таблицу: processed\_common\_data.trips

Каждая строка представляет одну проверенную поездку транспортного средства. Таблица имеет ключ по `device_id` и `время начала Поездка`.

<table><thead><tr><th width="215">Поле</th><th width="115">Тип</th><th>Описание</th></tr></thead><tbody><tr><td><code>device_id</code></td><td>integer</td><td>Идентификатор устройства. Чтобы получить метку Объект, присоедините к <code>raw_business_data.objects</code> по <code>device_id</code> where <code>is_deleted = false</code> чтобы избежать размножения строк из-за исторических назначений устройств.</td></tr><tr><td><code>время начала Поездка</code></td><td>метка времени</td><td>Время начала Поездки. Определяется по первой точке нового сегмента Движения после стоянки или разрыва данных.</td></tr><tr><td><code>trip_end_time</code></td><td>метка времени</td><td>Время, когда Поездка завершилась. Установите на момент, когда устройство перешло из состояния Движется в остановку, которая длилась не менее 5 минут.</td></tr><tr><td><code>длительность Поездки</code></td><td>текст</td><td>Длительность поездки в формате <code>HH:MI:SS</code>.</td></tr><tr><td><code>поездка_длительность_в_секундах</code></td><td>numeric</td><td>Поездка, длительность в секундах. Используйте это поле для арифметических вычислений.</td></tr><tr><td><code>trip_distance_meters</code></td><td>numeric</td><td>Общая дистанция поездки в метрах, рассчитанная по линейной геометрии PostGIS, построенной по всем точкам поездки.</td></tr><tr><td><code>avg_speed</code></td><td>numeric</td><td>Средняя скорость по всем точкам поездки, в км/ч.</td></tr><tr><td><code>max_speed</code></td><td>numeric</td><td>Максимальная скорость, зафиксированная во время поездки, км/ч.</td></tr><tr><td><code>min_speed</code></td><td>numeric</td><td>Минимальная скорость, зафиксированная во время поездки, в км/ч.</td></tr><tr><td><code>latitude_start</code></td><td>numeric</td><td>Широта первой точки поездки, в градусах.</td></tr><tr><td><code>longitude_start</code></td><td>numeric</td><td>Долгота первой точки поездки, в градусах.</td></tr><tr><td><code>altitude_start</code></td><td>numeric</td><td>Высота в начале поездки, в метрах над уровнем моря.</td></tr><tr><td><code>latitude_end</code></td><td>numeric</td><td>Широта последней точки поездки, в градусах.</td></tr><tr><td><code>longitude_end</code></td><td>numeric</td><td>Долгота последней точки поездки, в градусах.</td></tr><tr><td><code>altitude_end</code></td><td>numeric</td><td>Высота в конце Поездка, в метрах над уровнем моря.</td></tr><tr><td><code>точки в поездке</code></td><td>integer</td><td>Количество необработанных телематических точек, включенных в поездку. Минимум 2 для корректной поездки.</td></tr><tr><td><code>start_zone</code></td><td>текст</td><td>Название зоны, содержащей точку начала поездки, если таковая есть. Null, если точка начала не попадает в определенную зону.</td></tr><tr><td><code>end_zone</code></td><td>текст</td><td>Название Зона, которая содержит конечную точку поездки, если таковая есть. Null, если конечная точка не попадает в определенную зону.</td></tr></tbody></table>

Примеры ниже показывают распространенные шаблоны запросов. Базовый запрос возвращает записи поездок за последние 7 дней, отсортированные по устройству и времени начала. Второй пример соединяется с `raw_business_data.objects` чтобы включить метку Объект, понятную человеку, рядом с каждой Поездка.

{% tabs %}
{% tab title="Базовый запрос поездки" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    trip_start_time,
    время окончания поездки,
    длительность поездки,
    trip_distance_meters,
    avg_speed,
    start_zone,
    end_zone
ИЗ processed_common_data.Поездки
WHERE trip_start_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY device_id, Поездка_start_time;
```

{% endcode %}
{% endtab %}

{% tab title="С меткой объекта" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    t.device_id,
    o.object_label,
    t.trip_start_time,
    время окончания поездки,
    t.trip_distance_meters,
    t.avg_speed,
    t.start_zone,
    t.end_zone
FROM processed_common_data.trips t
LEFT JOIN raw_business_data.objects o ON o.device_id = t.device_id
ГДЕ t.trip_start_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY t.device_id, t.trip_start_time;
```

{% endcode %}
{% endtab %}
{% endtabs %}

## Как строятся поездки

Запись Поездка — это не сырые данные устройства, а производная сущность, собранная из сотен\
отдельных телематических точек. Преобразование работает через Сырые данные поэтапно:\
сначала определяя, какие точки стоит оставить, затем классифицируя статус Движение каждой точки,\
затем группируя точки в сегменты Поездка и, наконец, вычисляя агрегированные метрики, которые\
появляются в выходной таблице. Понимание этого процесса помогает вам правильно интерпретировать результаты\
и понимать, когда настройки по умолчанию нужно корректировать для вашего Автопарка.

Вот шаги алгоритма, который формирует запись о Поездка:

{% stepper %}
{% step %}

#### **Сбор и очистка входных данных**

Преобразование считывает данные за последние 12 часов из двух исходных таблиц:

* `Мониторинг_data_core` для показаний положения и движения
* `состояния` для аппаратного флага движения, который отправляет каждый трекер

Точки фильтруются перед любой дальнейшей обработкой:

* Записи с нулевыми координатами отбрасываются.
* Точки, у которых меньше 3 спутников, исключаются из набора GNSS.
* Точки LBS (`спутников = -1`) являются исключением: они пропускаются для отдельной обработки на следующем шаге, поскольку положения базовой станции требуют других проверок на корректность, прежде чем они смогут участвовать в определении поездки.
  {% endstep %}

{% step %}

#### **Решение о том, представляет ли каждая точка движение**

Каждой точке присваивается один из трех статусов:

* `Движется`: скорость равна или выше 3 km/h, а либо расстояние от предыдущей точки превышает 50 метров, либо активен аппаратный флаг движения трекера. Оба условия предотвращают ложные срабатывания: проверка расстояния отфильтровывает скачки скорости, а аппаратный флаг улавливает реальное движение на малой скорости, которое одно лишь расстояние могло бы пропустить.
* `Остановился`: скорость ниже порога или расстояния недостаточно.
* `Стоит`: для этой точки нет показания скорости.

Точки LBS проходят дополнительную проверку перед получением статуса. Любая точка LBS, для которой расчетная скорость между последовательными позициями превышает 200 km/h, отбрасывается как артефакт позиционирования. Точка LBS, которая проходит эту проверку и непосредственно следует за точкой GNSS, может сформировать собственный одноточечный сегмент Поездки, охватывая случаи, когда устройство в середине Поездки переходит с спутникового позиционирования на позиционирование по сотовым вышкам. Все остальные недопустимые точки LBS удаляются.
{% endstep %}

{% step %}

#### Группировка точек в Поездки

Поскольку каждая точка имеет статус движения, преобразование определяет границы Поездки. Новая Поездка начинается, когда:

* Устройство создает свою первую точку данных в окне обработки.
* Движение возобновляется после стоянки, удовлетворяющей условиям (минимальная длительность стоянки превышена).
* Движение возобновляется после разрыва данных (таймаут превышен).

Поездка заканчивается, когда:

* Устройство было непрерывно в состоянии Остановился в течение минимальной длительности стоянки.
* Возникает разрыв данных длительностью таймаута, пока устройство не Движется.

Пороги, которые управляют этими границами, приведены в [Параметры конфигурации](#configuration-parameters) справочнике ниже.
{% endstep %}

{% step %}

#### Вычисление выходных метрик

После того как границы поездки установлены, все точки каждой поездки агрегируются в одну строку вывода:

* `trip_distance_meters`: полученная из линейной геометрии PostGIS, построенной по упорядоченной последовательности точек с использованием `ST_MakeLine`.
* `avg_speed`, `max_speed`, `min_speed`: вычисляется по всем точкам в поездке.
* `latitude_start`, `longitude_start`, `latitude_end`, `longitude_end`: берется из первой и последней точек последовательности.
* `start_zone`, `end_zone`: заполняется путем сопоставления начальных и конечных координат с `processed_common_data.zones_geom`. Совпадение требует, чтобы точка находилась точно внутри границы зоны; буфер не применяется.
  {% endstep %}

{% step %}

#### Фильтрация шума перед записью результатов

Не каждый сегмент поездки, который определяет алгоритм, стоит сохранять. Короткие сегменты, вызванные кратковременным восстановлением GPS, неподвижными устройствами с периодическим дрейфом позиции или неполными данными на границе окна, отбрасываются. Поездка записывается в выходную таблицу только тогда, когда она одновременно соответствует всем следующим условиям:

| Условие                               | Порог                            |
| ------------------------------------- | -------------------------------- |
| Точки в поездке                       | Не менее 2                       |
| Максимальная зафиксированная скорость | Не менее 3 км/ч                  |
| Общая дистанция поездки               | Не менее 100 метров              |
| Время начала поездки                  | Должно быть определено (не null) |
| Время окончания поездки               | Должно быть определено (не null) |
| {% endstep %}                         |                                  |
| {% endstepper %}                      |                                  |

Следующие два справочных раздела содержат настраиваемые параметры и правила масштабирования Сырых данных,\
которые трансформация применяет внутри.

<details>

<summary>Параметры конфигурации</summary>

Эти пороговые значения определяют, как Поездки разделяются и проверяются. Это наиболее частые объекты настройки. См. [Настройка преобразования](#customizing-the-transformation) инструкции по их настройке в шаблоне рабочего процесса.

<table><thead><tr><th width="233">Параметр</th><th width="133">Значение по умолчанию</th><th>Описание</th></tr></thead><tbody><tr><td>Минимальная длительность стоянки</td><td>300 секунд (5 минут)</td><td>Стоянка короче этого значения не завершает текущую поездку. Считается, что устройство все еще находится в той же поездке.</td></tr><tr><td>Тайм-аут разрыва данных</td><td>1200 секунд (20 минут)</td><td>Если в течение этого времени данные не поступают, текущая поездка завершается, а при возобновлении передачи начинается новая.</td></tr><tr><td>Минимальная дистанция движения</td><td>50 метров</td><td>Точка должна находиться как минимум на таком расстоянии от предыдущей точки, чтобы считаться движением.</td></tr><tr><td>Минимальная скорость движения</td><td>3 km/h</td><td>Точки ниже этой скорости не классифицируются как движущиеся.</td></tr></tbody></table>

</details>

<details>

<summary>Масштабирование сырых данных</summary>

Сырые телематические данные из `Мониторинг_data_core` хранит значения координат и скорости как целые числа для эффективного хранения. Трансформация преобразует их в стандартные единицы перед обработкой.

| Поле                    | Делитель         | Результат                                  |
| ----------------------- | ---------------- | ------------------------------------------ |
| `latitude`, `longitude` | 10,000,000 (1e7) | Градусы (например, 554567890 → 55.456789°) |
| `высота`                | 10,000,000 (1e7) | Метры над уровнем моря                     |
| `speed`                 | 100 (1e2)        | км/ч (например, 6530 → 65.30 км/ч)         |

</details>

## Настройка преобразования

Трансформация Поездки по умолчанию отражает общую логику определения поездок Navixy. Если ваш операционный сценарий требует иного поведения, вы можете загрузить шаблон рабочего процесса в [Конструктор трансформаций](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder.md), изменить соответствующие узлы и запланировать скорректированный рабочий процесс как пользовательскую трансформацию в `processed_custom_data`.

{% hint style="warning" %}
Несколько узлов в рабочем процессе Поездки используют геометрические функции PostGIS и оконные функции (`LAG`, `FIRST_VALUE`, `LAST_VALUE`, `SUM OVER`). Для изменения этих узлов требуются уверенные знания SQL. Всегда предварительно просматривайте результат с помощью **Выполнить** кнопки в Transformation Builder перед планированием измененного рабочего процесса.
{% endhint %}

### Примеры настройки

Разверните разделы ниже, чтобы увидеть несколько примеров настройки для конкретных случаев.

<details>

<summary>Настройка порогов стоянки и разрыва</summary>

Используйте это, когда стандартный 5-минутный порог стоянки разделяет то, что должно быть одной непрерывной поездкой, на несколько записей — что часто встречается в городских маршрутах доставки с частыми короткими стоянками. Эта настройка также помогает, когда у устройств нерегулярные интервалы передачи данных и 20-минутный тайм-аут разрыва преждевременно завершает поездки.

Значения порогов жестко заданы как целочисленные константы в двух узлах Custom SQL:

1. Откройте **Флаги поездки** узел (`custom_9`). Найдите условие `parking_duration >= 300 * INTERVAL '1 second'`. Это встречается дважды в узле. Замените `300` на нужное вам значение в секундах в обоих местах. Например, чтобы требовать остановку длительностью 10 минут, используйте `600`.
2. В том же **Флаги поездки** узел (`custom_9`), найдите `time_diff >= 1200`. Затем откройте **Маркеры стоянок** узел (`custom_6`) и найдите там то же условие. Замените `1200` на нужное вам значение в секундах в обоих узлах. Например, чтобы допускать разрывы длительностью 30 минут, используйте `1800`.
3. Нажмите **Выполнить** для предварительного просмотра результата и убедитесь, что границы поездки соответствуют вашим операционным ожиданиям перед планированием.

</details>

<details>

<summary>Активация фильтрации LBS по расстоянию</summary>

Используйте это, когда ваш автопарк работает в районах с плохим покрытием GPS и точки LBS создают большие скачки координат — например, когда устройство теряет спутниковый сигнал и «прыгает» на вышку сотовой связи в нескольких километрах отсюда. Исключение этих точек дает более чистую геометрию поездки и более точные расчеты расстояния.

Шаблон рабочего процесса содержит заполнитель для этой проверки в **Обработанные LBS** узел (`custom_3`), но по умолчанию он неактивен. Столбец `distance_status` жестко задан и всегда возвращает `'VALID'` через заглушечное выражение `CASE WHEN 1 != 1 THEN 'EXCLUDED_DISTANCE' ELSE 'VALID' END`. Чтобы включить его:

1. Откройте **Обработанные LBS** Узел Custom SQL (`custom_3`) в Transformation Builder.
2. Замените заглушечную строку на реальное условие на основе `distance_meters`. Например, чтобы исключать точки LBS, расположенные более чем в 500 метрах от предыдущей точки:

```sql
   CASE
       WHEN point_type = 'LBS' AND distance_meters > 500
       THEN 'EXCLUDED_DISTANCE'
       ELSE 'VALID'
   END AS distance_status,
```

Порог от 200 до 1000 метров — разумный стартовый диапазон: используйте меньшее значение в районах с плотным покрытием вышек сотовой связи и большее там, где вышек мало.

3. Нажмите **Выполнить** для предварительного просмотра результата. Проверьте, сколько точек LBS теперь исключено и правильно ли выглядят оставшиеся поездки. При необходимости скорректируйте порог перед планированием.

</details>

<details>

<summary>Полное исключение точек LBS</summary>

Используйте это, когда ваш автопарк использует только GPS-устройства, которые никогда не формируют данные LBS, или когда вы хотите, чтобы записи поездок строились исключительно по подтвержденным позициям ГНСС.

1. Откройте **Основные данные** исходный узел (`telematics_1`, type: Сырые данные: Телематика). В **Условие фильтрации** поле, удалите `OR satellites = -1` из проверки спутников, изменив:

```
   event_id IN (2, 802, 803, 804, 811) AND latitude <> 0 AND longitude <> 0
   AND (satellites >= 3 OR satellites = -1)
```

на:

```
   event_id IN (2, 802, 803, 804, 811) AND latitude <> 0 AND longitude <> 0
   AND satellites >= 3
```

2. Удалите **Обработанные LBS** узел (`custom_3`) и the **Отфильтрованный LBS** узел (`custom_4`) из графа, вместе со всеми ребрами, соединенными с ними. Проведите новое ребро от **С расстоянием** узел (`custom_2`) к **Фильтр недопустимых** узел (`filter_1`) чтобы восстановить поток данных.
3. Откройте **Фильтр недопустимых** узел и замените оба существующих динамических условия одним прямым условием: `calculated_speed_kmh <= 200`. Исходные условия (`lbs_excluded_flag = 0` и `speed_status = 'VALID'`) ссылаются на столбцы, созданные удаленными узлами, и вызовут ошибку выполнения, если их оставить.
4. Нажмите **Выполнить** чтобы предварительно просмотреть результат. Проверьте, что количество точек и границы поездок выглядят корректно для ваших данных, прежде чем выполнять планирование.

</details>

### Использование шаблона рабочего процесса

Navixy предоставляет готовый шаблон рабочего процесса Поездки, который можно загрузить в Transformation Builder как отправную точку. Шаблон охватывает все этапы обработки, описанные на этой странице, от загрузки сырых данных до сопоставления с зонами и агрегации.

См. [Шаблоны](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md) страницу с инструкциями по загрузке, импорту и конфигурацией Узла Output для этого преобразования.

## Следующие шаги

* [**Общие преобразования**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations.md): Назад к индексу преобразований.
* [**Шаблоны**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md): Скачайте шаблон рабочего процесса Поездки и импортируйте его в Transformation Builder.
* [**Конструктор трансформаций**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder.md): Узнайте, как работать с визуальным редактором рабочего процесса, добавлять Узлы и просматривать результаты.
* [**Слой сырых данных**](/docs/analytics/ru/iot-query/schema-overview/bronze-layer.md): Изучите исходные таблицы, которые используются в трансформации Поездки: `Мониторинг_data_core`, `состояния`, и `zones_geom`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://navixy.com/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/trips.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.