Is there a Leaflet plugin or example for letting the user control the display order of overlay layers in a map?
Turning layers on and off is working fine, but I'd like the user to be able to drag layer names within the layer control to set the Z order.
For Path class (Polygons, Polylines, etc.) there are methods 'bringToFront()' and 'bringToBack()'. You can't exactly set precise position in draw order, but iterating over layer list and calling 'bringToFront()' could be less time consuming, then re-drawing every layer (especialy if they are bigger).
Related
Given a bound box like the below picture, how do you get all the features contained within, regardless of if they are visible or not.
I have tried to get all roads using
let features = map.querySourceFeatures('composite', {sourceLayer: 'road'})
But it only gives me roads that are visible if I am zoomed in.
I have also tried
let features = map.queryRenderedFeatures([tile_info.swPt, tile_info.nePt])
But again, it only gets features visible on the map based on zoom level.
I need all the features within the bounding box regardless of what you can see or zoom level
It is in the nature of vector tiles that you can not do what you want to do here. You can only query data which has been loaded into the browser, and the point of the vector tile architecture is to prevent that happening at lower zooms.
You could consider a server based approach like Tilequery.
I am generating a layer UK scale, it is composed for several polygons, the idea for the layer is to display it fully and then the user can zoom to most specific area. The main problem is because the number of polygons when I create the .mbtile it split some of the polygon at determined zooms.
I have tried with different options of tippecanoe like --not duplication extend zooms if still dropping ... but I couldn't nail whit the correct commands to make it work.
tippecanoe -zg --read-parallel -l $LAYER -o "$OUT_MBTILES" "$OUT_JSON" --coalesce-densest-as-needed --extend-zooms-if-still-dropping --no-duplication
I suspect this is somehow related to --no-duplication. Per the documentation:
--no-duplication: As with --no-clipping, each feature is included intact instead of cut to tile boundaries. In addition, it is included only in a single tile per zoom level rather than potentially in multiple copies. Clients of the tileset must check adjacent tiles (possibly some distance away) to ensure they have all features.
I'm not sure why you're using that option, but disable it if possible.
It's hard to be more specific without seeing your data and having a lot more information about what you're trying to achieve, zoom levels, attributes, data size etc.
I'm trying to create an experience where I have a couple of detailed 3D models of buildings on the map with extruded building footprints of neighboring buildings via a vector tile source. The 3D models would be the main focus point and the extruded footprints would be for reference. One challenge I'm running into is that I have a global building footprint layer and it has a footprint for the 3D buildings which doesn't match up perfectly. Additionally, when extruded, it ends up merging/overlapping the nice 3D models.
I'd like to be able to hide the individual footprints that overlap the 3D models. My original thought was to grab the bounding box of the 3D model and then use the new within style expression, but it looks like this will only filter points and lines, not polygons. The building footprint polygons have no unique information in them that I could use to filter on.
I know I could monitor map movements and query the rendered features and manually detect intersecting polygons, but since there is no unique property on the footprint, I can't filter or use feature state.
Any ideas of how to efficiently avoid rendering individual polygons in a specific area that come in from a vector tile source?
It is a common issue that the buildings layer in Mapbox Streets don't contain any unique attributes to allow filtering or rendering differently.
The best solution is usually to source a different buildings layer, and in this case, remove those redundant buildings in pre-processing.
I can think of one rather crazy workaround that might work here, although the performance may be poor.
Add the building layer with very low opacity, of type fill, essentially invisible. (Maybe invisible would work.) Call your main source buildings`.
Create a secondary building source of type geojson, and a secondary fill-extrusion layer. Call this source buildings-copy.
On map move or moveend, use querySourceFeatures to obtain a copy of all buildings.
Process this copy using Turf to remove the buildings you don't want, and call setData to set the copy as the data for buildings-copy.
You may need to do some clever caching to get reasonable performance.
When I use the following code to go through all the layers in a leaflet map,
map.eachLayer(function (layer) {
console.log(layer);
});
I just wants what rule is used to create this order. Is it because of the ZIndex of the layer? Or is it because the layer is added in different time? If the layer is added early, it will be in the bottom.
Thanks,
Good question, it seems the LeafletJS docs don't say anything about the ordering of the layers via eachLayer, so...
Looking at the code on github, L.Map.eachLayer loops through L.Map._layers which is an object (not an array). So technically the layers could come back in any order...
That said, the individual layers are added to the _layers object in the order they are added to the map. So in all likelihood, eachLayer will be iterating over the layers in that same order (whatever order they were added to the map).
OK, here's the deal:
I have two views: simple and advanced. On the iPad, they come with a big-ass map view, with a marker that can be moved to indicate a position.
Each view has a different instance of MkMapView. When I switch from one to the other, I want to keep the map at exactly the same position and zoom level, so the user feels as if it is the same map.
However, the shape of the map view is slightly different for each of the views. This is because the advanced search has more stuff above the map.
When I open the map (this is code from an abstract superclass, so both instances get it), I set the region and marker position, like so:
[mapSearchView setRegion:[mapSearchView regionThatFits:[[BMLTAppDelegate getBMLTAppDelegate] searchMapRegion]]];
[myMarker setCoordinate:[[BMLTAppDelegate getBMLTAppDelegate] searchMapMarkerLoc]];
searchMapRegion and searchMapMarkerLoc are static, and reflect the currently displayed map's region and marker location (the center of the map).
Here's the problem:
Because the map is a slightly different shape, there is always a bit of adjusting. This can "bounce" back and forth, so that the map zoom keeps decreasing every time you switch, until you are looking at the whole world.
It doesn't matter whether or not I use regionThatFits. The same thing happens, even with this code:
[mapSearchView setRegion:[[BMLTAppDelegate getBMLTAppDelegate] searchMapRegion]];
[myMarker setCoordinate:[[BMLTAppDelegate getBMLTAppDelegate] searchMapMarkerLoc]];
All I want, is for the exact same zoom and center to be displayed. I don't care is the advanced view cuts a bit off.
How do I get the $##!! MapKit to stop tweaking the zoom factor?
Just FYI. I solved this by creating a custom model layer class that maintains the scale and center point, and is used by multiple MKMapViews. It works pretty well, but the MapKit does sometimes tweak the scale very slightly to fit one of its "detents."