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

Add method for switching between two custom tile layers #2095

Open
oiva opened this issue Jan 9, 2014 · 12 comments
Open

Add method for switching between two custom tile layers #2095

oiva opened this issue Jan 9, 2014 · 12 comments
Labels
new-feature A new feature for iD

Comments

@oiva
Copy link

oiva commented Jan 9, 2014

Use case: using two different custom tile layers for mapping. For example, one map layer and one aerial imagery layer.

Now switching between two custom layers requires you to first change the background to some other layer and then back to custom layer, entering the URL for the second custom tile layer.

One option that might solve this (and #2094) would be to add new custom layers to the layer stack, retaining the "Custom" option, which could then be used to add another custom layer.

Another way to solve this could be having two separate custom layer options and make both of them remember their last value.

@bagage
Copy link
Contributor

bagage commented Feb 22, 2017

More generally, it would be convenient if we could add as many custom layers as we wish: in France there are at least 3 rendering that might be useful at the same time (IGN aerial photos, cf #3420, Strava heatmap and BANO).
It would mean a bit of UI reworking, but maybe something like that?

capture d ecran de 2017-02-22 19-07-22

@Abbe98
Copy link
Contributor

Abbe98 commented Mar 12, 2017

Reposting my comment from #3888,

Save all of the past ones in localstorage and display a dropdown in the dialog?

A new dialog window would be needed, is there any existing element that could be reused?

@verdy-p
Copy link

verdy-p commented Sep 25, 2017

How would you customize the transaprency if multiple layers are used ? They are not necessarily transparent.
Opaque non-transparent layers (such as Mapnik) would be exclusive of each other (radio buttons) unless there's an additional slider to set their respective transparency.
Some layers may need to be tuned also to implement a filter (such as converting white to transparent with some conversion curve from lightness to alpha, and inverting lightness), in advanced options.

As well the possibibilty of dragging up or down layers in list (or the use of "up/down" arrow buttons) could easily switch the order of opaque RGB layers (with no alpha channel).

You can see these in effect for example on the (non-free) French GeoData portal (from IGN) or the Swiss Geoportal, or in Mapbox.

Still we should keep the interface simple by enabling these only with minimum interface when we have a single layer: radio buttons are useful to switch between single opaque background layers, and a last "custom" radio button would have the possibility of compositing one or more layers with various viewing options for each of them and their respective order. In that case a single "Custom" radio button will be needed, or jsut a single "+" button to add a new selectable view where we can compose the layers as wanted and switch between multiple composite views or with preenabled opaque views.

@verdy-p
Copy link

verdy-p commented Sep 25, 2017

Note that some precomposed views (featuring several layers) may be proposed by default without needing to click on "+" to create one. A precomposed view can also be set by passing a single parameter pointing to some JSON object (or URL) containing all the parameters for the view, and immediately available with a radio button.

iD should be able to detect the suitable precomposed view according to their coverage bounding box or polygon, and that would be show in the list of available views (radio buttons)

@bhousel
Copy link
Member

bhousel commented Sep 25, 2017

How would you customize the transaprency if multiple layers are used ? They are not necessarily transparent.

I was thinking of transparent overlay layers on #3773.. but yeah iD should be able to let people add custom layers of this too.

I don't really understand your comment about precomposed views and JSON objects with coverage bounding boxes - Is that a thing that exists today?

@jidanni
Copy link
Contributor

jidanni commented Dec 12, 2019

Yup, some of these backgrounds,
17432-4
are simple transparent layers of boundary lines.
Therefore it would be extremely helpful if one could choose more than one background at a time (checkboxes instead of radio buttons.)
Or group them into two sets:
First set: only one selection allowed.
Second set: multiple selections allowed.
As far as more fancy settings, maybe implement them later.

@verdy-p
Copy link

verdy-p commented May 9, 2020

What was suggested was just to allow adding a custom layer, and when adding it (WMS or TMS link), add a checkbox in the definition to say if this is either

  • a transparent layer (to be used on top of another background layer using a checkbox to enable it, or on top of a blank background), or
  • a plain layer (to be used with radio buttons in the list of background layers).

Custom layers should be saved in user preferences with their WMS or TMS url, and this transparent/plain info so that they are reusable.

As well the definition of a defining bounding box is sometimes required to indicate the coverage of a custom layer.

As well a custom layer should be saved with info about the zoom levels they support (may be their coverage bounding box changes depending on zoom level, lower zoom levels may support larger areas but in fact from another provider of low resolution images, the high-resolution imagery being available in more limited areas, which are not necessarily a pure bounding rectangle but some custom polygon).

For compositing the view, we would then need several layers (including for the background layer: any area outside the coverage area would display another background layer). This means that layers should be orderable and it is not a complete non-sense to have several (ordered) background layers: the composed view will select tiles from the topmost layer that is covered by its defining area

Then comes the problem of tiles along the border of the definition area: we need to render most tiles but possibly with alpha transparency added to the top most one to allow both background layers to cover each other without creating "blank holes" the view along this border. The alpha transparency applied to the topmost layer would transition from one layer to the layer below it, based on the shape of the polygon defining the coverage area for each zoom level (or ranges of zoom levels for which the polygon applies): the view compositor select a tile from a lower or higher level of the same layer if possible to apply alpha transparency to it, before selecting tiles from a lower layer if the area is still not covered.

This solution would be fine for many custom layers showing high resolution imagery or imagery focusing specific themes but availavble only in specific areas (e.g. drone imagery made by local communities or by specific municipalities or subregions, or offered by some satellite provider after some emergency event for HOT-like projects: areas affected by a flood, or natural events or similar, or some cities affected by an earthquake or major wildfire, or industrial accident, or imageries specific to coastlines or to a natural park; sometimes some areas are also excluded from the imagery due to legal restrictions applied by the imagery provider, such as military areas that are fuzzied or voluntarily deformed with low resolution and a higher/randomized level of shape transforms; these areas are generaly very visible in the imagery but their shape is known: if these areas ar not jsut fizzied or offered at low resolution, shaping transforms can cause problems and these areas should be hidden completely from the tiles as if they were not covered at all by the layer; in that case using another layer, including a drawn OSM map only would be convenient to fill these holes: an OSM-based drawn map or blank layer could remain the generic background at the lowest level).

In summary: selecting layers only by radio buttons and plain non-transparent rendering is not sufficient. We still need additional layers on top with alpha transparency applied to them globally, plus special alpha-transparency along their defining area.

@jidanni
Copy link
Contributor

jidanni commented May 9, 2020

moth tiles -> most tiles?

@verdy-p
Copy link

verdy-p commented May 9, 2020

Yes @jidanni there were some typos left I just fixed a few including this one

@verdy-p
Copy link

verdy-p commented May 9, 2020

Another interesting extension would be to transform a non-transparent layer into a transparent one (notably cadastral maps which are mostly black on plain white: transforming such tiles into a monochromatic tile with alpha values only and constant RGB color would allow them to be superposed on another background layer such as aerial photography, in much clearer way than just applying a static alpha-transparency to this plain tiles which looks too much fuzzy as it severely degrades the contrast on lines and letters and obscures the background layer).
An adition would have a slider in each layer to adjust their global alpha-transparency.

@jidanni
Copy link
Contributor

jidanni commented May 10, 2020

Indeed, cadastral map uses go beyond just parcel boundaries, often being the richest source of what lies under a tree cover, when Lidar isn't available.

@tordans
Copy link
Collaborator

tordans commented May 1, 2022

As a UI inspiration, Placemark just introduced such a feature to add and manage multiple custom background layer https://www.placemark.io/videos/adding-custom-backgrounds-using-xyz-tiles

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

No branches or pull requests

8 participants