Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting background with multiple layers, and substitution of fill-extrusion #302

Open
mike-000 opened this issue Sep 29, 2020 · 2 comments

Comments

@mike-000
Copy link
Contributor

olms layers do not work well with layer switchers as the background is applied to the map div. Instead application code must preload the style json, find the background setting and set a postrender handler (in OL6 prerender only works if the layer is not fully opaque) on the layer to fill the background https://codesandbox.io/s/friendly-wind-jgv4e?file=/main.js . If this was done internally by olms the style urls could be used directly keeping the application code simple.

olms also ignores fill-extrusion in the style json. MapTiler's editor has a simple flatten 3d option (which must then be saved as a custom style) and the same can be done in application code (see above) so that all building appear the same as those at the view center in Mapbox GL. Compare MapTiler's Mapbox GL, OpenLayers vector tiles and raster tiles examples for OS Open Zoomstack Road. Using the 'off the shelf' style which works with Mapbox GL, buildings are missing when zoomed to street level in the OpenLayers vector tiles example, while they are present but flat in the raster tiles. Could olms have a flatten 3d option (or even default) to do this automatically without needing custom styles or application code?

@ahocevar
Copy link
Member

Thanks for your suggestions, @mike-000.

Since a Mapbox Style describes a whole map and not just a layer, there is some justification for setting the background color on the map div. However, I do see there are use cases for combining layers from a Mapbox Style with other layers. To support such use cases, I'd suggest creating a separate layer with a custom renderer that just adds a viewport sized div for the background, which could then be controlled by layer switchers just like any other layer. If you agree with that and see yourself in a position to implement it, a pull request would be welcome.

Regarding fill-extrusion, I think it makes sense to flatten 3d by default, because we do not support 3d anyway. Also for that, a pull request would be welcome.

@mike-000
Copy link
Contributor Author

mike-000 commented Oct 1, 2020

I hadn't considered Mapbox Styles with multiple layers (e.g. the MapTiler satellite hybrid) but that could be done by moving the new OpenLayers layers to a layer group after an olms call resolves. An application function could do that for any other Mapbox Styles to be added as switchable layers, and also set up a background fill on the group's first layer based on what olms has set on the map div, for example

olms(map, url0).then(function () {
  applyGroup();
  olms(map, url1).then(function () {
    applyGroup();
    olms(map, url2).then(function () {
      applyGroup();
      onChange();  // apply layer switcher setting
    });
  });
});

function applyGroup() {
  const group = new LayerGroup({ visible: false });
  map.addLayer(group);
  map.getLayers().getArray().slice().forEach(function (layer) {
    if (!(layer instanceof LayerGroup)) {
      map.removeLayer(layer);
      group.getLayers().push(layer);
    }
  });
  const backgroundColor = map.getTargetElement().style.backgroundColor;
  if (backgroundColor) {
    map.getTargetElement().style.backgroundColor = '';
    group.getLayers().getArray()[0].on('postrender', function (event) {
      const ctx = event.context;
      ctx.globalCompositeOperation = 'destination-over';
      ctx.fillStyle = backgroundColor;
      ctx.fillRect(0, 0, ctx.canvas.width, ctx.canvas.height);
      ctx.globalCompositeOperation = 'source-over';
    });
  }
}

That would be more suitable as an OpenLayers example than an ol-mapbox-style change (although Esri OSM would need #304 included in olms).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants