Capability: Default map provider

[prushforth]

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]

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

[prushforth]

The links are in the comment above http://maps4html.github.io/HTML-Map-Element-UseCases-Requirements/#capability-default-map

[cmhodgson]

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

This would allow the

[prushforth]

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.

[Malvoz]

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]

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]

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: broken links!

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]

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]

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]

@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]

@prushforth

Correct me if I'm wrong, but I'm not seeing how your thoughts aligns much with what @AmeliaBR's https://github.com/Maps4HTML/HTML-Map-Element-UseCases-Requirements/issues/8#issuecomment-521783604 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]

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]

@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]

@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?

[AmeliaBR]

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,

I don't think this is a reasonable concern. If it was true that browser teams would only be interested in implementing maps that integrate with their company's commercial map providers, then excluding default map layers from the spec would just decrease the likelihood of the spec being implemented at all.

[prushforth]

I made a pull request with a bunch of argumentation and a conclusion in it, which should properly be a comment on this issue. My apologies to the group. In my defense, I feel strongly about this issue; it's one of the whole reasons I started the community group, and that may have caused my error in judgement.

Anyway, here is the substance of my comments from the pull request, open for debate:

In the commercial Web mapping APIs listed here, the website author typically does not specify the map data source or other details about the map. This is considered a default map: a map is created in the page according to page specifications, but little to no control is required or given over the map that is generated or authored.

This capability forms a distinct division between the commercial and open source Web mapping toolkits listed (Leaflet / OL).

In considering the design and use of a native map widget for the Web platform, by allowing a map to 'default' to a provider, a Web author would be forcing the user of their Web page to a use a third-party service which could harvest not only the fact that the user visited the Web page - potentially a minor violation of user privacy - but if the geolocation API of the browser was in use by the map, potentially transmitting enough information to the third party to deduce the exact location of the user, which could be a much more significant privacy violation, since a user's location should be considered sensitive information under most circumstances.

While the above scenario is not very different than the current situation (with the salutary exception of the open source mapping toolkits), incorporating Web mapping capability into the Web platform should create this opportunity to improve the situation for Web map users, and not perpetuate a current failure mode.

There are additional negative aspects to this capability. Browser system defaults are powerful economic forces. This is exemplified by the value placed on being the default search engine in a browser, or defaulting to allowing third-party cookies. The effect of being a defaultable value would be the opposite of that which is desired by creating native Web maps, that is to say it would be a force for centralization. And centralization of the Web and the resulting aggregate effects of small privacy violations has arguably given rise to negative externalities including erosion of democratic institutions due to manipulation of public opinion through targeted advertising.

The default maps capability is not consistent with the Architecture of the World Wide Web, because it does not rely on hyperlinks. It is also inconsistent with the HTML Design Principles, because it violates the priority of constituencies, in that it places author convenience ahead of user privacy, and it violates the principle of specifying well-defined and testable / non-implementation defined behaviour. Finally, it is inconsistent with the Extensible Web Manifesto in that it is an existing high level behaviour defined exclusively in JavaScript, that is not defined in terms of the low-level capabilities that are required to implement it.

As such, a 'default map provider' capability is a failure of consistency, because breaks established patterns, and represents a risk to privacy, because it has great potential to reveal sensitive data.

I believe that the only logical conclusion is that such a feature is impractical (to put it gently) when considered for the Web platform.

Peace!

[AmeliaBR]

Thanks for the comments, Peter.

One other point that came up when we were discussing this, is that it is important to distinguish between the existing map frameworks that have built-in maps as an option (but you can provide your own maps as an alternative) versus those that serve only to display the default map layers (plus author annotations).

When describing this capability, I never considered that the capability to request a default map layer would exclude custom map sources. But of course, the reality is that many commercial mapping frameworks only have one and not the other, so we need to distinguish that.

[AmeliaBR]

In PR discussions, @Malvoz brings up another complication:

The way this capability is currently described is very specific: "Generate a default map for a given area" - you might want to generate a default map without specifying which area? The "for a given area"-part looks like it should be a separate capability, while this capability should focus on "default provider", i.e. generate a map without specifying the source.

@nchan0154 also mentions:

Perhaps we need to update the language in this capability to reference 'default map layer' or 'default provider'? 'Default map' to me implies a level of functional and semantic completeness.

Given that this is already a contentious discussion, I agree that it might be worth keeping the capability narrowly focused on the idea of a default map layer (even if that default layer always represents an area, that's a side effect). Setting the bounding box or the center-point and scale is a separate capability.