> 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/id/iot-query/schema-overview/transformation-layer/common-transformations/trips.md).

# Perjalanan

Catatan perjalanan kendaraan yang diturunkan dari data telematika mentah. Mencakup waktu mulai dan berakhir, jarak, statistik kecepatan, dan deteksi zona

Transformasi Perjalanan memproses data telematika mentah menjadi rekaman perjalanan kendaraan yang terpisah. Setiap baris dalam `processed_common_data.Perjalanan` merepresentasikan satu perjalanan lengkap: tempat perjalanan dimulai dan berakhir, berapa lama waktu yang dibutuhkan, seberapa jauh kendaraan menempuh jarak, dan dari zona mana kendaraan berangkat atau tiba.

Transformasi bawaan berjalan setiap 8 jam dan mencakup jendela data mentah bergulir selama 12 jam. Pada setiap kali berjalan, catatan yang sebelumnya dihitung untuk jendela tersebut digantikan dengan perhitungan baru, sehingga tabel selalu mencerminkan data terbaru yang tersedia.

{% hint style="info" %}

* Data dalam tabel ini mungkin berusia hingga 8 jam, yang mencerminkan eksekusi yang paling baru selesai.
* Semua cap waktu disimpan dalam UTC.
  {% endhint %}

## Tabel keluaran: processed\_common\_data.Perjalanan

Setiap baris mewakili satu perjalanan kendaraan yang tervalidasi. Tabel ini diindeks berdasarkan `device_id` dan `trip_start_time`.

<table><thead><tr><th width="215">Bidang</th><th width="115">Tipe</th><th>Deskripsi</th></tr></thead><tbody><tr><td><code>device_id</code></td><td>bilangan bulat</td><td>Pengidentifikasi perangkat. Untuk mendapatkan label pelacak, gabungkan ke <code>raw_business_data.objects</code> aktif <code>device_id</code> di mana <code>is_deleted = false</code> untuk menghindari penggandaan baris akibat penetapan perangkat historis.</td></tr><tr><td><code>trip_start_time</code></td><td>stempel waktu</td><td>Waktu saat perjalanan dimulai. Ditentukan oleh titik pertama dari segmen Gerakan baru setelah perhentian yang memenuhi syarat atau celah data.</td></tr><tr><td><code>trip_end_time</code></td><td>stempel waktu</td><td>Waktu saat perjalanan berakhir. Diatur pada saat perangkat beralih dari Bergerak ke berhenti yang berlangsung setidaknya 5 menit.</td></tr><tr><td><code>trip_duration</code></td><td>teks</td><td>Durasi perjalanan diformat sebagai <code>HH:MI:SS</code>.</td></tr><tr><td><code>trip_duration_seconds</code></td><td>numeric</td><td>Durasi perjalanan dalam detik. Gunakan field ini untuk perhitungan aritmetika.</td></tr><tr><td><code>trip_distance_meters</code></td><td>numeric</td><td>Total jarak perjalanan dalam meter, dihitung dari geometri garis PostGIS yang dibangun dari semua titik dalam perjalanan.</td></tr><tr><td><code>avg_speed</code></td><td>numeric</td><td>Kecepatan rata-rata di seluruh titik dalam perjalanan, dalam km/h.</td></tr><tr><td><code>max_speed</code></td><td>numeric</td><td>Kecepatan maksimum yang tercatat selama perjalanan, dalam km/h.</td></tr><tr><td><code>min_speed</code></td><td>numeric</td><td>Kecepatan minimum yang tercatat selama perjalanan, dalam km/h.</td></tr><tr><td><code>latitude_start</code></td><td>numeric</td><td>Lintang titik pertama perjalanan, dalam derajat.</td></tr><tr><td><code>longitude_start</code></td><td>numeric</td><td>Bujur titik pertama perjalanan, dalam derajat.</td></tr><tr><td><code>altitude_start</code></td><td>numeric</td><td>Ketinggian pada awal perjalanan, dalam meter di atas permukaan laut.</td></tr><tr><td><code>latitude_end</code></td><td>numeric</td><td>Lintang titik terakhir perjalanan, dalam derajat.</td></tr><tr><td><code>longitude_end</code></td><td>numeric</td><td>Bujur titik terakhir perjalanan, dalam derajat.</td></tr><tr><td><code>altitude_end</code></td><td>numeric</td><td>Ketinggian pada akhir perjalanan, dalam meter di atas permukaan laut.</td></tr><tr><td><code>points_in_trip</code></td><td>bilangan bulat</td><td>Jumlah titik telematika mentah yang disertakan dalam perjalanan. Minimum 2 untuk perjalanan yang valid.</td></tr><tr><td><code>start_zone</code></td><td>teks</td><td>Nama zona Perimeter yang berisi titik awal perjalanan, jika ada. Null jika titik awal tidak berada dalam zona yang ditentukan.</td></tr><tr><td><code>end_zone</code></td><td>teks</td><td>Nama zona Perimeter yang berisi titik akhir perjalanan, jika ada. Null jika titik akhir tidak berada dalam zona yang ditentukan.</td></tr></tbody></table>

