DEV Community: Daniel Sá

Why I Built My Own OpenStreetMap Routing Engine — and How I Use It in a Real Application

Daniel Sá — Tue, 27 Oct 2026 16:32:31 +0000

Building roadgraph-router-v2: from a practical mapping problem to a lightweight, browser-based routing engine.

Sometimes, the best way to understand a technology is to build something that depends on it.

That's how roadgraph-router-v2 started.

I was developing Energy&Fuel, a web application for exploring electric vehicle charging stations and fuel stations across Portugal.

The idea was relatively straightforward: bring together information about EV charging infrastructure, fuel prices, and station locations in one interactive map.

But as the project evolved, I wanted to go beyond displaying markers.

I wanted users to calculate actual road routes, compare alternatives, and understand how to reach a particular station.

That led me to an interesting problem:

Could I implement routing directly in the browser without relying on an external routing API?

The result was roadgraph-router-v2, an open-source TypeScript routing engine built around OpenStreetMap data, compact road graphs, and A* pathfinding.

In this article, I'll explain why I built it, how it works, and how I'm using it in Energy&Fuel.

1. The Project That Started Everything

Energy&Fuel is an interactive map focused on Portugal's energy and mobility infrastructure.

It brings together two major datasets:

More than 3,000 EV charging stations from the MOBI.E network.
More than 6,000 fuel stations using data from Portugal's Direção-Geral de Energia e Geologia (DGEG).

The application uses Next.js, React, TypeScript, and mapping libraries to display stations, prices, and geographic information.

Users can explore nearby stations, filter by fuel type, compare prices, and look for charging infrastructure.

You can explore the application here:

Energy&Fuel — Live Application

The routing problem

Finding the nearest station is relatively simple when considering geographic distance.

However, geographic distance and driving distance are not the same thing.

Imagine two fuel stations:

Station A is 2 km away in a straight line.
Station B is 3 km away in a straight line.

Station A might appear closer, but reaching it could require driving around a river, following a one-way system, or using a distant motorway exit.

In practice, Station B might be the better destination.

To address this, I needed a routing engine capable of understanding an actual road network.

Seeing the routing engine in action

Here's an example of roadgraph-router-v2 running inside Energy&Fuel:

In this example, the application calculates a journey of approximately 664 km across Portugal, with an estimated driving time of 5 hours and 48 minutes.

The interface displays three alternative routes and allows users to switch between cars, motorcycles, and trucks.

What's interesting isn't necessarily the route itself, but where the calculation happens.

Instead of sending the coordinates to an external directions API, Energy&Fuel uses roadgraph-router-v2 to calculate the route locally in the browser.

The routing engine operates inside a Web Worker, reading the necessary sections of a precompiled OpenStreetMap graph.

The application can therefore provide road routing without operating its own routing backend or depending on a third-party directions service.

Why not use an existing routing API?

There are already excellent routing solutions available.

Projects such as OSRM, GraphHopper, and Valhalla demonstrate how sophisticated open-source routing infrastructure has become.

I wasn't trying to replace them.

However, for my application, I wanted to explore a different architecture.

My objectives were:

Avoid requiring a separately hosted routing service.
Keep the routing logic independent of a commercial API.
Use OpenStreetMap as the underlying geographic dataset.
Support route calculations inside the browser.
Minimize the amount of geographic data downloaded by users.
Make the routing engine reusable in other projects.

I also wanted to understand the underlying algorithms rather than simply integrating another API.

This became the foundation of roadgraph-router-v2.

2. Introducing roadgraph-router-v2

roadgraph-router-v2 is a TypeScript library that transforms OpenStreetMap extracts into compact routing graphs and uses them to calculate routes.

The project is available on GitHub:

GitHub — roadgraph-router

And on npm:

npm — roadgraph-router-v2

The package handles two main responsibilities.

Preparing geographic data

OpenStreetMap provides detailed information about roads, intersections, access restrictions, and other geographic features.

However, raw .osm.pbf files aren't optimized for direct browser-based routing.

The first step is converting the relevant data into a graph that a routing algorithm can efficiently traverse.

roadgraph-router-v2 includes a compiler that produces a compact .efrb bundle.

Calculating routes

Once the graph is prepared, the routing engine can calculate paths between geographic coordinates.

The engine uses the A* algorithm, which explores a road network while using a geographic heuristic to guide the search toward the destination.

This makes it possible to calculate routes without contacting a remote routing server.

The package supports both Node.js and modern browsers.

Supported routing profiles

At the time of writing, version 0.4.0 supports seven profiles.

Road networks:

Car
Motorcycle
Truck
Bicycle
Pedestrian

Railway infrastructure:

Train
Metro

Railway routing is focused on mapped physical infrastructure, not passenger timetables or live train services.

Different transport networks can require separate compiled bundles.

For Energy&Fuel, the important profiles are car, truck, and motorcycle.

3. Compiling OpenStreetMap Data

Before calculating routes, we need road network data.

