# Navit is a car navigation system you can build on your own map data > Navit is a copylefted car navigation system with its own routing engine, written in C, that runs on Android, Linux car computers and desktops, reads OpenStreetMap and other vector map formats, and gets its position from gpsd or plain NMEA. It suits people who want navigation they can configure and extend rather than a packaged consumer app. **navit-gps/navit** — The open source (GPL v2) turn-by-turn navigation software for many OS - Repository: https://github.com/navit-gps/navit - Website: http://www.navit-project.org - Stars: 669 · Forks: 187 - Language: C - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/navit-gps-navit ## A navigation system with its own routing engine Navit is described in the repository as a copylefted libre software car-navigation system with its own routing engine, and the project description calls it the open source turn-by-turn navigation software for many operating systems. That last phrase, many operating systems, is the point. The README shows it on an Android tablet and on a Linux based carputer, and the badges point to F-Droid and Google Play packages under the org.navitproject.navit application id, so the same codebase covers the two deployment shapes people actually use for car navigation. The web interface is on the project site. The audience is therefore not a phone user looking for the easiest consumer app, but someone building a car computer, an embedded dashboard, or a navigation setup where they want to control the map data, the route computation and the interface. The word copylefted in the README's own tagline is the other thing to notice. The repository carries COPYING, GPL-2 and LGPL-2 files, and the licence field is recorded as a custom one that GitHub cannot classify, so a deployment inside a commercial product needs its own review rather than an assumption of permissiveness. ## Map support is uneven, and the README is honest about which part The maps section of the README is a list with qualifiers, and reading the qualifiers is the point. OpenStreetMap is listed with display, routing, and incomplete street-name search, so search is the weak point of the strongest map source. The Grosser Reiseplaner maps and compliant maps are listed with full support, which is the claim to check against whatever map you actually have. Garmin maps are listed with display and routing, and search is being worked on. That last phrase is doing real work in the sentence, because a navigation system you cannot search in is a system that will send you the wrong way when you do not know the address. Points of interest are supported in many formats, which is what makes a restaurant or fuel stop findable at all. The overall design is described as modular with routing and rendering of one or more vector maps in various formats, and the interfaces are GTK and SDL with touch-screen displays, which is the combination that makes a resistive or capacitive car screen work without a mouse. ## Where the position comes from, and the four ways it arrives Position is handled by a small set of interchangeable sources, and the list in the README covers the realistic cases. Current vehicle position can come from a file or a port, from gpsd either local or remote, from the location service of several mobile platforms, and from a UDP server for friends tracking, which is marked experimental. The gpsd path is the one that matters for a carputer, because it means the navigation process does not have to own the serial port or the USB receiver, and a daemon can feed several consumers. The NMEA path is the fallback for a direct GPS sensor. The mobile location service path is what makes the Android build work as an ordinary app, using the platform's own positioning rather than raw satellites. The friends tracking case is a different feature wearing the same interface, where a device publishes its position over UDP so another device can show it, and the experimental label is worth respecting because it is the least described of the four. The upstream tool here is gpsd, and the topic tags name it explicitly. ## LPA* backwards from the destination, and a traffic module on top The routing algorithm section describes the search in unusual detail, and it is worth reading because it explains the behaviour you get. Navit uses LPA*, the Lifelong Planning A* variant, starting at the destination by assigning a value to each point directly connected to the destination point, where the value represents the estimated time needed to reach the destination from that point. A Fibonacci-heap search then finds the point with the lowest value, and that value is assigned to connected points that are either unevaluated or whose current value is greater than the new one, and the loop repeats until the origin is found. Once the origin is reached, the lowest-value points are followed back to the destination. Working backwards from the destination is the defining idea of LPA*, and it is what makes incremental reuse possible, since the search can be re-run after the goal changes without discarding the work. The traffic module is the experimental part on top of it, and the README describes it as re-evaluating route-graph portions as segment costs change, so it can process traffic reports and find a way around problems. The module being experimental is the honest signal here, since dynamic rerouting is where a navigation system earns or loses trust, and an unreleased-quality implementation of it should be treated as a feature to test rather than a feature to rely on. ## Getting it: store packages, a build tree and a documentation site The README does not contain an install command, and it points elsewhere for setup. Installation details live in the documentation at navit.readthedocs.io, and the same site hosts the Reporting Bugs page that explains how to file issues, plus the per format map pages the maps section links to. The project ships packages on F-Droid and on Google Play under the org.navitproject.navit application id, which is the low effort route for an Android tablet. For everything else the repository is the source of truth, and the top level listing shows a substantial build environment. There is a CMakeLists.txt with a cmake/ directory and a cpack.cmake for packaging, a configure-based path with a config.h.in template, a Makefile.am for the autotools route, a build.gradle with the gradle wrapper for the Android build, a Toolchain/ directory, a man/ directory for the manual pages, and a po/ directory for the message catalogues. There is also a scripts/ directory, a fastlane/ directory for store release automation, a checkstyle.xml, a .typos.toml and a _typos.toml spelling configuration, and an AUTHORS file. Translations are managed on the hosted Weblate platform, which is worth knowing about if you want to contribute a language, since the translation status badge points there. ## Where Navit differs from a phone navigation app The nearest alternative is a consumer navigation app on a phone, and the difference in approach is not the map data but everything around it. A phone app gets maps, traffic and search from a service, updates them silently, and hides the configuration behind settings screens. Navit is an application you configure with your own map files, which means the map coverage, the search quality and the routing behaviour are all consequences of the choices you made in the configuration and in the data you downloaded. The upside is control, and it is real, because a project with its own routing engine and a modular design for maps, rendering and position can be adapted to a vehicle, a fleet or a research setup in a way that a packaged app cannot. The downside is the same in reverse. The README itself flags the gaps: street-name search on OpenStreetMap is incomplete and search on Garmin maps is still work in progress, so a configuration that works for display and routing may still not find the street you are looking for. Add the experimental traffic module and the friends tracking mode marked experimental, and the picture is of a capable system with a few parts that are not yet finished. The interface layer, GTK and SDL with touch-screen support, is aimed at embedded car hardware rather than at a phone, which tells you who the author had in mind. ## Conclusion Navit suits an enthusiast or a small team who wants turn by turn navigation from map data they control, running on an Android tablet or a Linux car computer, and who is prepared to tune the configuration and build from source when a packaged build is not enough. It is the wrong tool for someone who wants a phone app that works in ten minutes, since the map format support is uneven and several features are still marked as work in progress. Before you adopt it, read the map support page for your actual map source, because display, routing and search support differ per format, and confirm the position source you have, since gpsd, a NMEA device and a mobile location service are separate code paths. ## FAQ ### Which map formats does Navit support? The README lists OpenStreetMap with display, routing and incomplete street-name search, the Grosser Reiseplaner maps and compliant maps with full support, and Garmin maps with display and routing while search is still being worked on. Points of interest are supported in many formats. ### How does Navit get the current vehicle position? The README lists four sources: a file or port, gpsd either local or remote, the location service of several mobile platforms, and a UDP server for friends tracking, which is marked experimental. ### Which routing algorithm does Navit use? It uses LPA*, the Lifelong Planning A* variant, running backwards from the destination by assigning an estimated time to reach the destination to each connected point, using a Fibonacci-heap search for the lowest value point and repeating until the origin is found. An experimental traffic module re-evaluates route graph portions as segment costs change. ## Sources - [Issues](https://github.com/navit-gps/navit/issues) - [navit-gps/navit on GitHub](https://github.com/navit-gps/navit) - [Project website](http://www.navit-project.org) - [README](https://github.com/navit-gps/navit/blob/trunk/README.md) - [Releases](https://github.com/navit-gps/navit/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/navit-gps-navit