A whole dataset in one PMTiles
Boundaries, hydrography or an indicator become a single file with tippecanoe or ogr2ogr -f PMTiles, read by the browser through range requests, with no map server.
pmtiles verify and a drop log
Octo for web maps and tiles
Municipal boundaries, indicators, orthophotos and cadastral data can become tiles from the command line: tippecanoe and GDAL generate them, PMTiles stores everything in one static file, MapLibre draws in the browser from a JSON style and PostGIS serves same-day tiles through Martin. Octo writes the scripts, checks tile size and style against the data and delivers to staging. Classification, generalization, what can be published and the move to production stay with qualified people.
Six possible deliverables, drawn from the research. All start from a copy of the data, with read access to the official database, and all go to review by whoever is accountable for the map.
Boundaries, hydrography or an indicator become a single file with tippecanoe or ogr2ogr -f PMTiles, read by the browser through range requests, with no map server.
pmtiles verify and a drop log
Writes the JSON style with the approved classes, zoom expressions, labels and attribution, and checks each layer against the tileset metadata before publishing.
Deliverable: style reviewable line by line and an audit reportVirtual mosaic of the sheets and gdal raster tile in WEBP, with tile counts per zoom and a sample to look at; migrates old gdal2tiles routines.
A public view with no personal data and an ST_AsMVT function served by Martin, for layers that change every day, such as cadastral records and public works.
Finds pages that load the library through <script src>, old style expressions and WebGL 1 dependencies, and proposes the switch to an ES module.
When the consumer is a government agency or a desktop client, sets up WMS/WMTS in GeoServer, QGIS Server or MapProxy, and reads the GetCapabilities of official services such as IBGE's.
The same Octo cycle, applied to tiles and web maps. Each arm has a narrow role; the ones who decide classes, approve what goes public and publish to production are people.
Pages with maps, MapLibre or Leaflet version, tile folders (XYZ or TMS), OGC servers, gdal2tiles routines and where each piece of data comes from.
Reference system of the dataset, key fields (IBGE code, parcel number), zoom ranges per layer, and which one is the official dataset and which one is the working copy.
No personal data in the tile, restricted CORS, bucket credentials outside the script, base map key locked to the domain. Cadastral records with owner data go through LGPD review with the client.
Static file, tile server or OGC service, based on update frequency and who consumes it; tippecanoe or GDAL; vector or raster.
Generation with simulation and a log, JSON style with the approved classes, SQL function with rollback and the map page, with the source of each syntax noted.
Feature counts, tile sizes, style against metadata and the map opened in the browser, looking at the content, not just the absence of errors.
Only with your OK, it sends the file and the style to the staging environment. The switch in production is done by a person.
Tool versions, generation parameters, approved classes, date and origin of each publication. What worked for one dataset is not assumed ready for another.
Octo works with read access and as support. It does not change the official database, does not publish to production and does not sign cartographic products: that belongs to qualified people.
The criteria Octo uses to choose, with the documentation for the version installed in your environment.
| Task | Path | Note |
|---|---|---|
| Data that rarely changes, heavy traffic | tippecanoe → PMTiles in a bucket | Server needs Range and CORS |
| Data that changes every day | ST_AsMVT + Martin | Public view with no personal data |
| Source in several formats | ogr2ogr -f PMTiles or -f MVT | Less control over dropping |
| QGIS project already set up | qgis_process run native:writevectortiles_xyz or native:tilesxyzdirectory | Raster keeps the QGIS rendering |
| Orthophoto | gdal raster tile (GDAL 3.11+) | gdal2tiles deprecated in 3.13 |
| New indicator on existing geometry | tile-join -c | No geometry regeneration |
| Clip of a large tileset | pmtiles extract --bbox --maxzoom | Works with a remote file |
| Consumer requires WMS/WMTS | GeoServer, QGIS Server or MapProxy | Common in government agencies |
| Old page with MapLibre 5 | Migrate to <script type="module"> | WebGL 2 required in v6 |
Three steps. Each one only makes sense after the previous one has shown results on your team.
A proposal, not a promise
You point to the dataset and the indicator; Octo generates the PMTiles, writes the style and delivers to staging for review.
Style and tiles always go through the same check, and the new orthophoto is tiled with counts and a sample.
gdal2tiles routines migratedCadastral records and public works served from PostGIS the same day, and reference datasets regenerated on a schedule, with a summary read by Octo in the morning.
ST_AsMVT functions with a public viewEvery point below has a source published by the responsible body (Planalto, IBGE, the Brazilian Army, CONCAR), by the project or by the standards organization. The sources are in the next section.
4
points with a published source, each with its reference alongside.
maplibre-gl-style-spec package moved to version 25 (the style's version field is still 8), which warns on old expressions. The current version is v6.16.0, from October 25, 2026.Source: maplibre-gl-js releases (GitHub)gdal2tiles runs through gdal raster tile by default (available since 3.11); --legacy forces the old code and is expected to be removed in 3.15. Without --xyz, the order is TMS.Source: gdal2tiles and gdal raster tile documentation (gdal.org)application/vnd.pmtiles. tippecanoe limits tiles to 500K bytes and 200,000 features by default; the GDAL MVT driver uses a MAX_SIZE of 500000.Source: PMTiles v3 specification; tippecanoe repository; MVT driver (gdal.org)tile.openstreetmap.org policy requires visible attribution and a proper User-Agent and prohibits bulk downloading, prefetching and offline use, with no availability guarantee. For offline or heavy use, the way to go is self-hosting or a provider that allows offline use.Source: OSMF Tile Usage PolicyOcto prepares everything, but does not sign. The document of record stays with whoever is accountable for it.
Surveys, calculates, organizes and produces the documents: spreadsheets, reports, sheets, maps and drafts.
Deliverable: material ready to checkThe licensed professional checks what Octo delivered before signing. If something doesn't add up, it goes back to Octo with the correction.
Step: review by the signerOcto does not sign. Designs, technical reports, ART/RRT (Brazil's professional responsibility records), accountability reports and any official document are still signed by the company's or agency's licensed professional: here, the cartographic engineer or another licensed professional, with an ART; official data goes into the INDE only after approval by the competent authority.
Sign-off: licensed professional, with ARTProject documentation and release pages, and IBGE services, accessed on October 31, 2026.
The assessment starts with a map your team already publishes or wants to publish, without touching the official database. You get a proposal for what can be generated and checked by script, with a trial on a known dataset, and decide with it in hand.