For Energy&Fuel, I use an OpenStreetMap extract of Portugal.

The first step is installing the package:

npm install roadgraph-router-v2

The routing compiler requires Node.js 22.5 or newer.

Once installed, we can generate a routing bundle:

npx roadgraph-compile portugal.osm.pbf \
  --output portugal.efrb \
  --profile car,truck,motorcycle

This produces a file containing the compiled road network.

Instead of processing raw OpenStreetMap data every time the application starts, the preprocessing work is performed beforehand.

The browser only needs to read the compiled bundle.

Why the compiled format matters

One of my main concerns was the size of the geographic data.

A national road network contains a considerable amount of information.

Downloading and loading the entire graph before calculating a simple journey would be inefficient.

The .efrb format addresses this by supporting range-based access.

Rather than downloading everything, the router can retrieve the portions of the bundle needed for a particular route.

For example, the package's documented Portugal benchmark reports:

Metric	Result
Original Portugal OSM extract	425 MB
Compiled routing bundle	38 MB
Data downloaded for a city route	4.3 MB
End-to-end city route calculation	~270 ms
Browser library size	24.5 kB gzipped

These are measurements from the package's documented benchmark, not guarantees for every machine, network, or route.

Nevertheless, they demonstrate why selective graph loading can make browser-based routing practical.

Compiling the Energy&Fuel dataset

In the actual Energy&Fuel project, the compilation process is integrated into npm scripts.

The command follows this structure:

npm run routing:compile -- portugal-261003.osm.pbf \
  --output public/routing/portugal-v10.efrb \
  --profile car,truck,motorcycle

The generated file is placed in the application's public directory.

That means the browser can request the routing bundle as a static resource.

No separate routing API is required.

One important deployment detail: the server must preserve HTTP Range request behavior for .efrb files. Whole-file HTTP content encoding can interfere with accessing individual byte ranges.

4. Calculating Our First Route

The public API is designed to be straightforward.

Let's calculate a route between two coordinates in Monaco.

import { RoadRouter } from "roadgraph-router-v2";

const router = await RoadRouter.open(
  "/routing/monaco.efrb"
);

const origin = {
  lat: 43.7384,
  lng: 7.4246
};

const destination = {
  lat: 43.7325,
  lng: 7.4189
};

const result = await router.route(
  origin,
  destination
);

console.log({
  distance: result.distanceMeters,
  duration: result.durationSeconds,
  geometry: result.geometry
});

The result contains the calculated road distance, an estimated travel duration, and the geometry of the route.

The geometry is particularly useful because it can be rendered directly on an interactive map using GeoJSON-compatible mapping tools.

The routing calculation happens inside the library, using the compiled graph.

At this point, we've implemented routing without making a request to an external directions API.

However, this is only a simple example.

In a real web application, there is another problem to solve.

5. Keeping the Interface Responsive with Web Workers

One of the challenges I encountered was deciding where routing calculations should execute.

Even if a routing engine is efficient, decoding road network data and searching a graph requires CPU work.

Running this directly on the browser's main thread can affect responsiveness.

For a map-based application, that's particularly noticeable.

Users expect to be able to zoom, pan, and interact with markers while calculations are taking place.

In Energy&Fuel, I decided to move the routing engine into a Web Worker.

The architecture looks like this:

                  Energy&Fuel
                 React / Next.js
                       |
                       |
                Routing Client
                       |
                       | postMessage()
                       |
                 Web Worker
                       |
                       v
              roadgraph-router-v2
                       |
                       v
              Compiled OSM Graph
                       |
                       v
                A* Pathfinding
                       |
                       |
                Route Result
                       |
                       v
                 Map Interface

The main thread sends a request to the worker.

The worker calculates the route and returns the result.

This separation allows route calculations to run without occupying the UI thread.

The actual worker implementation

Energy&Fuel uses the following pattern:

import {
  RoadRouter,
  type Coordinate,
  type RoutePreference
} from "roadgraph-router-v2";

let base: RoadRouter | null = null;

self.onmessage = async ({ data }) => {
  try {
    if (data.type === "open") {
      base = await RoadRouter.open(data.url);

      self.postMessage({
        id: data.id,
        ok: true,
        value: {
          profiles: base.profiles
        }
      });

      return;
    }

    if (!base) {
      throw new Error("Routing graph not loaded");
    }

    const result = await base.route(
      data.from,
      data.to,
      data.preference ?? "fastest"
    );

    self.postMessage({
      id: data.id,
      ok: true,
      value: result
    });

  } catch (error) {
    self.postMessage({
      id: data.id,
      ok: false,
      error: error instanceof Error
        ? error.message
        : "Routing failed"
    });
  }
};

This is a simplified version of the worker used in Energy&Fuel.

The actual implementation also handles multiple vehicle profiles, alternative routes, departure times, and router caching.

Why this architecture matters

The result is a clean separation between the application and the routing engine.

The React components don't need to know how the graph is loaded or how A* works.

