Overview map

[fschmenger]

This branch adds OpenLayers overview maps as a configurable component (closes #204).

The control will be added to the map, when a top level overviewMap configuration option is declared.
I added an example to various app templates, e.g.

 "overviewMap" : {
    "collapsible": true,
    "collapsed": false
  }

[fschmenger]

I provide this as a preview for investigation. Maybe you should wait with merging until #262 is included in the main branch, so I can adjust the colorization part. Also I will add some basic unit tests and documentation upon finalization.

Some topics to discuss:

• I'm not really happy with default placement of the control, but all corners of the UI are already occupied. Any ideas on layout welcome.
• Codewise I decided to separate the control from the other OL control initializations in ol\Map.vue. I think on the long run the components should use a self-contained configuration object and this gives us the option to use a custom control (e.g. a vuetify sheet with GeoExt like control later on). Let me know if you think otherwise.
• Currently I'm displaying the active background layer, if a TileLayer, otherwise a fallback to OSM maps is implemented. This is since OL6 requires us to clone a layer if we want to reuse it for overview maps.
• Localization is currently not implemented (same for zoom buttons).
• For a first shot I used the OL names for configuration options. overviewMap uses collapsed while e.g. for sidebar it's visible. I should change it one or the other way round, probably collapsed is the more intuitive name?!

[chrismayer]

Thanks for kickstarting this @fschmenger. Regarding layout: I do not like having it with an "OL button". Since it is a comparable tool to the BaselayerSwitcher it should be the same look and feel, IMHO. Some ideas just shooting from the hips:

Maybe we place different buttons in the upper-left corer of the map, which is surely limited if more components would come into play and not sure how to arrange the open components, e.g. having BaselayerSwitcher and OverviewMap open at same time?

Anotehr option would be to introduce a circular menu, shwoing the underlying map-related tools on clicking the main button.

But the problem remains, how to place the concrete windows / components? Any ideas?

Third option would be to place it in the lower-right corner of the map as you did, but with a vuetify button. This would mean that we have to find another default spot for the floating measure window. Which is surely no problem (hopefully 😉 🤞 )

Thinking about this it might make sense to rework the zoom buttons as vuetify buttons as well? We had that in other projects with other frameworks, to have a common look and feel:

Please ignore the "wrong" icons (did not have any proper in my sketching tool)

[fschmenger]

@chrismayer Thanks for the review and the provided feedback. I will work towards a vuetify based button and a v-sheet then - probably something along the lines of you first sketch and then we can refine it later.

One problem that I see is, that in contrast to the BgLayerSwitcher (which will close on map click) the OverviewMap is of more permanent nature and requires some toggle semantics for its button. I ran a brief test on this: If I place the sheet to the right of a corresponding button, this will consume too much screen space for small devices and the overview map is located very much in the interior of the map control. Maybe I can try and place the sheet under the button in an overlapping fashion (like it is the case now), but then the vuetify button is probably too large and hides large parts of the overview map.

Anyway I can start reworking this when time, and we can discuss the placement issues in the process.

[fschmenger]

Here's a proof of concept implementation with vuetify based UI elements. There are still known bugs

• initialization order renders the extent box in the overview map invisible, until it gets the first map scroll event.
• z-order currently paints this control over the sidebar.

Anyway it should be sufficient for further investigation, so we can discuss placement stuff and you can fiddle around with it easily. For a first shot I decided to align it at 50% screen height to get it out of the way of the BgLayerSwitcher panel.

As mentioned above it doesn't look too impressive on a small screen device:

[JakobMiksch]

I tried it and it works well so far.
One case I observed:
when there are no baselayers activated the overviewMap stays empty. See screenshot below.
Maybe we could handle it similarly to the BaseLayer switcher which does not appear when there are no baselayers.

[fschmenger]

Hi Jakob, thanks for the review.

So far I wasn't aware, that a map configuration without at least 1 declared base layer is valid.
Currently, if no base layers, Wegue will just display arbitrary visible layers with the one on top as prioritized by order of declaration. You end up without a background map when toggling it/them off in the LayerList.
Is this even a desired behavior? IMHO it shouldn't be and we probably should prompt a configuration warning.

Anyway I see no need to disable the overview map in this case, as this feature does not depend on base layers directly.
I probably will just use the OSM layer as default then (currently implemented as a fallback , if the selected background layer is not a TileLayer)

If you have any ideas on improving the layout and positioning, let me know.

[JakobMiksch]

Hi @fschmenger . I was not aware that it is compulsory to have at least one baselayer. I could image applications without baselayers. But I admit, that these are rather exceptions. Using the OSM layer as default is fine for me.

[fschmenger]

Ok, z-index and OSM fallback are in there.
Still looking at the asnychronous initialization problem regarding the extent selection box, which looks like a harder nut to crack.

[fschmenger]

I found a fix for the selection box issue. So apart from documentation, unit tests and the upcoming colorization part that should be all the basics.
We should probably add a configurable size for the control, rather than doing it via css?!

[JakobMiksch]

I tried it again and it seems to be fine to merge.

[fschmenger]

@JakobMiksch Thanks for testing and approving this!

I will merge / rebase with the newly integrated theming PR and make some minor adjustments for the overview map to be theming consistent. Also I will provide unit tests and some basic documentation. This probably will be after the christmas break.

[fschmenger]

I rebased this PR on the current master branch and adjusted it to be theme compliant. Unit tests and documentation have been provided.
Note that 1f86331 and 2435c9d are not strictly related to overview maps, but affected the unit tests and therefore had to be fixed.

As a far as I am concerned this should be ready to merge now.

[fschmenger]

@JakobMiksch Thanks a lot for reviewing this, Jakob!

[chrismayer]

Thanks for this @fschmenger.