India map boundary compliance: what the law actually requires (2026)
Google, Mapbox, MapTiler, Mappls, and maps.guru all draw India differently. What the Criminal Law Amendment Act 1961 and the 2021 Geospatial Guidelines actually require, which providers render India official boundaries, and what your options are.
If you ship a map of India, the boundary you draw is a legal question, not a styling one. Google Maps, Mapbox, MapTiler, Stadia Maps, Mappls, and maps.guru do not all draw India the same way. Under the Criminal Law Amendment Act 1961, publishing a map of India that does not conform to Survey of India maps is punishable by up to six months' imprisonment, a fine, or both.
We are maps.guru, an Indian company, and we render India's official boundary — our tile pipeline suppresses OpenStreetMap admin_level=2 boundaries inside the India bounding box and replaces them with SoI-derived boundary data from the DataMeet India community. Most global providers do not do this. This post explains what the law says, what each provider actually renders, and where the honest limits of our own claim are. Every claim links to the primary source.
The short version
What the law requires: For political maps of India at any scale — national, state, or other boundaries — Survey of India published maps or SoI digital boundary data are the standard to be used. That is clause xiii of the 2021 Geospatial Guidelines, verbatim. The Guidelines add that "others may publish such maps that adhere to these standards."
The penalty: Criminal Law Amendment Act 1961, Section 2(2) — "Whoever publishes a map of India, which is not in conformity with the maps of India as published by the Survey of India, shall be punishable with imprisonment which may extend to six months, or with fine, or with both." Section 2(3) limits this: no court takes cognizance except on a complaint made by the Government.
Who renders India's official boundary: Mappls (MapmyIndia) builds on Survey of India aligned data under formal agreements with the agency. Google Maps serves India's official view to users in India through country-specific serving. maps.guru renders SoI-derived boundaries from DataMeet's open dataset. Providers rendering raw OpenStreetMap — Mapbox (without the worldview parameter), MapTiler, and Stadia Maps — show the Line of Control and disputed segments rather than India's full official claim.
A licensing relationship is a separate thing from conformity. Rendering the correct line and holding a commercial arrangement with SoI are different claims, and we make only the first. More on that below.
What "the official boundary" means in practice
Three areas differ between India's official map and the depiction most global providers ship:
- Jammu and Kashmir — India's official map shows the entire former princely state, including Pakistan-administered Gilgit-Baltistan and Azad Kashmir. OSM-derived maps typically render the Line of Control as the effective boundary.
- Aksai Chin — claimed by India, administered by China. India's official map includes it; most international depictions show it on the Chinese side or as disputed.
- Arunachal Pradesh — Indian state, claimed by China. Usually rendered as Indian territory but sometimes with a disputed-boundary treatment.
The difference is not cosmetic. A map that renders the LoC as a settled international border is, on a strict reading, a map "not in conformity with" Survey of India maps.
What each provider actually renders
| Provider | Boundary source | Renders India's official line | Uses the SoI boundary standard (clause xiii) | Notes |
|---|---|---|---|---|
| Mappls (MapmyIndia) | Survey of India aligned data | Yes | Yes | Formal SoI agreements (Nov 2025) |
| Google Maps | Proprietary, country-specific | Yes (in India) | Not published | Serves India's official view to users in India |
| maps.guru | SoI-derived (DataMeet) + OSM + Overture/NE | Yes | Yes | OSM admin_level=2 suppressed inside India bbox |
| Mapbox | OpenStreetMap + proprietary | Only with worldview=IN | No | Defaults to the OSM depiction |
| MapTiler | OpenStreetMap | No | No | OSM depiction |
| Stadia Maps | OpenStreetMap | No | No | OSM depiction |
| Ola Maps | Proprietary, India-built | Presumed yes | Not published | India-only provider, India data residency |
Why this column is not "SoI certified"
Because for a tile API, there is no such thing — and the distinction is worth understanding before you evaluate any vendor's compliance claim.
Survey of India does run a boundary scrutiny and certification process, but read what it actually asks for: "Two proof copies of each map (hard copy)", ₹2,450 per map, a release order issued for printing, and a certificate that "is valid for six months… the map must be printed within six months". It is a per-artefact, print-publication process. A vector tile API generates a different image at every zoom, viewport and style — there is no finite set of proofs to post to Dehradun, and nothing gets printed. No web mapping provider holds this certificate for its API, and any vendor implying otherwise is describing something else.
What actually governs digital maps is the Geospatial Guidelines of 15 February 2021, which deregulated the sector: "there shall be no requirement for prior approval, security clearance, license or any other restrictions on the collection, generation, preparation, dissemination, storage, publication, updating and/or digitization of Geospatial Data and Maps within the territory of India. Self-certification will be used to convey adherence."
Under that regime the boundary test is clause xiii — "For political Maps of India of any scale… SoI published maps or SoI digital boundary data are the standard to be used… Others may publish such maps that adhere to these standards." That is the column above, and it is the question that actually determines whether you are compliant.
Adherence is conveyed through the DST National Geo-Spatial Service Portal, a free self-certification open to Indian and foreign entities alike, which issues a downloadable certificate. Clause 10 of its undertaking restates the same requirement: "the Survey of India digital boundary data shall be used as standard for publishing political Maps of India."
Google and Mapbox solve this with country-specific serving: the same API returns a different boundary depending on the requesting region or an explicit parameter. Mapbox documents this as the worldview parameter, which defaults to the OpenStreetMap view unless you request IN; Google applies it automatically based on the domain and user region.
We take a different approach. Rather than serving different boundaries to different users, our tiles carry India's official boundary for every consumer of the tileset.
How we do it
Our tile pipeline treats India's boundary as a first-class input rather than something inherited from OpenStreetMap:
- Suppression. OSM boundary features with
admin_level=2whose geometry falls inside the India bounding box (68.0, 6.5to97.5, 37.2) are dropped during tile generation. - Replacement. An official India boundary GeoJSON is injected in their place, emitted into the
boundarieslayer from zoom 6 upward withkind: country,kind_detail: 2. - Everything else is conflated normally. Overture Maps, OpenStreetMap, and Natural Earth supply the rest of the planet, including all non-boundary features inside India.
The boundary dataset comes from DataMeet, the Indian open-data community that maintains Survey of India derived boundary files under CC BY 4.0.
The geometry verifiably follows India's official claim rather than the Line of Control. It reaches 37.10°N in the north, matching India's official claim including Gilgit-Baltistan, where an LoC-based depiction stops near 35.5°N. It includes Aksai Chin, extending east to 80.42°E above 34.5°N.
Disputed boundaries elsewhere in the world keep their disputed and disputed_by attributes, so the tileset stays accurate about genuinely contested borders outside India.
The threshold rule almost nobody explains
The 2021 Guidelines apply different rules depending on how accurate your data is. This is clause iv(a)(1), and it matters more than most compliance write-ups admit:
The threshold value for on-site spatial accuracy shall be one meter for horizontal or Planimetry and three meters for vertical or Elevation.
Data finer than that threshold triggers two hard requirements:
- Clause vii — may only be created or owned by Indian Entities, and "must be stored and processed in India."
- Clause ix — "shall only be stored and processed on a domestic cloud or on servers physically located within territory of India."
Data up to the threshold has no such restriction — clause ix explicitly permits it to "be uploaded to the cloud," and clause x removes export restrictions for it.
Why this matters for API consumers: a general-purpose vector basemap is far coarser than one-metre accuracy. Standard web-map tiles, geocoded points at building or locality resolution, and routing geometry sit above the threshold, so the storage-in-India requirement in clauses vii and ix does not bite for them. If you are capturing survey-grade data — drone photogrammetry, LIDAR, mobile mapping, CORS-corrected GNSS — you are below the threshold and those clauses apply in full.
The Guidelines also restrict two activities to Indian Entities regardless of accuracy: terrestrial mobile mapping, street view survey, and surveying in Indian territorial waters (clause vi(b)).
What "Indian Entity" means
Clause 7(f) defines it precisely: any Indian citizen, Government entity, registered society, statutory body, autonomous institution, "or any Indian company or Indian LLP owned by resident Indian citizens or any Indian company or Indian LLP controlled by resident Indian citizens."
This is the clause that determines whether you can hold fine-accuracy data at all. Foreign companies and foreign-controlled Indian companies may only license such data from Indian Entities, and clause viii requires that access be "made available through APIs that do not allow Maps/Geospatial Data to pass through Licensee Company or its servers." Re-use or resale is prohibited.
maps.guru is operated by Invarya Technologies Private Limited, an Indian company based in Pune — so clause vi and clause vii are available to us in principle. Being an Indian Entity is a prerequisite for holding fine-accuracy data; it is not the same as having a formal data arrangement with Survey of India, and we do not claim one.
Note the wording of clause xiii carefully: it says SoI maps or SoI digital boundary data "are the standard to be used," and that "others may publish such maps that adhere to these standards." The obligation is conformity to the standard, not possession of a licence. That distinction is why rendering an SoI-derived boundary and holding a formal SoI arrangement are separate claims — and we make only the first.
The liberalisation nobody noticed
The 2021 Guidelines were a substantial deregulation, and a lot of advice still circulating online predates them. Clause ii(1) is explicit:
Save as specifically provided for under these guidelines, there shall be no requirement for prior approval, security clearance, license or any other restrictions on the collection, generation, preparation, dissemination, storage, publication, updating and/or digitization of Geospatial Data and Maps within the territory of India.
Compliance is by self-certification. The Guidelines also state there is "not any negative list of prohibited areas" — the negative list covers sensitive attributes, not geographies.
So the regulatory burden for a typical product team is narrower than the folklore suggests: use SoI boundaries for political maps, stay above the accuracy threshold or keep fine data in India, and don't tag attributes on the negative list.
Your options, ranked by how much you need this
1. You need compliance with a paper trail. Two different documents get called this, and they are not interchangeable.
If you are printing a map — an atlas, a textbook, a poster, a report figure — you need SoI's boundary scrutiny certification. Post two hard-copy proofs to the Boundary Verification Wing in Dehradun with the application form, pay ₹2,450 per map (₹600 for additional maps at the same scale and layout in the same submission), and SoI either certifies it or returns a correction trace showing the right alignment. The release order is valid six months and the map must be printed within that window. At 1:4 million or larger you also need security clearance from the Ministry of Defence first.
If you are shipping software, that process does not fit and no provider holds it for an API. What applies is self-certification on the DST National Geo-Spatial Service Portal — free, open to Indian and foreign entities, certificate downloadable, renewable annually. Clause 10 of the undertaking is the boundary commitment: SoI digital boundary data as the standard for political maps of India.
For government tenders, ask which one the tender actually names before assuming. Where a documented SoI relationship is genuinely required, Mappls has formal agreements with the agency; SoI also publishes political maps and an administrative boundary database, and clause xiii requires they be "made easily downloadable for free" with digital display and printing permitted.
2. You need the correct boundary rendered, without a procurement paper trail. This is most commercial products. maps.guru renders the SoI-derived boundary by default, with no worldview parameter to remember and no per-region serving logic to get wrong. Google serves the correct view to users in India. Mapbox needs worldview=IN explicitly.
3. You render a general-purpose basemap on raw OSM tiles. The practical risk is low — Section 2(3) means prosecution requires a Government complaint, and enforcement has historically targeted published atlases, textbooks, and news graphics rather than developer basemaps. But "low risk" is not "conformant," and switching to a provider that renders the official line costs nothing at the API layer.
4. You need India data residency, not boundary conformity. Different problem, different answer — see our India data residency guide. Short version: Ola Maps is the only major provider offering it today.
5. You're capturing your own survey-grade data. Clauses vi, vii, and ix apply directly. You must be an Indian Entity and the data must stay on Indian infrastructure.
Where we stand
maps.guru renders India's official boundary. Our pipeline suppresses OpenStreetMap admin_level=2 features inside the India bounding box and replaces them with SoI-derived boundary data from DataMeet, verified above to follow India's official claim rather than the Line of Control. That is the default for every tile we serve, not a parameter you have to opt into.
Two things we do not claim, because they are different claims:
- We have no commercial arrangement with Survey of India. Mappls does — its borders follow SoI and it signed formal agreements with the agency in November 2025, including powering SoI's National Geo-Platform. If your procurement requires that documented lineage rather than conformity alone, Mappls is the correct answer and we will say so.
- We do not offer India data residency. We run on Cloudflare's edge, which cannot guarantee India storage today. If residency is contractual, Ola Maps is the answer — the reasoning is in our data residency guide.
What we do offer is the correct India boundary, INR billing, edge-served vector tiles, and flat pricing with no sales call — see pricing or the tiles overview.
Sources
- Survey of India — Contents of Geospatial Data Guidelines (2021)
- Criminal Law Amendment Act 1961 (MHA PDF)
- Section 2(2), Criminal Law Amendment Act 1961
- Survey of India online maps portal
- Mapbox
worldviewboundaries reference - Mappls API hub
- DataMeet maps repository (CC BY 4.0)
- Maps in publications: permissions, restrictions and legal consequences — Obhan & Associates
This post is engineering guidance, not legal advice. If boundary conformity is a compliance requirement for your product, take Indian counsel.
For provider-by-provider comparisons see our Mapbox alternative and Mappls alternative pages, or the Google Maps alternatives roundup.