Sightline turns OpenStreetMap into a search engine for real-world assets

A search interface over crowd-sourced map data

Sightline is described as a geospatial infrastructure intelligence platform for discovering and analyzing physical-world assets using OpenStreetMap data, and the repository description calls it an OSINT search engine for mapping real-world infrastructure from OpenStreetMap data.

The scope is broad. The overview lists telecommunications towers and data centres, power plants, substations and energy storage, airports, helipads and cable transport such as gondolas and funiculars, ports, harbours, piers and maritime facilities, warehouses and industrial facilities, pipelines, refineries and energy infrastructure, military installations, hospitals, prisons, embassies and government facilities, surveillance cameras and emergency infrastructure, and transportation hubs like train stations, bus stations and taxi stands. The README puts the number at 30 or more categories with over 200 searchable infrastructure types.

The project is written in TypeScript on Next.js, with React 19, Leaflet and react-leaflet for the map, Tailwind 4 for styling and a version of the package at 0.1.0. The licence is MIT, the homepage is sightline-maps.vercel.app, and the repository is not archived with the last push on 2026-05-10 and no GitHub releases, so there is no version to pin and a deployment of `main` is a deployment of whatever that branch currently holds.

Parse, geocode, query, cache

The architecture diagram in the README is the clearest description of what the server does, and it splits into three parts.

The frontend holds a `SearchBar`, `Filters`, a `ResultList` and a `MapView` built on Leaflet.js, and all four post to a single endpoint, `POST /api/search`, which lands on `route.ts`, the request handler.

The backend is five modules. `parser.ts` is described as the NLP engine and is handed the query string. `geo.ts` does geocoding and is called to resolve a location. `overpass.ts` is the OSM query builder and is called to fetch points of interest. `cache.ts` is a cache layer that the handler both reads from and writes to. And `ManagedProcess` style process management is not part of this picture, because there is no process to manage: the work is a request cycle.

The two external services close the loop. `geo.ts` geocodes through Nominatim, and `overpass.ts` sends a QL query to the Overpass API. The cache sits between the handler and both, so repeated queries for the same area and the same filters do not hit the public endpoints twice.

That cache is the reason the platform is usable at all, since Nominatim and Overpass are public services with usage policies, and a mapping tool that queried them on every keystroke would be a bad citizen of both.

Two ways to ask the same question

The query syntax section offers a natural language form and a structured form, and the examples show the same intent written twice.

In natural language:

telecom towers in karnataka
power plants near mumbai
data centers in california
airports in germany

And in the structured form:

type:telecom operator:airtel region:karnataka
type:data_center operator:google
type:substation region:texas
type:airport country:france

The supported parameters are a short list. `type:` selects the asset type, `operator:` filters by operator or owner, `region:` filters by state or region, `country:` by country, `near:` is a proximity search, and `radius:` sets the search radius in kilometres.

The distinction between the two forms is where the parsing work sits. The natural language form has to decide that `telecom towers` means the `telecom` type and that `in karnataka` is a region filter rather than part of the type, and the structured form sidesteps all of that by being explicit. Both end up as an Overpass query, and the README describes the intermediate step as the `overpass.ts` module building a QL query, which is the actual language the Overpass API speaks.

So the platform is two things layered: a natural language front end over a query language, and a UI over the results of running that query against a public endpoint.

The asset taxonomy is the substance of the project

A large part of the README is a taxonomy, and reading it tells you what the tool is actually good at.

Energy and power is the largest category, covering `power_plant` with the alias `powerplant`, `substation`, `transformer`, `converter`, `switch`, `power_line`, `power_pole`, and the generation types `solar`, `wind`, `nuclear` with the alias `nuclear_site`, `hydroelectric`, `geothermal`, `coal`, `gas_power`, `oil_power`, `biogas`, `biomass`, `tidal`, and `battery_storage`.

Telecommunications covers `telecom` with the alias `tower`, `antenna`, `mast`, `cell_tower`, `radio_tower`, `broadcast_tower`, `satellite_dish`, `telephone_exchange`, and `data_center` with the alias `datacenter`.