They only need to request a route and display the result.

For me, this was an important architectural improvement.

It also means the routing library can evolve independently from the interface.

6. Multiple Vehicle Profiles Without Duplicating the Entire Graph

Another interesting challenge was supporting multiple types of vehicles.

A road that's accessible to a motorcycle might have different restrictions for a truck.

Even when two vehicles can use the same road, they might have different speed assumptions.

roadgraph-router-v2 handles these differences through routing profiles.

For example:

import { RoadRouter } from "roadgraph-router-v2";

const router = await RoadRouter.open(
  "/routing/portugal.efrb"
);

console.log(router.profiles);

// ["car", "truck", "motorcycle"]

We can then select another vehicle profile.

const truckRouter = router.withProfile("truck");

const result = await truckRouter.route(
  origin,
  destination
);

console.log(result.distanceMeters);

The important detail is that multiple motor-vehicle profiles can share road geometry and topology inside the compiled bundle.

Each profile adds the information needed to evaluate its own routing rules.

This avoids storing an entirely separate road network for every supported vehicle.

How Energy&Fuel handles this

In Energy&Fuel, I cache the routers associated with different profiles.

When a user changes vehicle type, the application can reuse a previously initialized router instead of recreating it unnecessarily.

The worker maintains a cache using a Map:

const byProfile = new Map<string, RoadRouter>();

function routerFor(
  profile: string | null
): RoadRouter {
  if (!base) {
    throw new Error("Router not initialized");
  }

  if (
    !profile ||
    base.profile === profile ||
    !base.profiles.includes(profile)
  ) {
    return base;
  }

  const cached = byProfile.get(profile);

  if (cached) {
    return cached;
  }

  const router = base.withProfile(profile);

  byProfile.set(profile, router);

  return router;
}

This is particularly useful when users switch between vehicle types while comparing routes.

It also illustrates one of the benefits of designing the library around reusable graph data.

7. Alternative Routes and Route Preferences

Not every journey has one ideal route.

Sometimes users want the fastest option.

Other times, they might prefer the shortest distance.

roadgraph-router-v2 exposes route preferences through its API.

For example:

const fastest = await router.route(
  origin,
  destination,
  "fastest"
);

const shortest = await router.route(
  origin,
  destination,
  "shortest"
);

The engine also supports alternative-route calculation.

const alternatives = await router.routeAlternatives(
  origin,
  destination,
  "fastest",
  {
    count: 3
  }
);

for (const route of alternatives) {
  console.log({
    distance: route.distanceMeters,
    duration: route.durationSeconds
  });
}

This gives applications the ability to present multiple journey options.

In Energy&Fuel, the routing client supports both normal routes and alternative routes through the same worker interface.

An important distinction is that these are routes based on the compiled network and available routing rules.

They do not represent live traffic predictions.

8. What About Performance?

Performance was one of the reasons I decided to investigate compact routing graphs.

A routing engine that works well on a small city graph might behave very differently when processing a national road network.

The library therefore needs to consider more than just the pathfinding algorithm.

Three areas are particularly important.

Graph representation

The compiler transforms OpenStreetMap data into a more suitable representation for routing.

This means the browser doesn't need to parse raw OSM data whenever a route is requested.

Selective loading

The routing bundle supports HTTP Range requests.

This allows the browser to retrieve relevant sections instead of transferring the entire file.

It reduces initial data transfer, although the amount downloaded depends on the route and the graph.

Reusing loaded data

Previously downloaded and decoded graph data can be reused.

This matters when users calculate multiple routes or change vehicle profiles.

In Energy&Fuel, the worker architecture allows the router to remain initialized between requests.

That reduces unnecessary repeated setup work.

It's also worth distinguishing calculation time from user-perceived latency.

A route may require network transfers, graph decoding, and pathfinding. Measuring only the A* search doesn't tell the full story.

9. Limitations and Lessons Learned

Building a routing engine has been an opportunity to learn more about geographic data structures, graph algorithms, and browser performance.

But an equally important part of the project has been understanding its limitations.

OpenStreetMap data isn't perfect

The quality of calculated routes depends heavily on the underlying geographic data.

Some access restrictions, vehicle limitations, and road attributes may be missing or outdated.

Truck routing requires special care

Although roadgraph-router-v2 supports truck profiles and certain vehicle dimensions, a calculated route isn't a guarantee that a heavy vehicle can legally or physically travel along it.

Not all bridge clearances, weight restrictions, or local regulations are fully represented in OpenStreetMap.

The library shouldn't be the sole routing system used for safety-critical freight operations.

The graph needs updating

A compiled routing bundle represents the OpenStreetMap data available when it was generated.

It doesn't automatically know about newly opened roads, roadworks, or temporary closures.

Updating the geographic dataset requires compiling a new bundle.

Offline routing requires preparation

The engine doesn't require a routing API, but it still needs access to the compiled graph.

In a normal web deployment, that graph can be downloaded from a static server.

