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

Capability: Default map provider #8

Open
prushforth opened this issue Apr 15, 2019 · 14 comments

Comments

@prushforth
Copy link
Member

commented Apr 15, 2019

This issue is discussing an aspect of the new Use Cases and Requirements for Web Mapping (which is a great initiative and hopefully something that can be collaboratively developed by the Web standards and Web mapping standards communities. Those who show up write the standards!).

I have been thinking about whether having a default map provider should be part of the use cases / requirements. Video is a pretty close analogy to maps in many ways. I'm concerned that it will end up being a bit like having a browser-default video provider: not something that most users would want, but certainly something a browser vendor with a video service would like to have. This was also a question at TPAC last year.

Default map provider is something which certain web components already do (as noted), and that is a standard at a level that I don't believe is where maps should be standardized i.e they bury / don't provide the URL. I think having maps which support URLs for content retrieval goes a long way to obviating the need for having a default map provider (see Manual and/or Automated Map Creation and Layers - Add Using Standard URLs slightly below that).

It's incumbent on us (the mapping / map provider community) to make it easy to find target(s) for those URLs, which we're currently trying to do by getting support for MapML built into as many existing map servers as possible. If OpenStreetMap (say, to pick a non-commercial example, but not wanting to limit examples to non-commercial services, could also be open data/government providers) was to support MapML instead of iframe embeds, then they could provide valid MapML document so their maps would be available for embedding at a source URL.

In sum, I believe that instead of requiring (or even allowing!) default map provider, we should require URLs for maps / map content. Thanks for sharing your thoughts!

@jvanulde

This comment has been minimized.

Copy link

commented Apr 15, 2019

@prushforth can you share a link to the "Use Cases and Requirements for Web Mapping" initiative?

@prushforth

This comment has been minimized.

Copy link
Member Author

commented Apr 15, 2019

@cmhodgson

This comment has been minimized.

Copy link

commented Apr 15, 2019

The use cases mentioned an @edent's blog post are mostly centered around the use of a Mapping Engine which is already installed or built into the system on which the browser is running. Eg. Google Maps or Apple Maps. Realistically, on mobile device in particular, it would make sense for the browser's internal implementation of the tag to defer to Google Maps or similar. Given that the choice of which Map Engine to use is going to be limited to those installed on the system and supported by the browser, and the "default" map provider is essentially defined by the Map Engine, you would need a non-brand-specific way of saying "show an earth-based basemap layer, with these features in order of preference".

This would allow the element to take advantage of Map Engine features like pre-cached local map tiles. There is no URL-based way to access those, AFAIK.

@prushforth

This comment has been minimized.

Copy link
Member Author

commented Apr 16, 2019

There is no URL-based way to access those, AFAIK.

I'm suggesting that URLs are the way that resources are loaded by browsers, so tiles should follow the same pattern, since they're also resources. I think its an anti pattern to have a default tile provider. Its similar, to having a default HTML provider. Which might be the case for a centralized system, like say Facebook, but its not the Web.

@AmeliaBR AmeliaBR changed the title Default map provider Capability: Default map provider Apr 18, 2019

@Malvoz

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

I believe that instead of requiring (or even allowing!) default map provider, we should require URLs for maps / map content.

Allowing for default providers and to specify a designated provider would allow for really simple implementations in terms of HTML markup, while of course retaining the flexibility to choose a certain provider.

Similarly, web browsers have default search engines, but still allow users to change it. If default map providers were allowed, perhaps the end-user could configure their preferred map provider just as they do with search engines.

Not sure if this is worth mentioning, but consider that a developer who implements a Content Security Policy would always have to specify the source location in a directive if default providers weren't a thing.

@prushforth

This comment has been minimized.

Copy link
Member Author

commented Aug 13, 2019

I think there are practical issues to examine, and appreciate you raising CSP because I dont have much experience with it, but it seems like it might be worth its own issue.

But back to default map provider.What if a location of interest appears on one default map provider, but not another, so the user who was using the out of date (or up to date) default map provider would receive a puzzling experience if the location the author intended did not appear on the map.

Another thing would be control of the default map layer - would the layer appear in the set of layers in the DOM or would it just exist without having a DOM presence?

There's also privacy considerations, since requesting an area on a map reveals information about you to the service providing the map.

Probably others, I'll add when I think of some and have more time.

@Malvoz

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

appreciate you raising CSP because I dont have much experience with it, but it seems like it might be worth its own issue.

Actually, dismiss my argument about CSP, not allowing for default providers does not add any additional complexity in terms of how developers manage CSP already.

What if a location of interest appears on one default map provider, but not another, so the user who was using the out of date (or up to date) default map provider would receive a puzzling experience if the location the author intended did not appear on the map.

Users are already experiencing this on the web through broken links, and thus I don't think it's a showstopper for allowing default providers, but I agree that's a concern.

