Integrations · rfMAP

Vendor-neutral data your RF tools already speak

rfMAP is built to be consumed, not converted. The layer stack is delivered in formats compatible with RF planning tools, drive-test equipment and GIS tools across the ecosystem, so the data drops into the toolchain your planners already run rather than asking them to switch.

Get a demo →

The compatibility problem

Planning tools want data your GIS cannot produce

RF planning tools, drive-test equipment and GIS platforms each expect data in their own shape. When the 3D layers an RF team needs do not come ready for those tools, the data sits behind a conversion step, and conversion is where geometry and detail quietly degrade.

rfMAP is designed the other way around. The authentic 3D layer stack is delivered in formats compatible with the tools planners already run, so the data feeds the existing workflow instead of forcing a switch or a rebuild.

What the ecosystem reads

One dataset, every major tool category

rfMAP output is vendor-neutral by design. The same layers feed the three tool families an RF rollout depends on, with no rip and replace.

  1. 01

    RF planning tools

    The 3D layer stack loads into RF planning tools across the ecosystem, the environment where coverage, line-of-sight and densification are actually modeled.

  2. 02

    Drive-test equipment

    Output formats are compatible with drive-test equipment, so measured-versus-predicted work runs against the same authentic basemap.

  3. 03

    GIS platforms

    The layers feed GIS tools across the ecosystem, with a MapInfo heritage in the data lineage, so geospatial teams keep their existing platform.

The deliverable

The layer stack, delivered tool-ready

Integration is not an afterthought bolted onto the data, it is what the deliverable is. Each rfMAP layer is produced to drop into a planning, drive-test or GIS workflow as a layer those tools already understand.

35 land-use clutter classes in the classification raster RF tools read
3 tool families fed from one dataset, RF planning, drive-test and GIS
Vendor-neutral formats, so the data drops into the toolchain you already run
  1. 01

    3D buildings, footprints and rooftops in 3D

    Per-building multi-polygon detail, delivered so the obstruction between an antenna and a user is modeled in the tool, not assumed.

  2. 02

    3D vegetation with real heights

    Stacked polygons carrying height attributes, because tree lines block signal the way buildings do.

  3. 03

    4D bridges with full geometry

    Bridge models carrying height, width, depth and length for spans over corridors.

  4. 04

    DTM and DSM/Clutter Height, terrain and surface models

    A bare-earth Digital Terrain Model and a Digital Surface Model that includes buildings and vegetation, the two elevation surfaces a link profile reads.

  5. 05

    2D vectors, roads, rivers and coastline

    Linear vector layers that ground the 3D data in the network and the world around it.

  6. 06

    Clutter, land-use classification

    A land-use and land-cover raster of up to 35 classes, the clutter layer RF tools tune propagation against.

A shared part of the RF ecosystem

rfMAP grew up inside the RF planning ecosystem rather than alongside it. The data lineage carries a MapInfo heritage, and the same authentic 3D layers sit next to the planning and analytics tools operators already use, including names like Infovista and Teoco that appear among the platforms and partners rfMAP works with.

That heritage is the point of being vendor-neutral. The goal is to make every tool in the chain stronger by feeding it better data, not to replace any of them.

One dataset. Every tool.

The same authentic 3D dataset feeds the RF planning, drive-test and GIS tools across the ecosystem, and powers Lepton's own products too. The data is the hub, the tools are the spokes.

Inside the portfolio

The same data powers Lepton products

The clearest proof that rfMAP is built to be consumed is that Lepton builds on it too. The authentic 3D layer stack is the foundation under several products in the portfolio, each reading the data for a different planning job.

  1. 01

    neo360, 5G fixed-wireless planning

    neo360 uses the 3D data for line-of-sight and Fresnel analysis when qualifying fixed wireless access.

  2. 02

    SmartSignal, digital-twin analytics

    SmartSignal runs digital-twin analytics on the same authentic geodata that RF planners build on.

  3. 03

    NetworkAccess, wireless network modules

    The wireless modules in NetworkAccess draw on the rfMAP layer stack as their geospatial foundation.

What vendor-neutral data changes

  1. 01

    No rip and replace

    The layers feed your RF planning, drive-test and GIS tools directly, so adopting rfMAP does not mean swapping the tools your teams already know.

  2. 02

    No conversion tax

    Data delivered tool-ready skips the conversion step where geometry and detail quietly degrade, so planners read authentic 3D, not a lossy copy.

  3. 03

    One source across the chain

    Planning, drive test and GIS all read the same dataset, so measured, predicted and mapped views agree instead of drifting apart.

Proof

The dataset the industry plans on

Vendor-neutral data only matters if the data is the one the industry already trusts. More than 95% of India 5G deployment runs through the Lepton 3D dataset, and the same data is read by operators, network OEMs and tower companies worldwide.

India 5G >95% of India 5G deployment through the Lepton 3D dataset
  • Airtel
  • Reliance Jio
  • Vodafone Idea
  • Ericsson
  • Nokia
  • American Tower
Get started

Drop rfMAP into the tools you already run.

Tell us your RF planning, drive-test and GIS stack, and we will show you the rfMAP layers in the formats those tools read.

Get a demo →