Oil, gas and mining covers `refinery`, `pipeline`, `oil_well`, `gas_well`, `storage_tank`, `silo`, `gasometer`, `quarry` with the alias `mine`, `landfill` and `scrap_yard`. Water and utilities covers `water_tower`, `water_treatment`, `wastewater` with the aliases `sewage` and `sewage_plant`, `dam`, `reservoir`, `pumping_station` and `water_well`.

Aviation covers `airport`, `helipad`, `airfield`, `runway`, `taxiway`, `terminal`, `hangar` and `atc_tower`. Maritime covers `port` with the alias `seaport`, `harbour`, `ferry_terminal`, `marina`, `shipyard`, `dock`, `lighthouse`, `pier`, `jetty`, `slipway`, `mooring` and `boat_lift`. Rail and transit covers `train_station`, `railyard` with the alias `rail_yard`, `metro`, `tram_stop`, `halt`, `level_crossing`, `bus_station`, `parking`, `toll_booth` and `weigh_station`.

The aliases are the detail that shows the work. A user types `data centers` and the tool has to reach the `data_center` type, and the alias table is how that happens without asking the user to memorise the OSM tag names. It is also the part most likely to need extending, since every new category someone adds to OSM needs a matching entry here.

The data is crowd-sourced, and the README says so

The data sources section is where the platform's real limits are, and the README is direct about them. All infrastructure data comes from OpenStreetMap, a collaborative mapping project, and the README warns that OSM data is crowd-sourced and may contain inaccuracies or gaps.

That sentence is the most important line in the document for anyone using it for actual research. A query for power plants in Texas returns what OpenStreetMap contributors mapped, and in a country with an active mapping community that is a good answer, while in a region with thin coverage it is a list of the sites somebody happened to add. The platform does not know the difference and will present both the same way.

The two supporting services are the standard public OSM ones. Geographic resolution uses the Nominatim geocoding service to convert place names into bounding boxes and coordinates, and infrastructure queries execute against the Overpass API, which provides read-only access to OSM data. The repository topics name `overpass-turbo` as well, which is the query tool most people already use by hand for the same job.

So the comparison a reader should make is not Sightline against other map tools, but Sightline against writing the Overpass query yourself. The platform adds a natural language parser, a curated asset taxonomy, a map interface with clustering, and a cache. What it does not add is coverage, accuracy or a second source of truth.

Running it is a Next.js application

The package manifest shows a conventional Next.js project, with four scripts:

  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "eslint"
  },

The dependencies explain the interface. `next` at 16.1.6 with `react` and `react-dom` at 19.2.3, `leaflet` at 1.9.4 with `react-leaflet` at 5.0.0 for the map, `leaflet.markercluster` and its types for grouping results at low zoom, a Radix scroll area for the result list, `clsx` and `tailwind-merge` with `class-variance-authority` for the component styling, and `@vercel/analytics` for analytics.

The development tooling is Tailwind 4 through `@tailwindcss/postcss`, TypeScript 5, eslint 9 with the Next config, and a Babel plugin for the React compiler. The repository layout is a standard Next.js tree, with `app/` for the routes, `components/` for the UI pieces, `lib/` for the backend modules the architecture diagram names, `public/` for static assets, plus `next.config.ts`, `components.json`, `eslint.config.mjs` and `postcss.config.mjs`.

One detail worth noting: the package is marked `private` with the version at 0.1.0. It is an application rather than a library, so nothing here is meant to be consumed as a dependency, and the `0.1.0` is a version for the app rather than a published contract.

Editorial conclusion

Adopt Sightline when you want to query real-world infrastructure by phrase rather than by writing Overpass QL, and when the map data is good enough for your question, which it usually is for ports, power stations and data centres and often is not for anything sensitive. Do not adopt it as a verified inventory, since the README states that the OSM data is crowd-sourced and may contain inaccuracies or gaps. Verify first that the asset type you care about is in the taxonomy of 200 or more searchable types, that your queries stay inside the usage limits of the public Nominatim and Overpass services, and that the version you deploy matches the one you read, since the package is at 0.1.0 with the last push on 2026-05-10 and no published releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ni5arga/sightline on GitHub
4. Project website
5. README