Contoh di bawah menunjukkan pola kueri yang umum. Kueri dasar mengembalikan catatan perjalanan untuk 7 hari terakhir yang diurutkan berdasarkan perangkat dan waktu mulai. Contoh kedua bergabung dengan `raw_business_data.objects` untuk menyertakan label Pelacak yang mudah dibaca manusia di samping setiap perjalanan.

{% tabs %}
{% tab title="Kueri perjalanan dasar" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    trip_start_time,
    trip_end_time,
    durasi_perjalanan,
    jarak_perjalanan_meter,
    avg_speed,
    zona mulai,
    end_zone
DARI processed_common_data.Perjalanan
WHERE trip_start_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY device_id, trip_start_time;
```

{% endcode %}
{% endtab %}

{% tab title="Dengan label pelacak" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    t.device_id,
    o.label objek,
    t.trip_start_time,
    t.trip_end_time,
    t.trip_distance_meters,
    t.avg_speed,
    t.start_zone,
    t.end_zone
FROM processed_common_data.Perjalanan t
LEFT JOIN raw_business_data.objects o ON o.device_id = t.device_id
WHERE t.trip_start_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY t.device_id, t.trip_start_time;
```

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

## Bagaimana perjalanan dibangun

Catatan perjalanan bukanlah pembacaan mentah perangkat, melainkan entitas turunan yang dirakit dari ratusan\
poin telematika individual. Transformasi bekerja melalui data mentah dalam beberapa tahap:\
pertama menentukan titik mana yang layak dipertahankan, kemudian mengklasifikasikan status gerakan setiap titik,\
lalu mengelompokkan titik ke dalam segmen perjalanan, dan akhirnya menghitung metrik agregat yang\
muncul di tabel output. Memahami proses ini membantu Anda menafsirkan hasil dengan benar\
dan mengenali kapan pengaturan bawaan perlu disesuaikan untuk armada Anda.

Berikut adalah langkah-langkah algoritme yang membentuk catatan perjalanan:

{% stepper %}
{% step %}

#### **Mengumpulkan dan membersihkan input**

Transformasi membaca 12 jam terakhir data dari dua tabel sumber:

* `tracking_data_core` untuk pembacaan posisi dan gerakan
* `states` untuk penanda gerakan perangkat keras yang dikirim setiap pelacak

Titik difilter sebelum pemrosesan lebih lanjut:

* Rekaman dengan koordinat nol dihapus.
* Titik dengan kurang dari 3 satelit dikeluarkan dari set GNSS.
* Titik LBS (`satelit = -1`) adalah pengecualian: titik tersebut diteruskan untuk penanganan terpisah pada langkah berikutnya, karena posisi menara seluler memerlukan pemeriksaan validitas yang berbeda sebelum dapat berpartisipasi dalam deteksi perjalanan.
  {% endstep %}

{% step %}

#### **Menentukan apakah setiap titik merepresentasikan gerakan**

Setiap titik diklasifikasikan ke dalam salah satu dari tiga status:

* `bergerak`: kecepatan berada pada atau di atas 3 km/jam, dan jarak dari titik sebelumnya melebihi 50 meter atau penanda gerakan perangkat keras pelacak aktif. Kedua kondisi ini mencegah positif palsu: pemeriksaan jarak menyaring lonjakan kecepatan, dan penanda perangkat keras menangkap gerakan kecepatan rendah yang nyata yang tidak akan terlewat oleh jarak saja.
* `berhenti`: kecepatan berada di bawah ambang batas atau jaraknya tidak mencukupi.
* `parkir`: tidak ada pembacaan kecepatan yang tersedia untuk titik ini.

Titik LBS melalui pemeriksaan tambahan sebelum menerima status. Setiap titik LBS di mana kecepatan yang dihitung antara posisi berurutan melebihi 200 km/jam dibuang sebagai artefak penentuan posisi. Titik LBS yang lolos pemeriksaan ini dan langsung mengikuti titik GNSS dapat membentuk segmen perjalanan satu titik tersendiri, mencakup kasus saat perangkat beralih dari penentuan posisi satelit ke penentuan posisi menara seluler di tengah perjalanan. Semua titik LBS tidak valid lainnya dihapus.
{% endstep %}

{% step %}

#### Mengelompokkan titik ke dalam perjalanan

Dengan setiap titik membawa status Gerakan, transformasi mengidentifikasi batas perjalanan. Perjalanan baru dimulai ketika:

* Perangkat menghasilkan titik data pertamanya dalam jendela pemrosesan.
* Gerakan dilanjutkan kembali setelah berhenti yang memenuhi syarat (durasi parkir minimum terlampaui).
* Gerakan dilanjutkan kembali setelah celah data (waktu habis terlampaui).

Perjalanan berakhir ketika:

* Perangkat telah berhenti terus-menerus selama durasi parkir minimum.
* Celah data selama durasi waktu habis terjadi saat perangkat tidak Bergerak.

Ambang batas yang mengontrol batas-batas ini tercantum dalam [Parameter konfigurasi](#configuration-parameters) referensi di bawah.
{% endstep %}

{% step %}

#### Menghitung metrik keluaran

Setelah batas perjalanan ditetapkan, semua titik dalam setiap perjalanan digabungkan ke dalam satu baris keluaran:

* `trip_distance_meters`: diturunkan dari geometri garis PostGIS yang dibangun dari urutan titik yang diurutkan menggunakan `ST_MakeLine`.
* `avg_speed`, `max_speed`, `min_speed`: dihitung dari seluruh titik dalam perjalanan.
* `latitude_start`, `longitude_start`, `latitude_end`, `longitude_end`: diambil dari titik pertama dan terakhir dalam urutan.
* `start_zone`, `end_zone`: diisi dengan mencocokkan koordinat awal dan akhir dengan `processed_common_data.zones_geom`. Kecocokan mengharuskan titik berada tepat di dalam batas zona; tidak ada buffer yang diterapkan.
  {% endstep %}

{% step %}

#### Menyaring noise sebelum menulis hasil

Tidak setiap segmen perjalanan yang diidentifikasi algoritme layak dipertahankan. Segmen pendek yang disebabkan oleh pemulihan GPS singkat, perangkat diam dengan pergeseran posisi sesekali, atau data yang tidak lengkap di batas jendela dibuang. Perjalanan hanya ditulis ke tabel keluaran ketika memenuhi semua kondisi berikut secara bersamaan:

| Kondisi                          | Ambang batas                  |
| -------------------------------- | ----------------------------- |
| Titik dalam perjalanan           | Setidaknya 2                  |
| Kecepatan maksimum yang tercatat | Setidaknya 3 km/jam           |
| Jarak tempuh total               | Setidaknya 100 meter          |
| Waktu mulai perjalanan           | Harus ditentukan (bukan null) |
| Waktu akhir perjalanan           | Harus ditentukan (bukan null) |
| {% endstep %}                    |                               |
| {% endstepper %}                 |                               |

Dua bagian referensi berikut berisi parameter yang dapat dikonfigurasi dan aturan penskalaan data mentah yang diterapkan transformasi secara internal.

<details>

<summary>Parameter konfigurasi</summary>

Ambang batas ini mengatur cara perjalanan dipisahkan dan divalidasi. Ini adalah target yang paling umum untuk kustomisasi. Lihat [Menyesuaikan transformasi](#customizing-the-transformation) untuk petunjuk tentang cara menyesuaikannya di templat alur kerja.

<table><thead><tr><th width="233">Parameter</th><th width="133">Nilai default</th><th>Deskripsi</th></tr></thead><tbody><tr><td>Durasi parkir minimum</td><td>300 detik (5 menit)</td><td>Perhentian yang lebih singkat dari ini tidak mengakhiri perjalanan saat ini. Perangkat dianggap masih berada dalam perjalanan yang sama.</td></tr><tr><td>Batas waktu jeda data</td><td>1200 detik (20 menit)</td><td>Jika tidak ada data yang masuk selama durasi ini, perjalanan saat ini berakhir dan perjalanan baru dimulai saat data kembali masuk.</td></tr><tr><td>Jarak minimum gerakan</td><td>50 meter</td><td>Titik harus berada setidaknya sejauh ini dari titik sebelumnya agar dihitung sebagai gerakan.</td></tr><tr><td>Kecepatan minimum gerakan</td><td>3 km/jam</td><td>Titik di bawah kecepatan ini tidak diklasifikasikan sebagai bergerak.</td></tr></tbody></table>

</details>

<details>

<summary>Penskalaan nilai mentah</summary>

Data telematika mentah dari `tracking_data_core` menyimpan nilai koordinat dan kecepatan sebagai bilangan bulat untuk penyimpanan yang efisien. Transformasi mengonversinya ke satuan standar sebelum diproses.

| Bidang                  | Pembagi          | Hasil                                  |
| ----------------------- | ---------------- | -------------------------------------- |
| `latitude`, `longitude` | 10.000.000 (1e7) | Derajat (mis., 554567890 → 55,456789°) |
| `Ketinggian`            | 10.000.000 (1e7) | Meter di atas permukaan laut           |
| `Kecepatan`             | 100 (1e2)        | km/jam (mis., 6530 → 65,30 km/jam)     |

</details>

## Menyesuaikan transformasi

Transformasi Perjalanan bawaan mencerminkan logika deteksi perjalanan serbaguna Navixy. Jika skenario operasional Anda memerlukan perilaku yang berbeda, Anda dapat memuat templat alur kerja ke [Builder transformasi](/docs/analytics/id/iot-query/schema-overview/transformation-layer/transformation-builder.md), mengubah node yang relevan, dan menjadwalkan alur kerja yang disesuaikan sebagai transformasi kustom di `processed_custom_data`.

{% hint style="warning" %}
Beberapa node dalam alur kerja Perjalanan menggunakan fungsi geometri PostGIS dan fungsi jendela (`LAG`, `FIRST_VALUE`, `LAST_VALUE`, `SUM OVER`). Mengubah node-node ini memerlukan pengetahuan SQL yang kuat. Selalu lihat pratinjau hasilnya menggunakan **Jalankan** tombol di Pembuat transformasi sebelum menjadwalkan alur kerja yang dimodifikasi.
{% endhint %}

### Contoh kustomisasi

Perluas bagian di bawah untuk melihat beberapa contoh kustomisasi berbasis kasus.

<details>

<summary>Menyesuaikan ambang batas perhentian dan jeda</summary>

Gunakan ini ketika ambang batas parkir default 5 menit memisahkan apa yang seharusnya menjadi satu perjalanan berkelanjutan menjadi beberapa rekaman — umum pada rute pengiriman perkotaan dengan perhentian singkat yang sering. Penyesuaian ini juga membantu ketika perangkat memiliki interval pelaporan yang tidak teratur dan batas waktu jeda 20 menit mengakhiri perjalanan terlalu dini.

Nilai ambang batas ditetapkan sebagai konstanta integer di dua node SQL kustom:

1. Buka **Tanda perjalanan** node (`custom_9`). Temukan kondisi `parking_duration >= 300 * INTERVAL '1 second'`. Ini muncul dua kali di node. Ganti `300` dengan nilai target Anda dalam detik di kedua tempat. Misalnya, untuk mensyaratkan perhentian 10 menit, gunakan `600`.
2. Pada node yang sama **Tanda perjalanan** node (`custom_9`), temukan `time_diff >= 1200`. Lalu buka **Penanda parkir** node (`custom_6`) dan temukan kondisi yang sama di sana. Ganti `1200` dengan nilai target Anda dalam detik di kedua node. Misalnya, untuk menoleransi jeda 30 menit, gunakan `1800`.
3. Klik **Jalankan** untuk melihat pratinjau hasilnya dan memastikan bahwa batas perjalanan sesuai dengan ekspektasi operasional Anda sebelum dijadwalkan.

</details>

<details>

<summary>Mengaktifkan penyaringan LBS berbasis jarak</summary>

Gunakan ini ketika armada Anda beroperasi di area dengan cakupan GPS yang buruk dan titik LBS menimbulkan lonjakan koordinat yang besar — misalnya, perangkat kehilangan sinyal satelit dan melompat ke menara seluler beberapa kilometer jauhnya. Mengecualikan titik-titik ini menghasilkan geometri perjalanan yang lebih bersih dan perhitungan jarak yang lebih akurat.

Templat alur kerja menyertakan penampung untuk pemeriksaan ini di **LBS diproses** node (`custom_3`), tetapi secara default tidak aktif. The `distance_status` kolom ini disetel untuk selalu mengembalikan `'VALID'` melalui ekspresi tiruan `CASE WHEN 1 != 1 THEN 'EXCLUDED_DISTANCE' ELSE 'VALID' END`. Untuk mengaktifkannya:

1. Buka **LBS diproses** node SQL kustom (`custom_3`) di Pembuat transformasi.
2. Ganti baris tiruan dengan kondisi nyata berdasarkan `distance_meters`. Misalnya, untuk mengecualikan titik LBS yang berjarak lebih dari 500 meter dari titik sebelumnya:

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

Ambang batas antara 200 dan 1.000 meter adalah rentang awal yang wajar — gunakan nilai yang lebih rendah di area dengan cakupan menara seluler yang padat, lebih tinggi di area dengan menara yang jarang.

3. Klik **Jalankan** Untuk melihat pratinjau hasilnya. Periksa berapa banyak titik LBS yang sekarang dikecualikan dan apakah perjalanan yang tersisa terlihat benar. Sesuaikan ambang batas jika perlu sebelum penjadwalan.

</details>

<details>

<summary>Mengecualikan titik LBS sepenuhnya</summary>

Gunakan ini ketika armada Anda menggunakan perangkat khusus GPS yang tidak pernah menghasilkan pembacaan LBS, atau ketika Anda ingin catatan perjalanan dibangun secara eksklusif dari posisi GNSS yang terkonfirmasi.

1. Buka **Data inti** node sumber (`telematics_1`, jenis: Data mentah: Telematika). Pada **Kondisi filter** bidang, hapus `OR satellites = -1` dari pemeriksaan satelit, sehingga mengubah:

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

menjadi:

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

2. Hapus **LBS diproses** node (`custom_3`) dan **LBS tersaring** node (`custom_4`) dari graf, beserta semua sisi yang terhubung ke sana. Gambar sisi baru dari **Dengan jarak** node (`custom_2`) ke **Filter tidak valid** node (`filter_1`) untuk memulihkan aliran data.
3. Buka **Filter tidak valid** node dan ganti kedua kondisi dinamis yang ada dengan satu kondisi langsung: `calculated_speed_kmh <= 200`. Kondisi asli (`lbs_excluded_flag = 0` dan `speed_status = 'VALID'`) mereferensikan kolom yang dihasilkan oleh node yang dihapus dan akan menyebabkan galat eksekusi jika dibiarkan.
4. Klik **Jalankan** untuk melihat pratinjau output. Verifikasi bahwa jumlah titik dan batas perjalanan terlihat benar untuk data Anda sebelum penjadwalan.

</details>

### Menggunakan templat alur kerja

Navixy menyediakan templat alur kerja Perjalanan siap pakai yang dapat Anda muat ke Transformation Builder sebagai titik awal. Templat ini mencakup semua langkah pemrosesan yang dijelaskan di halaman ini, dari pemasukan data mentah hingga pencocokan zona dan agregasi.

Lihat [Templat](/docs/analytics/id/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md) halaman untuk unduhan, instruksi impor, dan konfigurasi node Output untuk transformasi ini.

## Langkah berikutnya

* [**Transformasi umum**](/docs/analytics/id/iot-query/schema-overview/transformation-layer/common-transformations.md): Kembali ke indeks transformasi.
* [**Templat**](/docs/analytics/id/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md): Unduh templat alur kerja Perjalanan dan impor ke Transformation Builder.
* [**Builder transformasi**](/docs/analytics/id/iot-query/schema-overview/transformation-layer/transformation-builder.md): Pelajari cara bekerja dengan penyunting alur kerja visual, menambahkan node, dan melihat pratinjau hasil.
* [**Lapisan data mentah**](/docs/analytics/id/iot-query/schema-overview/bronze-layer.md): Jelajahi tabel sumber yang menjadi masukan bagi transformasi Perjalanan: `tracking_data_core`, `states`, dan `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/id/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.