Fully offline operation requires the necessary data to be available locally or cached beforehand.

Existing routing engines remain valuable

OSRM, GraphHopper, and Valhalla are mature routing solutions with capabilities that roadgraph-router-v2 doesn't attempt to reproduce.

For applications requiring large-scale routing services, live data integration, or advanced routing functionality, those solutions may be more appropriate.

My goal was different: build a lightweight, reusable engine that could operate directly over compact OpenStreetMap graphs in JavaScript environments.

10. From a Project Requirement to an Open-Source Library

One of the most rewarding aspects of this project is that roadgraph-router-v2 didn't begin as an isolated experiment.

It came from a practical requirement in another application.

Energy&Fuel needed routing.

Instead of making the routing logic specific to Energy&Fuel, I separated it into a reusable package.

That decision made it possible to develop and test the routing engine independently.

It also opened the door to features that go beyond the original application.

The package now supports multiple road vehicle profiles, pedestrian and bicycle routing, alternative routes, turn restrictions, and routing over railway infrastructure.

Not every capability is used by Energy&Fuel.

And that's fine.

The application benefits from the routing engine, while the routing engine can continue evolving as a separate open-source project.

11. Try It Yourself

If you're interested in experimenting with OpenStreetMap routing in TypeScript, you can install roadgraph-router-v2 directly from npm.

npm install roadgraph-router-v2

Compile an OSM extract:

npx roadgraph-compile monaco.osm.pbf \
  --output monaco.efrb

Then calculate a route:

import { RoadRouter } from "roadgraph-router-v2";

const router = await RoadRouter.open(
  "./monaco.efrb"
);

const result = await router.route(
  { lat: 43.7384, lng: 7.4246 },
  { lat: 43.7325, lng: 7.4189 }
);

console.log(result.distanceMeters);
console.log(result.durationSeconds);
console.log(result.geometry);

For more advanced functionality, the GitHub repository contains documentation covering vehicle profiles, graph compilation, alternative routes, and additional routing options.

Project links

Routing engine

Application

Energy&Fuel — Live Demo

Final Thoughts

Building Energy&Fuel reminded me that seemingly simple application features can involve interesting engineering challenges.

Displaying a location on a map is relatively straightforward.

Calculating a route through thousands of interconnected roads, while minimizing data transfer and keeping a browser responsive, is a different problem.

Working on roadgraph-router-v2 gave me the opportunity to explore graph algorithms, geographic data processing, binary data formats, caching strategies, and browser threading.

It also reinforced an architectural principle I value:

A solution developed for one application can become a useful

I Built an Open-Source Routing Engine for JavaScript Using OpenStreetMap 🚗

Daniel Sá — Mon, 12 Oct 2026 18:32:03 +0000

What if you could calculate routes directly in your JavaScript application, without relying on Google Maps, external routing APIs, or a running routing server?

That's the idea behind roadgraph-router, an open-source npm package I've been working on.

After spending time experimenting with OpenStreetMap data, graph structures, and routing algorithms, I wanted to build something that could process real road networks while remaining lightweight enough to run in Node.js or directly in a browser.

Today, I'm releasing the project publicly.

🔗 Project Links

🐙 GitHub Repository

🚀 npm — Latest Version ⭐ Recommended

📦 npm — Legacy Version (No longer maintained)

🤔 Why I Built It

OpenStreetMap provides an incredible amount of geographical information, including road networks, intersections, speed limits, and turn restrictions.

But transforming all that information into something you can efficiently use inside a JavaScript application isn't necessarily straightforward.

When working with larger geographical datasets, such as Portugal's road network, I encountered several challenges:

OpenStreetMap files can be hundreds of megabytes.
Processing large road networks can require significant memory.
Loading an entire road network into a browser isn't practical.
Routing needs to respect one-way streets and turn restrictions.
I wanted the routing engine to work without depending on an external API.

I started experimenting with ways to compile OSM data into smaller, more efficient graph structures.

That experimentation eventually became roadgraph-router.

🚀 Introducing roadgraph-router

roadgraph-router is a TypeScript routing library that converts OpenStreetMap .osm.pbf extracts into compact routing bundles and calculates routes using the A* search algorithm.

The goal is simple: make road routing accessible to JavaScript developers without requiring a dedicated routing service.

Some of its current capabilities include:

OpenStreetMap integration: Compile .osm.pbf extracts from different geographical regions.
A* pathfinding: Calculate road routes between geographical coordinates.
Compact binary storage: Store road networks in optimized, compressed bundles.
Partial network loading: Download only the parts of the road network needed for a route.
Browser and Node.js support: Run routing calculations locally without an external routing API.
Road snapping: Match geographical coordinates to actual road segments.
Traffic rule awareness: Respect supported one-way streets, access rules, speed limits, and turn restrictions.
GeoJSON output: Integrate resulting route geometries into mapping applications.

The initial release focuses on car routing, with opportunities to expand its capabilities over time.

🛠️ Getting Started

Install the package using npm:

