GeoJSON Bounds Look Wrong? Check Coordinate Order and Projection

When a GeoJSON layer appears in the ocean, spans half the world, or disappears completely, the map style is rarely the first thing to blame. Start with the data. Bounds, coordinate order, projection, and outliers explain many broken previews.

A local GeoJSON Globe Viewer is useful because it can show feature count, geometry types, coordinate count, and approximate bounds before you wire the data into a production map.

Start with Bounds

Bounds summarize the minimum and maximum longitude and latitude in a dataset. They are a fast sanity check.

For example, if a city delivery dataset produces bounds that cover North America, Europe, and the ocean, something is probably wrong. A single bad coordinate can stretch the bounds so far that the real features become hard to see.

Check:

• minimum longitude
• maximum longitude
• minimum latitude
• maximum latitude
• whether any coordinate is near 0,0
• whether values exceed valid longitude or latitude ranges

Valid geographic longitude is usually from -180 to 180. Valid latitude is from -90 to 90.

Check Coordinate Order

GeoJSON positions use longitude first, then latitude. The official GeoJSON standard, RFC 7946, defines the format around geographic coordinates in decimal degrees. Mapbox's GeoJSON glossary also states that the first coordinate element is longitude and the second is latitude.

That means New York City is written like this:

[-73.935242, 40.73061]

not like this:

[40.73061, -73.935242]

If you swap the order, a point can jump to another continent or fail validation if the latitude slot receives a number outside -90..90.

Check Projection Assumptions

GeoJSON is commonly expected to use WGS84 longitude and latitude coordinates. If your source data came from a projected coordinate system, CAD export, local grid, or Web Mercator meters, the numbers may not be valid longitude and latitude.

Projection problems often show up as:

• coordinates much larger than 180 or 90
• features far from the expected country
• a layer that disappears after fitting bounds
• all points stacked near an unexpected location
• routes that cross the world

If the coordinate values look like meters instead of decimal degrees, convert them before treating the file as normal GeoJSON.

Look for One Bad Feature

Do not assume the entire file is wrong. One bad point can stretch bounds and make the whole layer look broken.

Debug by reducing the dataset:

1. Preview a small sample.
2. Split the file into groups.
3. Check bounds for each group.
4. Find the feature that expands the bounds unexpectedly.
5. Inspect that feature's coordinates and properties.

This is faster than editing the map style or changing the base map.

Example: A City Layer Covers the Whole World

Imagine a store layer for one city. Most coordinates are around [-73, 40], but the computed bounds include longitude 0 and latitude 0. That usually means one feature has a missing value that became 0,0, or a placeholder point was exported with the real data. The map may zoom out to include the Gulf of Guinea, making the actual city points look tiny.

Another common case is swapped order. Coordinates around [40, -73] will not land in New York because GeoJSON reads that as longitude 40, latitude -73. The layer is syntactically valid but geographically wrong.

Do Not Fix Data Problems with Style

It is tempting to fix a broken preview by changing zoom, center, opacity, or layer color. That only hides the issue. If bounds are wrong, the data will still break search, fitting, clustering, screenshots, exports, and downstream analysis.

Fix the coordinate problem first. Style should be the last step, not the debugging tool.

FeatureCollection Structure Still Matters

A valid JSON file is not automatically valid GeoJSON. Check that the top-level object is a FeatureCollection, Feature, or geometry object. If it is a FeatureCollection, make sure features is an array. If a feature has properties but no geometry, a viewer may count it but draw nothing.

For polygons, also check ring nesting and closure. A broken polygon can make a bounds problem look like a rendering problem.

Safe Workflow Before Publishing

Use this workflow before feeding GeoJSON into a website, dashboard, or customer-facing map:

1. Preview locally before uploading private data.
2. Check feature count and geometry types.
3. Check bounds.
4. Confirm longitude-latitude order.
5. Confirm coordinates are WGS84 decimal degrees.
6. Search for outliers.
7. Only then debug styling or layer configuration.

Quick Answer

If GeoJSON bounds look wrong, first check longitude-latitude coordinate order, valid coordinate ranges, projection assumptions, and outlier features. A local preview can show whether the problem is in the data before you spend time debugging the map renderer.

References

• RFC 7946: The GeoJSON Format
• Mapbox GeoJSON glossary