MySQL raises ER_INVALID_GEOJSON_UNSPECIFIED (SQLSTATE HY000, error 3072) when a spatial function receives malformed, incomplete, or non-GeoJSON input.
ER_INVALID_GEOJSON_UNSPECIFIED appears when MySQL spatial functions like ST_GeomFromGeoJSON() receive invalid or unspecified GeoJSON text. Validate the JSON structure, include a required "type" field, and pass well-formed coordinates to resolve the error.
ER_INVALID_GEOJSON_UNSPECIFIED
MySQL throws ER_INVALID_GEOJSON_UNSPECIFIED (SQLSTATE HY000) when you call a spatial function such as ST_GeomFromGeoJSON() or ST_PointFromGeoJSON() with text that is not valid GeoJSON. The server stops parsing and returns error code 3072 instead of building the geometry.
The problem usually appears in MySQL 5.7.5 or later, when GeoJSON support was added, and continues through current versions if malformed input is supplied.
MySQL validates every GeoJSON document against RFC 7946 rules. Missing mandatory keys like "type" or "coordinates", using strings instead of numeric coordinate arrays, or passing plain JSON that is not GeoJSON will trigger the error immediately.
The error can also occur when variable placeholders are empty, dynamic SQL concatenates partial JSON, or your application truncates longitude and latitude values, producing invalid coordinate pairs.
First, confirm the text sent to MySQL is valid GeoJSON using an online validator or a JSON_SCHEMA check. Ensure the top-level "type" is set (e.g., "Point", "Polygon") and that "coordinates" contain numeric arrays.
Then call ST_GeomFromGeoJSON() with the validated string or store the GeoJSON in a column of type JSON and reference it. If dynamic variables are involved, safeguard them with JSON_QUOTE() to preserve structure.
When importing external GeoJSON files, read them in full and strip whitespace only after validation. If your API receives GeoJSON, set NOT NULL constraints and a CHECK(JSON_VALID(col)) clause to catch malformed input before calling spatial functions.
During migrations, cast legacy WKT data to GeoJSON with ST_AsGeoJSON() first, then feed it back into ST_GeomFromGeoJSON() to guarantee compliance.
Always validate GeoJSON at the application layer and again in MySQL with JSON_VALID() or a generated column. Store GeoJSON in a JSON column, not TEXT, to leverage MySQL's native validation.
Use parameterized queries in tools like Galaxy to prevent string-building errors and share vetted spatial queries across your team, reducing malformed input.
Error 1416 (HY000) Cannot get geometry object causes similar issues for WKT; verify WKT format. Error 3144 ER_INVALID_JSON_TEXT signals generic JSON validation failures; ensure JSON_VALID() returns 1.
Error 3612 ER_WRONG_ARGUMENTS_ES affects ST_LATITUDE and ST_LONGITUDE; supply correct geometry types. Each of these errors can be fixed by validating input data before calling spatial functions.
GeoJSON objects must declare a "type" such as "Point" or "Polygon". Omitting it triggers error 3072.
Using strings, nulls, or uneven numeric pairs inside "coordinates" is invalid GeoJSON.
Dynamic queries that concatenate variables may pass an empty string to ST_GeomFromGeoJSON().
Supplying generic JSON or WKT instead of GeoJSON will fail validation inside MySQL.
Raised when generic JSON fails validation. Ensure the JSON string is syntactically correct.
Occurs with invalid WKT input. Validate Well-Known Text before calling spatial functions.
Triggered by supplying non-geometry arguments to spatial helpers such as ST_LATITUDE().
No. MySQL fully supports GeoJSON starting in 5.7.5. The error only signals that the specific input string is invalid.
Use JSON_VALID() to check general JSON syntax and ST_GeomFromGeoJSON() in a SELECT to confirm spatial validity.
No. Validation is built into the spatial function. You must supply correct GeoJSON.
Galaxy helps by letting you save and share validated spatial queries, reducing the chance of malformed GeoJSON reaching production databases.
.avif)
.avif){kind=logo}
