标签：#webmap

In the Mapbox Standard Style , the complexity of its layer styling is abstracted away — you can configure it with predefined variables, but you can't directly edit its layers. This is by design, and allows you to benefit from continuous improvements by our map designers. So what do you do when you need a label to say something different, appear at a different zoom level, or simply not appear at all? Here's a technique for surgically replacing a single label with your own, while keeping everything else in the Standard style untouched and precisely matching the label style. In the embedded example below, we've replaced the label for "New York" with "New Amsterdam". Why they changed it, I can't say. 😉 Using a classic style? If you're on a classic Mapbox style where you have direct access to edit symbol layers, there's a simpler approach: override the label text using an expression directly on the layer. See Customize label text in the Mapbox docs. This post is specifically about the Standard style, where internal layers are not editable — which requires a different technique. Step 1: Get the exact coordinates and properties of the label feature Most map labels come from the place_label source layer in the Mapbox Streets tileset . Here's a simple map that shows only the place_label source layer's points (and water features for reference). Click a label and you will see its full data, including the coordinates and properties: Copy the full GeoJSON Feature. Fields like symbolrank , filterrank , class , worldview , text_anchor , and capital all control how the label is styled and at which zoom levels it appears. You'll need to match these when building your replacement feature. Step 2: Build a custom style that imports Standard Instead of loading the Standard style directly, create a top-level style JSON that imports Standard and adds your own source alongside it: const map = new mapboxgl . Map ({ style : { version : 8 , sprite : ' mapbox://sprites/mapbox/standard/... ' ,

React + Mapbox GL JS: Custom Markers, Popups, and Bounds-Based Data Fetching If you've added a Mapbox map in a React app before, you've probably hit a wall pretty quickly: Mapbox GL JS manages its own DOM, and React manages a virtual DOM, and getting the two to play nicely takes some thought. Markers and popups are a great example of this tension — they're imperative APIs in a world where you want declarative components. This post walks through a pattern I've landed on for wrapping mapboxgl.Marker and mapboxgl.Popup in composable React components, and combining them with bounds-based data fetching to build something like a real estate or earthquake explorer map — where the data on the map updates as you pan and zoom. Here's what we'll cover: Wrapping mapboxgl.Marker in a React component that handles its own lifecycle Using createPortal to render custom marker content in React Fetching data from an API using the map's current bounding box Tracking an active marker with React state Wrapping mapboxgl.Popup in a component If you want to see the finished product first, the source code is on GitHub . The Core Challenge: Two DOMs Before we get into the code, it's worth understanding why this requires a pattern at all. When you use React's normal component tree, React controls the DOM. But mapboxgl.Marker also creates and manages DOM nodes — it places an element on the map at a specific geographic coordinate, handles repositioning as you pan, and removes itself cleanly when you're done with it. The approach here is to use React to manage the lifecycle of each marker (mount when data arrives, unmount when data goes away), while letting Mapbox handle the positioning . We use React's createPortal to render JSX content into a DOM node that we hand off to Mapbox. The example discussed below is a map that fetches earthquake data for the current viewport, displaying a custom Marker and Popup for each. As you move the map and the bounds change, new data is fetched and the Markers a