1
votes

I have successfully uploaded a geojson tileset to Mapbox Studio and rendered the polygons in the geojson in my web app by using map.addLayer and referencing the URL endpoint of the tileset in Mapbox Studio.

What I want to do now is either through the Mapbox API or locally in my typescript file get the bounds of the layer that's been added.

I know the solution needs to involve turf and bbox but I am having trouble actually getting the bound values that I need to pass into map.fitBounds(bbox) in order to adjust the map.

Thanks in advance for the help!

1

1 Answers

0
votes

Do you expect the contents of your GeoJSON layer to change dynamically on the client side, or will the polygons added via the initial GeoJSON tileset upload be constant? If the polygons will not be changing, I'd recommend computing an encompassing bounding box for the polygons in your tileset to then pass to your web application. The tool geoson.io lets you upload your GeoJSON to visualize on a map in the browser. After uploading your data, you can select the "marker" tool from the toolbar in the upper right and manually place markers on the map to indicate the Southwest and Northeast coordinates of the bounding box for all the polygons. The corresponding GeoJSON from these placed markers will show in the panel on the righthand side of the interface, from which you can retrieve the latitude-longitude coordinates of the placed markers to pass to Map#fitBounds as demonstrated in this example.

The reason why you should ideally compute the bounding box in advance rather than on the client side is that Mapbox GL JS is ultimately a graphics engine whose knowledge is restricted to the geographic contents currently rendered on the screen. Mapbox does have any insight into components of your tileset or map layers outside of the current viewport, since it is not rendering this data! You could use Map#queryRenderedFeatures or Map#querySourceFeatures to parse the underlying GeoJSON being rendered, but the results are restricted to rendered data and the process is probably far more computationally expensive than necessary.