Use Case: Static maps

[prushforth]

This issue is for discussion of the use case “Display a region of map data as a static image”, its examples & list of required capabilities.

---

Ironically, sometimes an HTML author wants to provide a simple static map that provides some other mappiness (a pushpin or two, for example). It would be good to be able to 'freeze' a map at a location, perhaps using a CSS property, or possibly, though not preferably, an attribute. Being a map, it would still be "georeferenced" for crawlers' sake only, perhaps. But it could use back-end services like WMS or tile caches to provide visual and non-visual semantic context.

[cmhodgson]

This is typically achieved in existing frameworks by not adding pan and zoom controls to the map. These controls are often added by default to the map and have to be actively disabled. The mechanic in use then is not that the map is "frozen", just that the map has an initial location and zoom level, and the user has no way to change those if no pan or zoom controls are offered.

[prushforth]

So its the pan and zoom controls presence that enables drag-to-pan, for example?

…

On Thu, Apr 25, 2019, 1:57 PM Chris Hodgson ***@***.***> wrote: This is typically achieved in existing frameworks by not adding pan and zoom controls to the map. These controls are often added by default to the map and have to be actively disabled. The mechanic in use then is not that the map is "frozen", just that the map has an initial location and zoom level, and the user has no way to change those if no pan or zoom controls are offered. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASTBJIRL4UFXL6UJTXVT3LPSHWHZANCNFSM4HIPFOAQ> .

[AmeliaBR]

It's definitely a good use case & it does mean that we have to think more broadly about what it means to provide default "controls": is the control just the visible buttons, or is it the entire functionality?

[cmhodgson]

The pan control provides the drag-to-pan functionality. It may or may not also provide (arrow) button-based click-to-pan, that might be a separate control or an option to the pan control. Also touch-based drag-to-pan uses different events and sometimes requires different handling or to be separately enabled/disabled (depending on how you want the map to behave on touch-based devices).

[prushforth]

OK, well I was thinking about controls being on/off in a similar way to how the <video> element controls attribute works. Turning <video> controls off doesn't disable the feature, you just have to get it via script. Although maybe the user can't play a video that doesn't have controls and for which script is not enabled, which would be the video player analogy of a 'frozen' map.

[cmhodgson]

Ok after reviewing some API docs, I guess it was way back in Openlayers 2 that pan was a control. In the current Openlayers, DragPan is an "interaction" which seems to be anything that receives events from the map and causes things to happen on the map as a result. In Leaflet controls are generally things that put buttons on the map interface. Drag-panning in Leaflet is just an option to the map.
I personally like the idea of an "interaction" or "control" or "behaviour" as a category of "things that do stuff with the map" all of which can be disabled or enabled in a similar way. I think the map "widget" needs to have several basic built-in such controls or behaviours, and there needs to be an API to add new ones. Editing tools are a separate (sub?) category of tool/control as they manipulate features in a layer, not just the map view.

[cmhodgson]

I think the video element controls attribute is a reasonable parallel, just consider how much more complex a map is than a video, and the level of custom interaction that existing map frameworks provide APIs for, and you can see that you need more than a single on/off switch for all controls.

[prushforth]

you need more than a single on/off switch for all controls

I think you're right, and the HTMLMediaElement interface may show us the way that is done for video/audio. If not we may need to invent :-)

[prushforth]

So, getting back to the topic of this issue, which is, the HTML / map author needs a way to enable a static map, or conversely, disable/make static a slippy map, while still retaining some mappyness.

[Malvoz]

@nchan0154, @NickFitz
I don't know if any of you guys are currently working on the static maps examples, but in case it is of any help and you didn't see the #17 (comment) earlier, I ping you now just as an FYI.

[NickFitz]

@Malvoz I've got static maps on my to do list, if nobody beats me to it. Thanks for the links, they're very helpful.

[nchan0154]

Thank you @Malvoz! I think I can update the capabilities section on this as I missed a couple when looking for them the first time round.

[prushforth]

These APIs are useful. They seem to share a desire to make it simple to include an actual map, possibly composed of fused tiles, as the value of <img src>.

That is author simplicity.

User simplicity, or constrained use of a map by making it 'static', but still a map (as opposed to purely an image), is also a goal (of this issue).

[NickFitz]

A technical note for future reference: the Google API key I'm using is tied to the examples/ path, but in Safari (and I presume other browsers) the default referrer policy for images is to only send the root domain in the Referer: header. I've therefore added https://localhost:8000/ and https://maps4html.github.io/ as permitted referrers for that API key, and will do the same for the other keys I have control of. (N.B. no '*' after the URL - it seems that makes Google, at least, require a path component in the Referer: header.)

@AmeliaBR Could you do the same for the MapBox API key if necessary, please? Oh, and I've realised that I accidentally overwrote the project MapBox key with my own in a recent PR, so I'll make a separate issue/commit to fix that and I've just pushed a fix to get the MapBox API examples working again.

[AmeliaBR]

I've just pushed a fix to get the MapBox API examples working again.

Thanks. Pretty sure I just set domains without paths in the permissions for that key, so it should be fine now.

[AmeliaBR]

User simplicity, or constrained use of a map by making it 'static', but still a map (as opposed to purely an image), is also a goal (of this issue).

Yes, it is definitely worth distinguishing the two different ways of getting a static map image (as <img> versus as a frozen map viewer). There are pros & cons of each.

For our purposes, the <img> examples are less relevant, since it's not really a client-side feature; it's about the server being able to provide a single image for a given request. It only becomes a browser-level feature if we start talking about default map layers and having a URI scheme to access them (as Peter brought up in #8).

However, it's definitely still worth talking about the fact that many of these map data services provide static images, because that shows that there is a demand for static map snapshots.