npm install roadgraph-router

Before calculating routes, you'll need to compile an OpenStreetMap extract into a routing bundle.

For example, using a Monaco OSM extract:

npx roadgraph-compile monaco.osm.pbf --output monaco.efrb

The compiler requires Node.js 22.5 or newer.

Once compiled, you can load the routing bundle and calculate a route:

import { RoadRouter } from "roadgraph-router";

const router = await RoadRouter.open(
  "/routing/monaco.efrb"
);

const result = await router.route(
  { lat: 43.7384, lng: 7.4246 },
  { lat: 43.7325, lng: 7.4189 }
);

console.log(result.distanceMeters);
console.log(result.durationSeconds);
console.log(result.geometry);

The result contains the calculated distance, estimated duration, and road-following GeoJSON geometry.

This means you can use the output with libraries such as Leaflet or MapLibre to visualize routes on a map.

And because routing happens locally, there's no need to send every route request to an external routing service.

📦 Making Large OSM Files Smaller

One of the most interesting challenges was working with larger OSM extracts.

For example, the Portugal dataset I used for testing was approximately 425 MB.

Rather than loading and maintaining that entire dataset in memory, roadgraph-router compiles the information into a compact, range-addressable binary format.

The results were encouraging.

Portugal compilation benchmark

Metric	Result
Original OSM PBF	425 MB
Compiled routing bundle	38.03 MB
Routing edges	2,757,265
Compilation time	7 min 46 s
Peak memory usage	1.11 GB

That's approximately a 91% reduction in file size compared with the original PBF extract.

Of course, the compiled bundle is a purpose-built routing representation, not a lossless replacement for the original OSM dataset.

The important part is that it retains the road-network information the routing engine needs.

The measurements above were collected on one desktop machine, so actual performance will depend on hardware, geographical data, and compilation options.

🌍 You Don't Need to Download the Entire Map

Another important design decision was to avoid downloading the complete routing bundle whenever someone requests a route.

Instead, the package uses HTTP range requests to retrieve the relevant sections of the road network.

For example, in my Portugal benchmark, a short urban route in Lisbon required approximately 4.93 MB of downloaded routing data, despite the complete bundle being 38 MB.

That route took around 118 ms to load its graph data and 86 ms for the A* search, excluding additional overhead.

This approach makes it possible to work with fairly large road networks without loading everything at once.

It is particularly interesting for web applications where bandwidth and memory matter.

🧠 More Than Just Finding the Shortest Path

Finding a path through a graph is one thing.

Finding a usable driving route is another.

Real road networks contain rules that a routing engine needs to understand.

A driver cannot always travel in both directions along a road or turn wherever they want.

roadgraph-router currently handles several important aspects of this problem, including one-way streets, supported turn restrictions, and speed information from OSM.

It also snaps coordinates to road segments rather than simply selecting the closest intersection.

This becomes especially important in rural areas, where junctions can be far apart.

Internally, the routing engine uses A* and can switch to an edge-based search when turn restrictions must be enforced.

There are still limitations. For example, conditional access restrictions, live traffic, and traffic signal delays aren't currently modelled.

I'm treating those as areas for future development rather than pretending the library is already a complete navigation platform.

🔮 What's Next?

The package is still in its early stages, and there are several improvements I'd like to work on.

Two of my main priorities are:

1. Different vehicle profiles

Right now, the bundled routing profile focuses on cars.

I'd like to expand this to support other types of vehicles and transportation, each with its own routing rules.

For example, bicycles and pedestrians shouldn't necessarily follow the same road network constraints as cars.

2. Alternative routes

Finding one route is useful, but there are situations where having multiple options is better.

I'd like the engine to eventually return alternative routes when meaningful alternatives exist, allowing applications to compare options by distance or estimated travel time.

Beyond those features, I want to keep improving processing efficiency, bundle sizes, memory consumption, and developer experience.

The objective is to make the package increasingly useful while keeping its architecture understandable and lightweight.

🤝 Open Source and Contributions

roadgraph-router is available on GitHub under the MIT license.

It's a project I'm actively developing, and I'd genuinely appreciate feedback from other developers.

Whether you work with mapping applications, OpenStreetMap, transportation software, routing algorithms, or simply enjoy exploring graph-based problems, I'd be interested in hearing your thoughts.

If you find something that doesn't work as expected, have an idea for an improvement, or want to contribute, feel free to open an issue or pull request.

GitHub: https://github.com/danieljvsa/roadgraph-router

npm: https://www.npmjs.com/package/roadgraph-router

Install it with:

npm install roadgraph-router #legacy
npm install roadgraph-router-v2 #current-valid

💬 Final Thoughts

Building this package has been an interesting exercise in working with large datasets, binary formats, graph algorithms, and geographical information.

There's still a lot I want to improve, but I felt it was time to make it public rather than continue developing it in isolation.

I'm interested in seeing whether other developers find it useful, especially those who want to experiment with routing without operating a dedicated backend service.

