SIRGAS 2000 vs WGS 84 vs Córrego Alegre / SAD 69: when the difference matters

Short answer: SIRGAS 2000 and WGS 84 are the same place to within a metre, and the transformation between them is a null one — PROJ selects EPSG:15894, "SIRGAS 2000 to WGS 84 (1)", a +proj=noop published with a stated accuracy of 1.0 m. So the pair everyone asks about is not the one that bites. The legacy pair is: at Brasília a SAD 69 coordinate sits 68.530 m from the same ground point in SIRGAS 2000 (EPSG:15485), at Belo Horizonte a Córrego Alegre coordinate sits 41.711 m away (EPSG:6193), and a file labelled one while holding the other puts your boundary in the neighbour's plot.

Measured on 23 September 2026 with GDAL 3.13.3 and PROJ 9.8.1, against the coordinate converter at static-page-tools@79fc1f6. The PROJ data version counts too: EPSG database v12.029, PROJ_DATA.VERSION 1.24, with the shift grids br_ibge_CA7072_003.tif and br_ibge_SAD69_003.tif absent and network fetching off, so every operation below is a Helmert rather than a grid. That makes each one the operation PROJ selected here, not a universal fact: with the proj-data grids installed, EPSG:4618 to EPSG:4674 selects DERIVED_FROM(EPSG):5528 instead, EPSG:4618 to EPSG:4326 selects DERIVED_FROM(EPSG):5542, EPSG:4225 to EPSG:4674 selects DERIVED_FROM(EPSG):5526, and the metres would differ.

The four pairs, and which one actually moves you

At Praça da Sé in São Paulo (-23.550385, -46.633956), projinfo -s EPSG:4674 -t EPSG:4326 --summary returns one candidate, EPSG:15894, rated 1.0 m, and projinfo -k operation EPSG:15894 -o PROJ prints +proj=noop. Nothing is applied: gdaltransform hands the coordinate back byte-identical and, with CPL_DEBUG=ON, logs no operation line. EPSG ships the identity with a 1.0 m uncertainty instead of a shift, because the two frames are defined to be the same frame to about that. There is no reprojection between them to get wrong.

At Praça dos Três Poderes in Brasília (-15.799800, -47.861000), EPSG:4618 to EPSG:4674 selects EPSG:15485, "SAD69 to SIRGAS 2000 (1)", 5.0 m, a three-parameter Helmert of +x=-67.35 +y=3.88 +z=-38.22, and the point moves 68.530 m. To EPSG:4326 it selects EPSG:5882, "SAD69 to WGS 84 (16)", also 5.0 m and the same Helmert, and moves the same 68.530 m.

At Praça da Liberdade in Belo Horizonte (-19.932000, -43.937000), EPSG:4225 to EPSG:4674 selects EPSG:6193, "Corrego Alegre 1970-72 to SIRGAS 2000 (2)", 5.0 m, Helmert +x=-206.05 +y=168.28 +z=-3.82, and the point moves 41.711 m; to EPSG:4326 it selects EPSG:6194 and moves the same 41.711 m. One digit apart, and easily swapped.

The bare projinfo command tells a different story

Check SAD 69 the obvious way and PROJ tells you none of that. projinfo -s EPSG:4618 -t EPSG:4326 --summary returns a single candidate — unknown id, Ballpark geographic offset from SAD69 to WGS 84, unknown accuracy, extent World — under the note Note: using '--spatial-test intersects' would bring more results (20). Run it that way and 20 candidates come back in total, nineteen more than the default's one; EPSG:4618 to EPSG:4674 prints (3) and returns 3 in total, two more. A ballpark is not an operation and is not a figure to quote. The default --spatial-test contains asks whether an operation's extent contains the whole source CRS extent, and SAD 69 reaches across South America, so no Brazil-only operation qualifies.

Meanwhile ogr2ogr on the same machine quietly applies EPSG:5882 and EPSG:15485 to your actual points, because a point transform tests the point. Ask at the scale of what you are transforming: --spatial-test intersects, or a --bbox tight around it. The trap runs both ways — a Brazil-wide --bbox turns EPSG:4225 to EPSG:4674 into a ballpark, because Córrego Alegre's own area of use is smaller than Brazil.

Córrego Alegre: the converter is running PROJ's own parameters

The browser converter does not call PROJ. It uses proj4 with hard-coded +towgs84 strings, and its EPSG:4225 definition is +towgs84=-206.05,168.28,-3.82,0,0,0,0 on +ellps=intl. PROJ's EPSG:6193 and EPSG:6194 both carry the Helmert step +x=-206.05 +y=168.28 +z=-3.82 on that same ellipsoid — the same three numbers, byte for byte. So there is nothing to compare on this datum: the two use identical parameters and therefore cannot disagree, and any agreement figure between them would be the same arithmetic run twice rather than a check of one against the other. On Córrego Alegre the converter is EPSG:6194, by construction.

SAD 69: two EPSG operations of equal accuracy, and the metres between them

SAD 69 is the real comparison. The converter's EPSG:4618 definition carries +towgs84=-66.87,4.37,-38.52,0,0,0,0 while EPSG:5882 carries +x=-67.35 +y=3.88 +z=-38.22 — two different Helmerts on the same ellipsoid, so the answers can genuinely diverge. The comment beside those parameters in the converter source calls them "under a metre" apart, and nobody had put a number on it.

