OpenRoadBook specification v1.0 (Draft)

1. Introduction

1.1 Purpose

OpenRoadBook defines an open, human‑friendly, machine‑readable format for roadbooks. It is designed for both competitive rally events (FIA‑style) and non‑competitive adventure travel (motorbike, 4x4, overland). It enables interoperability between peers, organizers, competitors, and software tools, while remaining easy to author and validate.

1.2 Goals

2. Scope

This specification applies to:

It covers:

It does not prescribe:

3. Terminology

GPS fields (waypoint) are optional. Roadbooks may be fully usable without GPS coordinates, relying solely on distances, tulips, and notes.

4. Data Model

4.1 File Format

4.2 Structure Example

meta:
  format: OpenRoadBook
  version: 1.0
  event:
    name: Rally of Exampleland
    date: 2025-10-23
    stage: SS1
    organizer: Example Rally Club
    regulations: FIA Cross-Country Rally Appendix II

entries:
  - km: 0.00
    tulip: start
    cap: 90
    notes: "Start of stage"
    symbols: [start]
    waypoint: { lat: 41.12345, lon: 2.12345 }

  - km: 12.35
    tulip: turn_left
    cap: 270
    notes: "Gravel, caution rocks"
    symbols: [danger2, jump]
    speed_limit: 50

4.3 Field Definitions

5. Symbol Registry

5.1 Purpose

The registry defines a stable vocabulary of symbol IDs. Each ID maps to metadata and an SVG/PNG asset.

5.2 Example Entry

symbols:
  - id: danger2
    name: "Danger (2 exclamations)"
    category: hazard
    svg: danger2.svg
    description: "Serious hazard, reduce speed"

5.3 Core Categories

5.4 Adventure Extensions

6. Validation

7. Interoperability

8. Versioning

9. Governance

10. Compliance

A tool is OpenRoadBook‑compliant if it:

  1. Can parse and validate OpenRoadBook v1 YAML.
  2. Can render or export roadbooks using the official symbol registry.
  3. Preserves unknown fields (for forward compatibility).

Profiles

FIA Profile

Adventure Profile

Appendix A: Example Roadbook Entry

- km: 25.40
  tulip: turn_right
  cap: 180
  notes: "Sharp right, rocks inside"
  symbols: [danger2, rocks]
  waypoint: { lat: 41.67890, lon: 2.67890 }

Appendix B: Adventure extensions

B.1 Additional Symbols

B.2 Optional Fields

B.3 Example

- km: 45.20
  tulip: straight
  notes: "Pass through small village, bakery on right"
  symbols: [town, food]
  tip: "Good place to refuel body and bike"

title: “Specification” description: “Normative guidance for the OpenRoadBook adventure release, with a roadmap toward FIA-compliant, professional rally workflows.”

Specification (draft)

The specification defines normative schema rules, profile behaviour, and validation requirements. Use this document to determine whether a file, tool, or workflow is compliant with the OpenRoadBook format.

Introduction & scope

This document describes the normative expectations for files claiming conformance to the OpenRoadBook format. It covers required fields, allowed values, profile semantics, and the validation behaviour that tools must implement.

  • Purpose: Keep roadbooks open, human-readable, and machine-validated.
  • Current scope: Adventure and training stages with baseline metadata.
  • Next: FIA profiles, penalties, and telemetry through transparent RFCs.
  • Out of scope: Proprietary visuals, closed tooling, or vendor lock-in.

Goals

The specification aims to make roadbooks predictable and verifiable across authoring, validation, rendering, and exchange. It must enable independent implementations to produce consistent outputs from the same inputs.

Standardized schema

Entries follow a predictable structure, enabling automation and machine validation.

Human readability

YAML is canonical so authors can understand the data without specialized tools.

Extensibility

Profiles and registry additions expand capabilities without breaking existing roadbooks.

Conversion-ready