If you were building a routing engine in JavaScript, what feature would you prioritize next?

Thanks for reading! 🚀

Tags: #javascript #typescript #opensource #showdev

Teltonika-Go Update: From Initial Release to Full Codec Support

Daniel Sá — Fri, 29 May 2026 20:17:41 +0000

A few months ago, I published my first article introducing Teltonika-Go:

Introducing Teltonika-Go: A Go Package for Parsing and Communicating with Teltonika Devices

At the time, the goal was simple:

Build an open-source Go library to simplify communication with Teltonika GPS tracking devices.

The project started as a side project inspired by my experience working in vehicle tracking and telemetry systems. I wanted a reusable package that developers could easily integrate into their own fleet management, IoT, and GPS tracking platforms.

Since then, the project has grown significantly.

What Has Changed?

The initial version focused primarily on AVL packet parsing and the most commonly used codecs.

Today, Teltonika-Go supports:

AVL Data Codecs

Codec 08
Codec 8E
Codec 16

Command & Response Codecs

Codec 12
Codec 13
Codec 14
Codec 15

Additional Features

AVL packet decoding
AVL packet encoding
Command packet encoding
Command response decoding
TCP support
UDP support
IMEI handling
CRC validation
Timestamp utilities
Extensive unit testing

Repository:

https://github.com/danieljvsa/teltonika-go

One of the biggest milestones was expanding support beyond AVL data packets and implementing command-related codecs.

This transformed the library from a parser into a more complete communication toolkit for Teltonika devices.

Why This Matters

Many GPS tracking systems eventually need more than just location data.

Real-world deployments often require:

Sending commands to devices
Receiving command responses
Managing remote configurations
Supporting multiple Teltonika device generations
Handling both TCP and UDP communication

Supporting these additional codecs makes it easier to build complete integrations without having to implement protocol handling from scratch.

Lessons Learned

Protocol Specifications Matter

The most challenging aspect of the project was never the Go code itself.

The difficult part was ensuring protocol correctness.

When working with binary protocols, small mistakes can break communication completely.

Issues such as:

Incorrect packet lengths
CRC calculation errors
Wrong byte ordering
Timestamp conversion mistakes

can result in devices rejecting packets without providing much information about what went wrong.

Most development time was spent validating behavior against protocol documentation and testing edge cases.

Testing Became Essential

As support for more codecs was added, the importance of testing increased dramatically.

Adding new functionality without introducing regressions became a priority.

Today, the project includes a growing suite of tests that helps ensure stability when adding features or improving existing implementations.

Open Source Is About Iteration

One thing I enjoy about open source is that projects rarely remain in their original form.

The first release is simply the starting point.

Since publishing the original article, I've received feedback, discovered new use cases, and identified areas where the library could be improved.

Each iteration has made the project more complete and more useful.

Building with Modern AI Tools

This project was also an interesting opportunity to explore modern AI-assisted development.

I used tools such as:

Claude
OpenCode
DeepSeek
Qwen

to accelerate development tasks including:

Boilerplate generation
Test creation
Documentation improvements
Code reviews
Refactoring suggestions

The biggest lesson was that AI works best as an accelerator rather than a replacement for domain knowledge.

Understanding GPS tracking systems, binary protocols, and Teltonika specifications remained essential for validating the generated code and ensuring correct behavior.

What's Next?

There are still several improvements planned for future releases.

Some areas I'd like to focus on include:

More real-world examples
Complete TCP server examples
Improved documentation
Better pkg.go.dev support
Additional protocol utilities

The goal remains the same as when the project started:

Make Teltonika device integration easier for Go developers.

Final Thoughts

Looking back at the original article and comparing it with the current state of the project, it's satisfying to see how much it has evolved.

What started as a simple parser has grown into a much more complete Teltonika communication library supporting multiple codecs, command handling, and packet generation.

If you're working with Teltonika devices, GPS tracking systems, or telemetry platforms, I'd love to hear your feedback.

Feel free to check out the repository, open an issue, or contribute to the project.

Happy coding 🚀

Repository:

https://github.com/danieljvsa/teltonika-go

Building Two Web Apps Using Claude AI + OpenCode

Daniel Sá — Sun, 24 May 2026 12:11:22 +0000

Over the last weeks I decided to experiment with AI-assisted development workflows to see how much faster I could go from idea to working MVP.

Instead of treating AI as a “code generator”, I approached it more like an engineering accelerator:

brainstorming partner
rapid prototyping assistant
UI iteration helper
debugging companion
architecture sounding board

The result was two small projects:

Altivo — a lightweight portfolio tracker
Hopway — a visual route planning app

Both projects are intentionally lightweight, but they helped me explore a modern development workflow using:

Claude AI
OpenCode AI
DeepSeek V4 Flash
Qwen 3.6 Plus

The Projects

Altivo

Altivo is a lightweight and privacy-friendly portfolio tracker focused on simplicity and static deployment.

Live Demo:
https://danieljvsa.github.io/altivo/