Here is the number, and it needs both operation codes beside it or it says the wrong thing. The converter's triple -66.87,4.37,-38.52 is not an approximation of EPSG:5882: it is EPSG:1877, "SAD69 to WGS 84 (14)", byte for byte — published by EPSG with the same 5.0 m accuracy and the same area of use as EPSG:5882, and second on every Brazil-restricted projinfo run. Put the Brasília point through both and the answers land 0.747 m apart, 0.730 m to 0.747 m across five Brazilian cities: the gap between two published operations of equal stated accuracy, each roughly seven times inside its own declared 5.0 m uncertainty. Not converter error, and nothing beside the 68.530 m that EPSG:15485 and EPSG:5882 move the point in the first place.

When the difference matters

Set the threshold by what you are arguing about. A cadastral boundary or a plot survey is argued in centimetres, and through EPSG:5882 the SAD 69 shift measured 63.015 m at Salvador, 68.530 m at Brasília, 69.291 m at Manaus, 71.403 m at São Paulo and 74.588 m at Porto Alegre — any one of those puts a corner in somebody else's lot. It is systematic rather than noisy: every vertex moves the same way, so the plot keeps its shape and looks plausible. On a 1:250,000 basemap the same shift is a fraction of a millimetre and invisible, which is how legacy files survive for decades — but the label still has to be right, because the day someone reuses that file for a boundary is the day it stops being invisible.

How to tell which datum a file is in

Three spellings of the same answer, and which one you see depends on how you look. ogrinfo -so yourfile.shp yourlayer on GDAL 3.13.3 prints WKT2, so the keyword is GEOGCRS[ and the names read GEOGCRS["SIRGAS 2000",, GEOGCRS["WGS 84",, GEOGCRS["SAD69", and GEOGCRS["Corrego Alegre 1970-72",. Add -wkt_format WKT1 and the same four come back under the older GEOGCS[ keyword, the spelling most documentation still shows. Open the .prj in a text editor and you get a third, ESRI WKT1 with its own names: GCS_SIRGAS_2000, GCS_WGS_1984, GCS_South_American_1969 and GCS_Corrego_Alegre.

The ellipsoid settles it when the name is mangled: Córrego Alegre 1970-72 sits on International_1924 and SAD 69 on GRS_1967_Truncated, while SIRGAS 2000 and WGS 84 sit on GRS_1980 and WGS_1984, which share a semi-major axis. A spreadsheet gives you nothing to read at all — a CSV carries no coordinate system, so the datum has to come from whoever exported it (CSV latitude and longitude on a map).

Assign or reproject: two flags, two verbs

ogr2ogr -a_srs EPSG:4674 relabel.shp fix4225.shp on a Córrego Alegre file writes a new .prj and moves nothing: ogrinfo -so now says GEOGCRS["SIRGAS 2000", while ogrinfo -al -geom=YES still prints POINT (-43.937 -19.932). ogr2ogr -s_srs EPSG:4225 -t_srs EPSG:4674 moved.shp fix4225.shp does the other job: the label changes the same way and the geometry becomes POINT (-43.937208157368 -19.9323212697943), byte-identical to what EPSG:6193 produces, because that is the operation ogr2ogr picked. The relabelled file is the trap — it opens, it draws, it looks fine, and its point is now the full 41.711 m from where it belongs, with a fresh .prj vouching for it.

-a_srs is right in exactly one case: the numbers were already correct and the label was missing or wrong. -s_srs with -t_srs is right whenever the numbers have to move. The missing .prj post covers the first case in detail.

In the browser

The coordinate converter offers all four in its Source projection (CRS) picker, and the option labels are hard-coded English in every locale, so they read identically on the Portuguese and Spanish pages — including the Brasil group heading, spelled in Portuguese in the English UI. Under Brasil: SIRGAS 2000 (EPSG:4674), SAD 69 — legacy (EPSG:4618) and Córrego Alegre 1970-72 — legacy (EPSG:4225), plus SAD 69 / Brazil Polyconic — legacy (EPSG:29101), SAD 69 / UTM 22S — legacy (EPSG:29192) and SAD 69 / UTM 23S — legacy (EPSG:29193). WGS 84 (EPSG:4326) is under Global.

Set the target before reading anything: it starts on SIRGAS 2000 / UTM 23S (EPSG:31983), so degrees typed into the Decimal degrees row with Target projection (CRS) left alone come back as metres. Choose the same CRS on both sides and there is no result half — the page prints Choose a different target projection to see the conversion. For the codes themselves, the EPSG cheat sheet's "The legacy set you inherit" section lists the Brazilian legacy entries and what replaced each one, and its "The Latin American set" section does the same for Colombia, Argentina, Chile and Mexico (EPSG codes for Brazil and Latin America).

Test files you can use

Nothing to download: the fixture is a coordinate pair. Convert the three pairs above on their own datums — Praça da Sé in SIRGAS 2000, Praça dos Três Poderes in SAD 69, Praça da Liberdade in Córrego Alegre 1970-72 — and watch each one move. Each sits inside its datum's declared area of use, which is what the runs above depend on: ask PROJ at a wider scale — no area at all, or a Brazil-wide --bbox — and it answers with a ballpark instead of a named operation.

To build the broken variant, take a shapefile you know is in Córrego Alegre and run ogr2ogr -a_srs EPSG:4674 relabel.shp fix4225.shp. The file now claims SIRGAS 2000, every coordinate is exactly where it was, and nothing inside it will tell you.

For teams

A datum is a fact about a file that usually lives outside the file — a folder name, an email thread, one person's memory of who supplied it. Geodocs keeps the coordinate system with the data on a shared map, so a legacy survey is reprojected once on the way in and everyone drawing on top works in the same frame.