Designed for rendering into FIA-style PDFs, GPX/KML, and digital dashboards.

Validation-first

JSON Schema or equivalent ensures data quality before competitors see it.

Open governance

Community-driven updates with transparent releases and versioning.

Data requirements

Files that declare `meta.format: OpenRoadBook` and the matching `meta.version` must meet the structural and field-level constraints specified here. The JSON Schema provides the machine-readable contract; this document explains intent and edge cases.

File structure

  • Format declaration: meta.format: OpenRoadBook
  • Version: meta.version follows semantic versioning.
  • Event metadata: name, date, stage, organizer, regulations.
  • Entries array: ordered list of navigation steps.

Entry schema

  • km (number) — cumulative distance in km.
  • tulip (string) — ID referencing the tulip registry.
  • cap (integer) — compass heading 0–359.
  • notes (string) — human-readable guidance.
  • symbols (array) — registry IDs for hazards/services.
  • Optional: speed_limit (integer km/h), waypoint (lat/lon), adventure tip and landmark.

Symbol registry

  • IDs grouped by navigation, hazards, road/surface, services/controls.
  • Adventure appendix defines extra IDs (camp, water, etc.).
  • Each record includes ID, name, category, SVG filename, description.
  • Registries must remain stable; new symbols append without reusing IDs.

Validation

Validation verifies types, ranges, and registry references. Implementations should use the published JSON Schema as the primary validator and follow the profile-specific rules for mandatory or restricted fields. Validation failures must be reported with clear, actionable messages.

The authoritative schema is published at https://openroadbook.com/schemas/orb.schema.json, matching the `$id` embedded in the JSON Schema for automatic resolver support. Immutable snapshots live under versioned paths such as https://openroadbook.com/schemas/1.0/orb.schema.json so tooling can pin to a specific release.

  • Check that km is numeric and non-negative.
  • Ensure cap is an integer in the range 0–359.
  • Verify every ID in symbols exists in the registry.
  • Require mandatory fields per profile; optional fields may be present.

8. Versioning & governance

Semantic versioning keeps the ecosystem predictable. Community governance ensures changes reflect real-world needs.

Semantic versioning

  • MAJOR — breaking changes to schema or registry.
  • MINOR — additive changes, new fields, new symbols.
  • Each release documents changes in a public changelog.

Governance

  • Community-driven working group with organizers, developers, riders.
  • Proposals discussed openly (e.g., GitHub issues / RFCs).
  • Transparent approvals and roadmap tracking.

Updates

  • Publish releases with accompanying schema files and assets.
  • Tag registry revisions; never delete or repurpose IDs.
  • Document migration steps for breaking changes.

10. Compliance checklist

A tool or dataset may be advertised as OpenRoadBook-compliant when it satisfies the following conditions.

Parse & validate

Accept OpenRoadBook YAML and execute schema validation with error reporting.

Render or export

Output roadbooks using the official symbol registry (PDF, digital, or hybrid).

Preserve forward compatibility

Retain unrecognized fields to avoid breaking future minor releases.

Profiles

Profiles tailor the baseline schema for each discipline. The adventure profile ships today; FIA and additional competitive variants are in development with the community.

FIA profile

  • Draft in progress aligning with FIA Appendix II requirements.
  • Restricts symbols to FIA-recognized pictograms and hazard grading.
  • Requires compliance with FIA formatting, penalties, and timing rules.
  • Targets competitive rally raid and cross-country events.

Adventure profile

  • Ships today with additional symbols like camp, water, food.
  • Supports optional fields tip and landmark for storytelling.
  • Ideal for non-competitive navigation, training stages, and community rides.

Future profiles

  • Encourage proposals for new disciplines (e.g., TSD rallies, cycling).
  • Must specify allowed extensions and registry subsets.
  • Should reference validation updates in the JSON Schema.

Stay aligned

Specification v1.0 (draft) · Last updated 29 Oct 2025

Back to the format overview