GitHub:
https://github.com/danieljvsa/altivo

The idea was to build something lightweight that could:

track ETFs
support crypto
run entirely as a static frontend
avoid unnecessary complexity

I wanted a cleaner and simpler experience than many traditional portfolio platforms.

The project also became an interesting exercise in:

frontend architecture
UI simplification
API integration
local-first persistence

Tech Stack

HTML
CSS
JavaScript
GitHub Pages
Financial Market APIs

Hopway

Hopway is a lightweight route planning and travel exploration tool.

Live Demo:
https://danieljvsa.github.io/hopway/

GitHub:
https://github.com/danieljvsa/hopway

The concept behind Hopway was creating a map-first experience where users can:

create routes
visually explore destinations
share travel plans
experiment with AI-generated route ideas

The app uses CARTO maps and focuses on keeping the UX lightweight and visual.

I wanted it to feel more like an exploration tool than a traditional route planner.

Tech Stack

HTML
CSS
JavaScript
CARTO Maps
GitHub Pages

The AI Workflow

One of the most interesting parts of these projects was experimenting with different AI tools together.

Each model had different strengths.

Claude AI

Claude was the strongest tool for:

architecture discussions
reasoning
debugging
planning features
refining ideas
writing structured prompts

It was especially useful when thinking through:

application structure
user experience
roadmap decisions
feature tradeoffs

OpenCode AI

OpenCode became the main execution layer for applying changes directly inside the repositories.

This made iteration significantly faster because I could:

define tasks
refine prompts
generate implementations
review results quickly

The workflow started feeling much closer to collaborating with a junior developer that could iterate extremely fast.

DeepSeek V4 Flash

DeepSeek V4 Flash was surprisingly useful for:

quick fixes
smaller implementations
fast iterations
UI experimentation
alternative code suggestions

Because it was fast and free, it became useful for high-frequency iteration loops.

Qwen 3.6 Plus

Qwen 3.6 Plus was particularly good for:

generating alternative approaches
refining frontend ideas
brainstorming UX improvements
comparing implementation styles

Sometimes asking multiple models the same question produced surprisingly useful contrasts.

What AI Was Actually Good At

The biggest productivity gain was not “AI writing code”.

It was reducing friction.

AI was extremely useful for:

generating boilerplate
accelerating iteration
refining UI ideas
debugging faster
exploring alternatives
reducing context-switching

For small MVPs, that becomes incredibly powerful.

What Still Required Human Control

The important engineering decisions still required human oversight.

Things that still needed strong manual control:

architecture decisions
consistency
product direction
deployment
performance considerations
long-term maintainability

AI accelerated execution, but it did not replace engineering judgment.

Lessons Learned

A few things became very clear during these projects:

Smaller focused prompts worked better than giant prompts
AI performs best when architecture is already defined
Iteration speed becomes one of the biggest advantages
Reviewing generated code remains critical
Combining multiple models produced better results than relying on a single one
AI is especially powerful for reducing setup and boilerplate friction

One of the most interesting outcomes was how quickly experimentation became possible.

Normally many side projects die during the setup phase:

too much boilerplate
too much context switching
too much repetitive work

AI dramatically reduced that friction.

That allowed me to spend more time on:

product thinking
UX refinement
architecture
experimentation

Instead of repetitive setup work.

Final Thoughts

These projects are small, but they represent something bigger:
a shift in how rapid MVP development is evolving.

AI-assisted workflows are becoming extremely valuable for:

side projects
prototypes
internal tools
experimentation
product validation

AI did not replace development.

But it significantly reduced the time between:
idea → prototype → working application.

As a backend developer, these projects also helped me improve:

frontend awareness
UX thinking
rapid delivery skills
product-focused development

And honestly, the workflow was fun.

If you're experimenting with AI-assisted development workflows too, I'd love to hear how you're using them.

Introducing teltonika-go: A Go Package for Parsing and Communicating with Teltonika Devices

Daniel Sá — Thu, 12 Jun 2025 13:40:53 +0000

If you've ever worked with Teltonika GPS tracking devices, you know that parsing their proprietary protocol can be a bit of a challenge. Whether you're building a fleet management system, a custom IoT platform, or just tinkering with real-time vehicle telemetry, understanding and communicating with these devices is critical.

That's why I created teltonika-go — an open-source Go package that simplifies parsing Teltonika messages and enables communication with their devices over TCP.

📦 What is teltonika-go?

teltonika-go is a lightweight, idiomatic Go library designed to help developers decode, parse, and interpret the binary protocol used by Teltonika GPS trackers like the FMB series. It provides building blocks for server-side communication with these devices, which typically send AVL (Automatic Vehicle Location) data over TCP.

With teltonika-go, you can:

Read and parse AVL packets sent by devices
Understand GPS, IO, and timestamp data
Handle device handshakes and codec types (including Codec8, Codec8 Extended and Codec16)

Build your own custom server or integrate Teltonika device communication into an existing Go application

