# Rapid is an OpenStreetMap editor built around data checks, country coverage and a browser bundle you can embed > facebook/Rapid is the web editor used for large OpenStreetMap mapping operations, with built in integrity checks, per country authoritative data, and a split build pipeline that produces a distributable bundle. Coverage is limited to the countries on the request list, and the latest published release is older than the current source version. **facebook/Rapid** — The OpenStreetMap editor driven by open data, AI, and supercharged features - Repository: https://github.com/facebook/Rapid - Website: https://rapideditor.org - Stars: 643 · Forks: 137 - Language: JavaScript - License: ISC - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/facebook-rapid ## An editor shaped by coordinated mapping campaigns Rapid is a browser editor for OpenStreetMap, and the way it is built reveals who it is for. The project description calls it an editor driven by open data with AI assisted features, and the surrounding documentation points at a training document for Open Mapping at Facebook. That is a campaigning workflow: many mappers, one area, consistent results. Two consequences follow. The editor is not a general purpose map viewer, and the documentation asks you to read the Code of Conduct and the Contributing Guide before contributing at all. There is a translations section, a channel for feedback on OpenStreetMap US and HOTOSM Slack, and a separate document for requests. Two usage paths exist. For ordinary mapping, the documentation points at rapideditor.org/edit for the latest release and rapideditor.org for the wider site. For testing, the current build of the main branch is published as a canary at rapideditor.org/canary, and the documentation warns plainly that this build may be unstable and buggy. The repository also carries files that describe how the project is governed and operated rather than how it works: CHANGELOG.md, RELEASING.md, PRIVACY.md, FAQ.md, COUNTRY_REQUESTS.md, API.md and a docs/ directory. For an evaluation, the Changelog and the training document are the two places where the feature list actually lives, since the overview is deliberately short. ## Integrity checks are the reason to use Rapid over a plain editor The feature that separates Rapid from a general OSM editor is described in one sentence of the project overview: Rapid includes data integrity checks to ensure that new map edits are consistent and accurate. In a mapping campaign, where dozens of people touch the same objects over a short window, that check is the whole point. A wrong edit is expensive to find later and expensive to revert, and the review burden falls on whoever is checking the changes. The project frames the wider stack the same way: advanced mapping tools combined with authoritative geospatial open data. Authoritative data is the point of the country coverage mechanism described below, and integrity checking is what keeps hand edits from contradicting it. What the documentation does not spell out is the internals of the checker: which validation rules fire, whether they are configurable per task, and what happens to an edit that fails. The documentation points to the Changelog and the training document for the enhanced feature list rather than describing a validation pipeline. If your evaluation depends on how strict the checks are, that document is where the answer has to come from, not from the repository overview. The AI framing deserves the same scrutiny. The package description in package.json calls Rapid an AI enhanced editor for OpenStreetMap, and the repository description mentions AI among its ingredients. No mechanism for it is described in the repository files, so treat it as a positioning statement until the Changelog or docs/ describe something concrete. ## Country data comes from a request list, not a download Rapid's data coverage is bounded by an explicit process, and this is the constraint most likely to disqualify it for a given project. The requests section has three rows. For country data, you submit a new issue asking for Rapid data for other countries. For features, you submit an issue requesting new capabilities. For roads, you are pointed at a list of available countries and asked to create the issue in the Rapid repository rather than in other repositories, with progress tracked on COUNTRY_REQUESTS.md. So the set of places you can map with Rapid is a curated list, and adding to it is a ticket, not a build. A team that needs to map a location outside that list faces a wait, and no timescale is given. The same shape applies to features. Requesting a capability is an issue, which means new functionality enters through discussion rather than through a configuration switch in your deployment. If your organisation needs a custom field, a specific tagging scheme, or an export format that is not in the editor, you cannot solve it by configuration alone. That constraint is also why the project keeps so much documentation around the edges: the training wiki, the available countries page, and COUNTRY_REQUESTS.md are all part of the practical workflow for anyone planning a campaign. ## The build produces two bundles and a pile of sprites The build system in package.json explains a lot about how the editor is shipped. The scripts section splits into build, dist and clean groups, and the clean script removes dist/esbuild.json, the built JavaScript, source maps, CSS and generated sprite files, which tells you the output layout before you read any esbuild config. The interesting part is the parallel naming. There are separate scripts for modern and legacy bundles in both dev and prod flavours, which means Rapid keeps one code path for current browsers and one for older ones. The bundle scripts run esbuild through config/esbuild.config.modern-dev.js and the matching legacy and prod files, and the CSS build runs scripts/build_css.js. Icon assets are generated rather than committed. Separate scripts build community, Font Awesome, Maki and Mapillary sign sprites, each invoking svg-sprite with a symbol destination and its own shape id generator, and writing into dist/img. The community sprite pulls from the osm-community-index package in node_modules. Data has its own build step: scripts/build_data.js writes into dist/data. So a working Rapid build produces JavaScript bundles, CSS, image sprites and a data directory, and the npm package publishes only dist, with dist/rapid.min.js as the main entry and the package marked as an ES module. ## Building from source with the npm scripts The repository is a JavaScript project managed with npm, with package-lock.json committed. The relevant entry points are in the scripts section of package.json, and the whole pipeline is driven by npm run scripts. ```json "name": "@rapideditor/rapid", "version": "2.5.7", "main": "dist/rapid.min.js", ``` The package name is @rapideditor/rapid and the version in the source tree is 2.5.7. The all script chains clean, build and dist, while the build script itself runs the build tasks in parallel: ```json "all": "run-s clean build dist", "build:css": "dotenvx run --quiet -- node scripts/build_css.js", "build:data": "shx mkdir -p dist/data && node scripts/build_data.js", ``` Note the dotenvx wrapper on the CSS script and the presence of a.env file at the repository root. Environment variables are loaded for build steps rather than hardcoded, which matters if you are reproducing a build in CI. Testing is set up with Karma, with karma.conf.cjs and a test/ directory in the tree, and the scripts also include benchmark targets that start a server and run benchmark suites in parallel, including a CI benchmark variant. The docs directory and the webdoc.conf.json file suggest API documentation is generated as part of the workflow, and eslint.config.js and.prettierignore cover linting and formatting. ## Embedding the editor in your own application The clearest route to using Rapid without hosting it yourself is the editor at rapideditor.org/edit, and the clearest route to integrating it is the examples directory. The project points developers at folders under dist/examples, described as example code to help you learn how to integrate the Rapid editor into your project. That is a meaningful distinction for platform teams. A hosted instance gives you a ready editor with country data already provisioned. Embedding means you are responsible for serving the bundle, keeping it in step with the data you want, and deciding how the editor talks to your own OpenStreetMap credentials. API.md describes the public interface, and the source of truth for the public methods is also in the docs/ directory. The dependency picture follows from the packaging. Since the npm package publishes only dist and points at dist/rapid.min.js, consumers get a prebuilt artifact and not the source tree, which is a deliberate separation between the editable repository and the distributed library. One caveat for anyone planning an upgrade path: the examples in dist/examples are tied to the current build layout, so they need to be revisited whenever the dist structure changes, and the changes to dist that scripts/build_data.js and the sprite scripts make are not described in detail. ## ISC licensing, but the releases lag the source tree Rapid is available under the ISC License, with details in the LICENSE.md file. ISC is a permissive licence with a short notice requirement and no copyleft obligation, which makes it comfortable to embed the editor in an internal or commercial web application. The canvas and data it renders are OpenStreetMap data, which carries its own attribution requirements that the licence text does not address. The release picture needs reading carefully. The repository is not archived and the last push was on 2026-05-28. The published release tags are rapid-2.5.6 from 2026-02-03, rapid-2.5.2 from 2025-01-17 and rapid-2.5.1 from 2025-01-15, while the version in package.json is 2.5.7. That means the source tree sits one version ahead of the newest tag, and the newest tag itself is about four months older than the last push. For a hosted deployment that is mostly irrelevant, since rapideditor.org/edit serves the latest release and canary serves the main branch build. For an embedder it matters a great deal: you are pinning a dist artifact, and the gap between 2.5.6 and the current source is where any fixes will be. Reading CHANGELOG.md before you pin a version is the concrete next step, and RELEASING.md describes how the project cuts releases if you need to understand that cadence. ## Conclusion Use Rapid if you are running a coordinated OpenStreetMap mapping project, or if you need to embed an OSM editor inside your own web application through dist/examples. Do not pick it for casual mapping in countries it does not carry data for, because the request process runs through the issue tracker rather than a download. Before adopting, check the list of available countries for your area, compare the published rapid-2.5.6 tag against the 2.5.7 version in package.json, and read CHANGELOG.md to see whether the features you need landed after that release. ## FAQ ### What is Rapid and who uses it? Rapid is a web based editor for OpenStreetMap that combines mapping tools with authoritative geospatial data and data integrity checks for consistent edits. It is built for coordinated mapping operations, with a training document maintained for Open Mapping at Facebook. ### How do I install Rapid for my own project? The editor is published on npm as @rapideditor/rapid, with dist/rapid.min.js as the main entry and only the dist directory in the package files. To build from source instead, the package.json scripts drive the pipeline, with all chaining clean, build and dist. ### Does Rapid support my country? Coverage is limited to a published list of available countries, and requests for additional country data are submitted as new issues in the issue tracker. Requests for roads for a new country are tracked on COUNTRY_REQUESTS.md. ### What does Rapid check before an edit is accepted? The documentation states that Rapid includes data integrity checks so that new map edits are consistent and accurate, without describing the individual validation rules in the repository overview. The Changelog and the training document are the places where the enhanced feature list is described. ### Which version of Rapid should I deploy? The latest published release is rapid-2.5.6 from 2026-02-03, while the source tree carries version 2.5.7 in package.json and the last push was on 2026-05-28. rapideditor.org/edit serves the latest release, and the main branch build is published separately as a canary that the project warns may be unstable. ### Can I embed the Rapid editor in my own web app? Yes. The project points developers to example code under dist/examples showing how to integrate the Rapid editor into a project, and the public interface is described in API.md and the docs directory. ## Sources - [facebook/Rapid on GitHub](https://github.com/facebook/Rapid) - [License: ISC](https://github.com/facebook/Rapid/blob/main/LICENSE) - [Project website](https://rapideditor.org) - [README](https://github.com/facebook/Rapid/blob/main/README.md) - [Releases](https://github.com/facebook/Rapid/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/facebook-rapid