Labels across the visble map's edges are only shown partially. This is of course expected behaviour and not a problem when panning is possible.
But for non-interactive maps, like in this Mapbox example, panning is disabled. There's no way for users to ever see those labels completely. That leaves most of them as useless clutter.
For this case, when panning is disabled, I'd prefer to either render those labels completely inside the visible map or not at all. Any ideas?
The symbol-avoid-edges property provides the behaviour for which you're asking. Applying this property to all symbol layers in your base layer will require some light scripting or elbow grease.
There is no existing way to prevent labels from intersecting with the viewport edges.
Related
I want to label stations on my map, and I would like to clusterize the stops at different zoom levels to filter them down. So as you zoom out all you get is the start and end, and then finally a single label start->end.
How do I render a text label on a vector tile ?
I could fetch the stations as a geojson and reload on zoom change if there's no easy way to do this with tiles.
Is there a reason you need to encode your data differently per-zoom-level in the tiles or are you mainly concerned with displaying data differently per-zoom-level? If the latter, I would recommend looking for an approach that focuses more on styling the vector tiles you already have rather than trying to generate those tiles in a more complex fashion. You could try using a zoom function to style your data. If you're using Mapbox Studio, you can also set zoom-specific style rules in the Studio UI, which is the route you'll probably want to go if you're using Leaflet (I see the Leaflet tag in your post but it's not entirely clear what your implementation looks like).
If the former, you may need to use a tool like Tippecanoe. This route will likely be a bit more complex, but gives you fine-grained control over how your vector tiles are generated. Keep in mind that once you've created your tiles using Tippecanoe, you'll still need to style them somehow.
AFAIK, when plotting markers on mapbox map (Mapbox GL JS), you have two options:
(a) to plot them as point and layer styles (in which case they are rendered into the final <canvas> element, they are not inspectable, they cannot receive :hover states
(b) to add them as markers, which then remain individually inspectable HTML elements. The downside of this method though is that they don't zoom/scale as smoothly and quickly as the map so that a little of inertia is noticable.
Both methods support interaction (if you supply interactive: true in the (a) option) although you handle it in different ways.
Are there any other limitations of any of those methods that I should consider when building interactive map?
That's a pretty broad question. But generally I see the upsides of each method as:
Layers: part of the map, so you get collision detection, data-driven styling, zoom-driven styling, etc.
Markers: part of the DOM, so you get CSS, Javascript events, easy integration of images and fonts, and simpler mouse event handling, like :hover.
It's not quite true to say that layers don't support :hover. You can detect mouseOver then do map.setFeatureState() to set a hover property on the feature. It's just that you don't get it for free.
When should one use a marker instead of a feature layer of points in Mapbox?
Points layers can be updated and styled dynamically using all the styling tools of Mapbox GL JS. Features in points layers can also be clicked, presenting a popup just like with a marker.
Given this, when would one want to use a marker?
As Andrew mentioned there are two sides two this:
Accessibility
Markers are implemented as DOM elements and thus can be included in the tab order and can be given accessibility attributes
Animation
As markers are DOM elements animating them is quite easy with a bit of CSS & JS. You can animate points on a circle layer too, but its much more of a hassle.
Small point count
The number of markers/points you can display at once is somewhat limited by what the DOM can manage. My suggestion is that, if you have more than 500 points to display, you should opt for a circle layer instead of markers (this is a very rough estimates and depends on other parameters as well, animation, point size etc.). Using a circle layer you will hit - depending on the hardware - a limit in the 10s of thounds of points.
I'm starting research to add a user feature to an existing map built in Mapbox GL JS (wrapped in an Angular 2+ application). What I need to do, is allow a user to be able to draw and rotate ellipses and text labels over the top of a map, and be able to save screen captures of the result.
I'm coming into this with no experience in Mapbox or Leaflet, so I have a lot to figure out. My first goal is to determine if I can do this in Mapbox directly (with a plugin?), of if I will need to render a canvas over the top of my map with some third-part drawing library (I have a lot of experience with those).
The obvious advantage to doing this in Mapbox directly would be that we might still be able zoom and pan.
The Mapbox-gl-draw library lets the user author features in a map, but probably not to the extent you need.
If the features the user creates don't need to live "in map space" (ie, the map is static, and the labels are statically positioned over the top, for printing), working directly on a canvas will give you much more flexibility. You'll also have access to a much wider variety of libraries.
Am working on a project where we have a Bing map being resized depending on whether or not a panel is shown/hidden on the left-hand side of the map. Because of this, and Microsoft's terms preventing overlaying anything over the logo/copyright, etc, I'm using the VEMap.resize method to resize the map, and then am moving the panel out of the way. The issue is that there's an awkward autopan that occurs as part of the resize - because we're declaring a center point to determine the resize, the map pans to include this point in the center without any control over it. Without declaring a center, the map doesn't pan, but it also doesn't pull the new data (map tiles) in our resize in either, resulting in an awkward grey bar on the right-hand side..
Is there a simple way to either resize the map and disable that autopan, moving the center prior to the panning, or to force the map tiles to be rendered upon the resize itself? Any help would be appreciated.
You may want to try the new version 7.0 as you could get rid of this annoyance by using "map.setView({center: map.getCenter(), animate:false})" after resizing; that should override the nice but annoying pan movement on resize.
However there are a few features (like infoboxes or client-side clustering) currently missing in 7.0 when migrating from 6.3 however and the classnames changed, so you may want to wait for now, however it would be the good moment to prepare yourself for 7.