1

I am trying to learn how to use Mapbox Studio, but I can't figure out how to upload GeoJSON files that I export from R's sf package using the st_write() function. For example, see the R code below:

library(tigris)
states <- states()
states <- st_transform(states, crs = "EPSG:3857")
st_write(states, "states.geojson")

When I load the exported states.geojson file into Mapbox Studio, I get the following error:

enter image description here

When loading other datasets I had created and exported as GeoJSON, I got a different error - "Error calculating min/max zoom: Bounds invalid".

I am new to Mapbox and GeoJSON so don't know much about this - but I would like to be able to export GeoJSON files from R using st_write() and load them into Mapbox! Any insights on why I am getting these errors and how to avoid them would be much appreciated. Thanks.

Casey
  • 93
  • 1
  • 6
  • If you could share the geoJSON file it would be easier to dig into. I'd recommend you try exporting with `crs = "EPSG:4326"` instead of `crs = "EPSG:3857"` To troubleshoot further, I'd recommend validating your geojson data using a tool like [geojsonlint.com](https://geojsonlint.com/). Also, try pasting your geojson data in [geojson.io](http://geojson.io/) and walk through it yourself. – camkruse May 06 '22 at 22:06

1 Answers1

3

I suggest that you avoid using EPSG:3857 when working with GeoJSON files, and stick to WGS84 (EPSG:4326).

The current GeoJSON standard allows only WGS84 - see https://datatracker.ietf.org/doc/html/rfc7946#section-4 (there is some wiggle room about lat-long vs. long-lat convention, but degrees are non negotiable; EPSG:3857 is in meters).

The former versions of the standard allowed other coordinate reference systems, which is why R / {sf} allows you to export the data, but it is extremely bad practice to do so. You are quite likely to run into issues such as the one you are facing now.

The official reason for the more strict specification was that GeoJSON using code is likely to end up in unconnected installations, and it may be impractical to keep it up with the evolving nature of EPSG database. The unofficial reason involved IT folks not being able to handle the truth spherical geometry.

Jindra Lacko
  • 7,814
  • 3
  • 22
  • 44
  • This is probably the best advice, despite the confusing [help page](https://docs.mapbox.com/help/glossary/projection/) at mapbox about projections. 4326 worked fine for me, 3857 did not. – mrhellmann May 07 '22 at 04:01
  • 1
    I found it the best to think of 4326 as a data storage system (only); being unprojected (in angular units) it has no way of presentation onto a flat object (a map or computer screen; only a globe would do). But it is, by virtue of GPS, extremely familiar to users. 3857 is a projected system, highly optimized for presentation (it projects most of the Earth onto a square; squares nest easily with implications for zooming). Its coordinates are in length units (meters) and extremely unfamiliar to users. As result web maps ended up projected in 3857, but labeled in 4326. Confusing indeed! – Jindra Lacko May 07 '22 at 04:32
  • Same with @mrhellmann, projecting to 4326 before exporting worked for me, while 3857 did not. Their note on Mapbox's confusing advice regarding this is what misled me. I was specifically looking at [the troubleshooting errors page](https://docs.mapbox.com/help/troubleshooting/uploads/#errors) which specifically recommends projecting into EPSG:3857 before uploading to Mapbox. – Casey May 10 '22 at 18:22