Octo for vector datasets in ET-EDGV 3.0
An ET-EDGV 3.0 dataset is a PostGIS database with one schema for classes and another for domains. Creating that database, loading an old dataset, clipping IBGE's BC250 and flagging dangles and gaps between polygons all run through psql, ogr2ogr and qgis_process. Octo builds and checks these batches. The mapping of each feature, the acceptance of each fix and the approval of the data stay with the responsible cartographer.
Six possible deliverables, drawn from the research. All run on a working database, with read access to the official one, and all go to review by whoever is technically accountable for the data.
Creates the PostGIS database from the SQL that DSG Tools publishes for ET-EDGV 3.0, replaces the SRID placeholder, checks the number of classes and domains and applies it in a single transaction.
Deliverable: working database and hash of the model usedInventories the legacy dataset, counts the values in each field and proposes the table that maps source layer and code to EDGV class and domain, with a status for the cartographer.
Deliverable: mapping CSV with real countsImports into a staging schema with ogr2ogr and loads the classes through SQL: 9999 where the source doesn't say, geometry made valid and input-versus-output counts.
Invalid geometry, polygon coverage, gaps, dangles, crossings without a node and pending attributes, through SQL in PostGIS and DSG Tools algorithms in qgis_process.
Downloads BC250 2025 with a hash, clips it to the project area and measures length in Polyconic and area in Albers, with the parameters the IBGE documentation specifies.
Deliverable: GPKG clip and recorded measurementsAnswers "does this column exist?", "which code is dry?" and "which classes does BC250 not include?" by reading the model SQL and the documentation, without opening QGIS.
Deliverable: answer with source file and lineThe same Octo cycle, applied to ET-EDGV datasets. Each arm has a narrow role; the ones who map the feature, accept the fix and approve the data are people.
Where the CAD, shapefile, geodatabase and PostGIS data live; which EDGV version each one follows; whether there is a DSG Tools database and from which model.
Classes, columns and domains taken from the model SQL; mapping table with real counts; product SRID and scale pinned before the load.
Connection through a PostgreSQL service, no password in scripts; read access to the official database. Records with personal data are assessed with the client (under Brazil's LGPD) before anything leaves the environment.
SQL in PostGIS or a DSG Tools algorithm for each rule; direct load or staging schema; GeoPackage or dump for BC250.
Scripts with a trial run, simulation, transaction and count check, with the source of each syntax noted in the file.
Input equals loaded plus discarded plus no-geometry; kilometers before and after; an area the team knows opened in QGIS.
Only with your OK, it runs the COMMIT on the working database. Moving it to the official database is done by a person.
Model commit, approved mapping table, tolerances, counts and pending items for each batch. One city's mapping table is not assumed ready for another.
Octo works with read access and as support. It does not edit the official database, does not approve data and does not sign cartographic products: that belongs to licensed professionals, with an ART.
The criteria Octo uses to choose, with open-source tools and IBGE's public datasets.
| Task | Path | Note |
|---|---|---|
| Create an ET-EDGV 3.0 database | DSG Tools SQL with [epsg] and # replaced, psql --single-transaction | Pin the model commit |
| Find out whether a column exists | grep in the SQL or in the models repository | Without opening QGIS |
| Inventory a legacy dataset | ogrinfo -ro -so -al | Count and fields per layer |
| Import into PostGIS | ogr2ogr -lco SCHEMA=staging -lco GEOMETRY_NAME=geom -nlt PROMOTE_TO_MULTI -makevalid | Never directly into the edgv schema |
| Map to the classes | SQL with a mapping table | Mapping table approved by the cartographer |
| Validate geometry and coverage | ST_IsValidDetail, ST_CoverageInvalidEdges | Writes flags, does not fix |
| Validate with DSG rules | qgis_process run dsgtools:<algorithm> | Output in GPKG and JSON |
| Fix coverage | ST_CoverageClean on a copy | PostGIS 3.6 and GEOS 3.14; only after approval |
| Use BC250 2025 | Official GeoPackage, sha256sum, ogr2ogr -spat -clipsrc | 1:250,000 scale; boundaries with no official standing |
| Measure area and length | Albers for area, Polyconic for length | Parameters from the IBGE documentation |
Three steps. Each one only makes sense after the previous one has shown results with your mapping team.
A proposal, not a promise
Octo reads the model and your datasets and tells you what exists, in which version and what is missing, without changing anything.
Legacy datasets enter the model through a trial load, with a pending-items report and count checks.
Each editing batch goes through the same set of rules before reaching the reviewer, with the summary read by Octo.
Every 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.
edgv and dominios schemas, 292 and 146 tables, domains through foreign keys with code 9999 "A SER PREENCHIDO" (to be filled in), commands separated by # and the SRID as the placeholder [epsg].Source: github.com/dsgoficial/DsgTools, commit a9413f6ST_CoverageInvalidEdges has existed since PostGIS 3.4.0; ST_CoverageClean, since 3.6.0, requires GEOS 3.14 and offers four strategies for overlaps, with the neighbor sharing the longest boundary as the default.Source: postgis.net/docsOcto 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 ARTStandards, datasets and documentation used in the research, accessed on October 31, 2026.
The assessment starts with a layer your team already maintains, without touching the official database. You get the inventory, a proposed mapping table and a trial validation run, and decide with that in hand.