id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
15369	[PATCH] download area display in SlippyMapBBoxChooser	ris	team	"There are a good number of reasons it's useful to be able to see the extents of the downloaded area in a SlippyMapBBoxChooser. In the download dialog it makes it possible to line up a new download with the existing downloaded area. The MiniMap does a much better job of giving the user an idea of where they are in their larger work area if they can see the download bounds.

Here I've implemented it deliberately in a near-identical way to how `OsmDataLayer` performs the painting. Why haven't I made an effort to refactor & share the implementation? It turns out it's ''just different enough'' to make that useful. The differences mostly come from `JMapViewer`'s different idea of projections & geometry to that of `MapView`'s.

The hatched texture is fetched from the layer itself via a new accessor method `getHatchedTexture()`. Why did I not make this a static method when the underlying field is static? Because I can foresee a time when it becomes more common to work with multiple downloaded osm layers (especially now we have overpass support) and hatching colour or style could conceivably be used to differentiate between them (?).

Reasons you may **not** want to apply this as-is:

It is currently not optional. I was planning to add a control for this to the bottom of the ""source button"", similar to how openlayers maps (used to) allow optional layers to be controlled. But then I looked at the source of the ""source button"", and it became clear that this is a horse that has already been flogged a bit far as it is.

So... I propose that before this gets considered for inclusion I give the source button a bit of an overhaul. It's trying to mimic a pattern found in old openlayers maps which will be becoming less and less familiar to users over time and does so in quite an ad-hoc and accessibility-troubled way. My suggestion would be to replace it with a fairly normal-looking `JButton` showing the fairly widely recognized ""layers"" symbol which, when pressed, opens a bog-standard `JMenu` which can expose tile sources through radio menu items or boolean options through toggle menu items. This completely avoids the ""your panel isn't very big and you have more than 4 tile sources? good luck choosing the bottom ones."" problem by deferring it to swing.

Thoughts?

Attaching patches..."	enhancement	closed	normal	17.10	Core	latest	fixed	SlippyMapBBoxChooser download area OsmDataLayer paint