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

Use Case: Static maps #17

Open
prushforth opened this issue Apr 25, 2019 · 17 comments
Open

Use Case: Static maps #17

prushforth opened this issue Apr 25, 2019 · 17 comments
Labels
discussion: use case a possible use case: should it be included? what should it say? status: editor's draft there's a draft section in the report that corresponds to this discussion

Comments

@prushforth
Copy link
Member

@prushforth prushforth commented Apr 25, 2019

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.

@prushforth prushforth added discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft labels Apr 25, 2019
@prushforth prushforth changed the title Use Case: Static map Use Case: Static maps Apr 25, 2019
@cmhodgson
Copy link

@cmhodgson cmhodgson commented Apr 25, 2019

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
Copy link
Member Author

@prushforth prushforth commented Apr 25, 2019

@AmeliaBR
Copy link
Member

@AmeliaBR AmeliaBR commented Apr 25, 2019

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
Copy link

@cmhodgson cmhodgson commented Apr 25, 2019

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
Copy link
Member Author

@prushforth prushforth commented Apr 25, 2019

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
Copy link

@cmhodgson cmhodgson commented Apr 25, 2019

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
Copy link

@cmhodgson cmhodgson commented Apr 25, 2019

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
Copy link
Member Author

@prushforth prushforth commented Apr 25, 2019

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
Copy link
Member Author

@prushforth prushforth commented Apr 25, 2019

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.

@AmeliaBR AmeliaBR added section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion and removed status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft labels May 26, 2019
@AmeliaBR AmeliaBR removed the section: map viewer Capabilities & use cases for declarative map viewer widgets label Jul 25, 2019
@Malvoz

This comment has been minimized.

@Malvoz
Copy link
Member

@Malvoz Malvoz commented Sep 13, 2019

@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
Copy link
Contributor

@NickFitz NickFitz commented Sep 13, 2019

@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
Copy link
Contributor

@nchan0154 nchan0154 commented Sep 14, 2019

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
Copy link
Member Author

@prushforth prushforth commented Sep 14, 2019

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
Copy link
Contributor

@NickFitz NickFitz commented Oct 3, 2019

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
Copy link
Member

@AmeliaBR AmeliaBR commented Oct 3, 2019

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
Copy link
Member

@AmeliaBR AmeliaBR commented Oct 3, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: use case a possible use case: should it be included? what should it say? status: editor's draft there's a draft section in the report that corresponds to this discussion
Projects
None yet
Development

No branches or pull requests

6 participants