Another thing would be control of the default map layer - would the layer appear in the set of layers in the DOM or would it just exist without having a DOM presence?

Presumably, using a default map provider would offer the very same capabilities as when a provider is specified using <layer src="">, even if that means exposing the layers in the DOM?

@prushforth

This comment has been minimized.

Copy link
Member Author

commented Aug 15, 2019

a default map provider would offer the very same capabilities

That would be important, I think.

I can't put my finger on a blocking argument at this point, I just think this is something that should be under the control of the author; their responsibility, even. And we can and should make it easy to provide content.

Anyway, we can work on / think about it and see how it will work best.

@AmeliaBR

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

When it comes down to the markup structure, if default maps are supported, one option could be to still require the author to specify the <layer> element, but with an attribute that indicates the default map type (street map, satellite, etc.) that should be inserted, instead of a src/tref.

It could even be defined in such a way that you could specify a src as well as a default layer type, and the src would provide the fallback if the browser doesn't have a suitable default layer to use.

@prushforth

This comment has been minimized.

Copy link
Member Author

commented Aug 16, 2019

@AmeliaBR thanks, that's a bit better. I awoke with the following thought (sometimes these are my best ones ;): my main concern is that some implementors will have a strong bias towards default layers, so much so that they decline to implement <layer>, preferring to have almost the entire behaviour of the map customizable through progressive enhancement, and not through URLs such as are specified by the current layer src.

So, I feel that URL-free maps should not be possible, but could be enabled by a custom element if you wanted to make one (such as Google has done with their current google-map custom element).

@Malvoz

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

@prushforth

Correct me if I'm wrong, but I'm not seeing how your thoughts aligns much with what @AmeliaBR's #8 (comment) is suggesting. I think what Amelia is suggesting reflects my initial thoughts on how markup for use with the default provider could look like: <layer> is always required, where <layer src> is used to specify the source URL of a certain provider and <layer defaultProvider>~ (attribute, no src) will use the default provider available on the system or as configured in the browser settings.

my main concern is that some implementors will have a strong bias towards default layers

I sympathize with that concern, however an implementor with a bias towards a certain map service provider will still have the same incentive to market that provider. Only allowing URLs means that as a developer I'm now more concerned with which one provider I should point the src to, so I'm inclined to research and find a SO post asking "What is the best map service provider??" where the top-voted answer will say "Just use the Google Maps provider", now all my users on Edge, Firefox etc. will get maps from that provider instead of the default one, whether that be Bing Maps or something else so the biased implementor wins again.

@Malvoz

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

Personally, I have a bias towards allowing default providers (as a developer, I'm not an implementor) because it makes for super simple integration with HTML. Default providers also opens up for a potential geo: URI scheme and I'm inclined to think that performance of a default provider would be unmatched. And even with allowing default providers, you'll still have developers wanting to use a certain provider using <layers>'s src, and they can use the default provider as a fallback if the specified provider is unreachable for some reason.

@prushforth

This comment has been minimized.

Copy link
Member Author

commented Aug 16, 2019

@Malvoz Amelia's proposal, like yours, doesn't allay my concern which is mostly, but not solely, that implementors will prefer to implement only default providers in markup, pushing all / most of the semantics of maps and layers into APIs, which is only barely ahead of where we are today (see the google-map element linked to above).

allowing URLs means that as a developer I'm now more concerned with which one provider I should point the src to

Is it really that hard to add a URL to a layer src value? And having done so, we're assured that the user gets the same experience in all browsers. I mean, we do so for img, and video, etc. Anyway, maps aren't only basemaps, they're thematic and so on. So any additional layers the author wants, they're going to have to find a URL for.

I'm inclined to think that performance of a default provider would be unmatched.

Yes.

The performance of large providers today is driven by use of tiled vector data, the format of which is highly proprietary. I feel that a declarative solution to map content semantics could support tiled vector data through possibly a 'tile' event, handing the tile to script for rendering or what-have-you. But, a default provider in today's web, that used the same tiled vector data that they currently do, would either have to execute the same rendering JavaScript, or execute some native code equivalent in order to accomplish the rendering (which would be fast, as you say).

Default providers also opens up for a potential geo: URI scheme

That sounds interesting. How so?

@prushforth

This comment has been minimized.

Copy link
Member Author

commented Aug 18, 2019

@Malvoz @AmeliaBR What about a tile: URI scheme? I dont know how URI schemes work yet, but let's say you were allowed to define some default template variables in a URI scheme e.g. {x}, {y}, and {z} or some such set. The you could allow a <layer src> to refer to such a URL, and THEN you could allow a URL such as <layer src="tile:internal-cache> (where internal-cache is defined by our URI scheme ) and the intermal cache is defined to be a tile cache that does not require network access, thus preserving privacy.

I'm just putting out ideas, correct my notions where appropriate.

This has the benefit of preserving layer (and tile) semantics, privacy, and simplicity (for authors).

WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.