✅ Why Use It?

Teltonika devices are widely used in the GPS tracking industry, but documentation is limited and most of it is not tailored to developers. If you're a Go developer, teltonika-go provides:

A clean and idiomatic API
No external dependencies (other than the Go standard library)
Open-source flexibility (MIT License)

🔧 Getting Started

Install the package:

go get github.com/danieljvsa/teltonika-go

Example: Parse a TCP packet from a Teltonika FMB device.

package main

import (
    "fmt"
    pkg "github.com/danieljvsa/teltonika-go/pkg" //for general functions
    tools "github.com/danieljvsa/teltonika-go/tools" //for functions that used in package to help in case only want to decode specific tram code
)

func main() {
    // example binary data from a Teltonika device
    rawLogin := []byte{ /* login packet */ }
    rawTram := []byte{ /* AVL packet */ }

    // Decode login packet
    login := pkg.LoginDecoder(rawLogin)
    if login.Error != nil {
        fmt.Println("Login decode error:", login.Error)
    } else {
        fmt.Printf("Login decoded: %+v\n", login.Response)
    }

    // Decode AVL/tram packet
    tram := pkg.TramDecoder(rawTram)
    if tram.Error != nil {
        fmt.Println("Tram decode error:", tram.Error)
    } else {
        fmt.Printf("Tram decoded: %+v\n", tram.Response)
    }
}

🧱 Project Structure

The project is still in its early stages, but currently supports:

Decode login packets
Parse AVL records using Codecs 08, 8E and 16
Validate and interpret Teltonika TCP/UDP headers

Feel free to check out the repo: https://github.com/danieljvsa/teltonika-go

🚧 Roadmap

The project is under active development, and here are some features on the horizon:

Full support for Codec 12 and Codec 14
Full support for encoding for commands with codecs 12, 13, 14, 15.
Tools to send commands to devices (e.g., engine cut-off, configuration updates)
Improved error handling and documentation

If you're working with Teltonika devices and using Go, I'd love your feedback and contributions!

🤝 Contributing

Contributions are welcome! If you find a bug, have a feature request, or just want to improve the code, feel free to open an issue or a pull request.

🙌 Final Thoughts

Parsing Teltonika’s binary protocol doesn’t need to be a pain. With teltonika-go, you can start building robust applications that speak Teltonika's language — all in idiomatic Go.

👉 Check out the project on GitHub: danieljvsa/teltonika-go

⭐ Star it if you find it useful, and let's make working with Teltonika devices easier together!

Source code: https://github.com/danieljvsa/teltonika-go

DEV Community: Daniel Sá

Why I Built My Own OpenStreetMap Routing Engine — and How I Use It in a Real Application

1. The Project That Started Everything

The routing problem

Seeing the routing engine in action

Why not use an existing routing API?

2. Introducing roadgraph-router-v2

Preparing geographic data

Calculating routes

Supported routing profiles

3. Compiling OpenStreetMap Data

Why the compiled format matters

Compiling the Energy&Fuel dataset

4. Calculating Our First Route

5. Keeping the Interface Responsive with Web Workers

The actual worker implementation

Why this architecture matters

6. Multiple Vehicle Profiles Without Duplicating the Entire Graph

How Energy&Fuel handles this

7. Alternative Routes and Route Preferences

8. What About Performance?

Graph representation

Selective loading

Reusing loaded data

9. Limitations and Lessons Learned

OpenStreetMap data isn't perfect

Truck routing requires special care

The graph needs updating

Offline routing requires preparation

Existing routing engines remain valuable

10. From a Project Requirement to an Open-Source Library

11. Try It Yourself

Project links

Final Thoughts

I Built an Open-Source Routing Engine for JavaScript Using OpenStreetMap 🚗

🔗 Project Links

🤔 Why I Built It

🚀 Introducing roadgraph-router

🛠️ Getting Started

📦 Making Large OSM Files Smaller

Portugal compilation benchmark

🌍 You Don't Need to Download the Entire Map

🧠 More Than Just Finding the Shortest Path

🔮 What's Next?

🤝 Open Source and Contributions

💬 Final Thoughts

Teltonika-Go Update: From Initial Release to Full Codec Support

What Has Changed?

AVL Data Codecs

Command & Response Codecs

Additional Features

Why This Matters

Lessons Learned

Protocol Specifications Matter

Testing Became Essential

Open Source Is About Iteration

Building with Modern AI Tools

What's Next?

Final Thoughts

Building Two Web Apps Using Claude AI + OpenCode

The Projects

Altivo

Tech Stack

Hopway

Tech Stack

The AI Workflow

Claude AI

OpenCode AI

DeepSeek V4 Flash

Qwen 3.6 Plus

What AI Was Actually Good At

What Still Required Human Control

Lessons Learned

Final Thoughts

Links

Altivo

Hopway

About Me

Introducing teltonika-go: A Go Package for Parsing and Communicating with Teltonika Devices

📦 What is teltonika-go?