MySQL raises error 3055 when a geometry WKB value is encoded in big-endian order instead of the required little-endian format.
MySQL error 3055 ER_GIS_DATA_WRONG_ENDIANESS is triggered when spatial WKB data is stored in big-endian order; reload or convert the geometry to little-endian using ST_GeomFromWKB or ST_AsBinary to resolve the issue.
ER_GIS_DATA_WRONG_ENDIANESS
Error 3055 fires when MySQL receives or reads a geometry value whose Well-Known Binary (WKB) header indicates big-endian ordering. Starting with MySQL 5.7.5, the GIS subsystem strictly enforces little-endian encoding, so any mismatch causes immediate failure.
The message appears during INSERT, UPDATE, LOAD DATA, or spatial function calls that deserialize WKB. While the data type is spatial, the root cause is a binary format mismatch rather than a corrupt geometry.
Developers most often see it after migrating spatial data from PostGIS or Oracle, importing shapefiles with third-party tools, or calling client libraries that default to big-endian WKB. It can also surface during replication if the upstream system emits incompatible byte order.
Failing geometry inserts block ETL pipelines, replication lag grows, and applications that rely on spatial indexes lose data integrity. Correcting the endianess ensures your GIS features function and your tables stay consistent.
The primary trigger is a geometry byte string encoded in network (big-endian) order while MySQL expects host (little-endian) order.
Additional contributors include client libraries that ignore the WKB byte order flag, dump files generated by older GDAL versions, and manual hex literals crafted without the 0x01 little-endian marker.
First, verify that the input really is big-endian by inspecting the first byte of the WKB header. A 0x00 indicates big-endian, while 0x01 is correct.
Next, convert or reload the geometry using a function that rewrites the WKB in little-endian.
-- Detect offending rows
SELECT id FROM spatial_table WHERE ST_AsBinary(geom) LIKE 0x00% LIMIT 10;
-- Convert on the fly using ST_GeomFromText
UPDATE spatial_table
SET geom = ST_GeomFromText(ST_AsText(geom), ST_SRID(geom));
If loading from an external file, regenerate it with ogr2ogr using the option -lco ENDIANNESS=LOW.
Finally, commit and test.
Shapefile Import: Regenerate the .sql dump with little-endian and reload.
Cross-database Migration: Use ST_AsEWKB in PostGIS, then feed the output into MySQL's ST_GeomFromWKB.
Binary Literals in Code: Replace hard-coded hex strings with parameterized ST_GeomFromText calls.
Always serialize geometry with libraries that honor byte order flags. Validate incoming data with automated checks before INSERT.
Store spatial dumps in text (WKT) form when portability matters.
Galaxy's SQL editor can run lint checks that flag big-endian WKB before it reaches production, preventing the error entirely.
ER_GIS_DATA_MISSING_SRID: Raised when SRID is absent. Include ST_SRID on insert.
ER_GIS_INVALID_DATA: General corruption error. Validate geometry using ST_IsValid.
Data exported from systems that default to network byte order produces a 0x00 flag and triggers the error.
Older versions of ogr2ogr or mysqldump did not flip endianess correctly, leading to incompatible dumps.
Developers sometimes craft geometry literals by hand and forget the little-endian marker 0x01.
Some GIS clients ignore MySQL endian requirements and send big-endian buffers.
Occurs when SRID information is absent from a geometry value. Add or set SRID to resolve.
Raised for malformed geometries such as self-intersecting polygons. Validate with ST_IsValid then repair.
Indicates MySQL cannot open a GIS temporary file during import. Check file system permissions.
No. MySQL enforces little-endian for GIS data starting with 5.7.5. You must convert the data.
No. WKT is text based and has no endian concept, so it bypasses the issue.
Yes. When you update the geometry column, MySQL rebuilds the underlying R-Tree index.
Galaxy's AI copilot can inspect ST_AsBinary output, detect wrong-endian rows, and suggest the correct UPDATE statement.
.avif)
.avif){kind=logo}
