Tool: Google maps api

[prushforth]

This issue is for discussion of the reference tool "Google Maps embeds and Google Maps Platform API".

---

Google hasn't joined this CG, so I don't think its wise to use their api as an example of anything, good or bad regarding maps. It would be great to have their contributions, but I've tried to avoid presuming that they want to contribute. I have invited them on many occasions; so many that their not being present can only mean that they don't want to participate.

I guess the same goes for other things like blogs that I may have mentioned elsewhere, which I will fix.

[cmhodgson]

Regardless of Google's participation, their's is one of the most popular examples of a web mapping API. Between Google Maps, Leaflet, OpenLayers, Bing Maps, etc, we have existing examples of the API that is required to build a web map application. If MapML is going to be used to build map applications, it will need to provide a similar API.
Secondarily, if MapML is actually going to be supported by the major browsers, Google will need to be involved at some point... So precluding solutions that would require vendor involvement is pretty silly - vendor involvement is basically the goal, is it not?

[prushforth]

Secondarily, if MapML is actually going to be supported by the major browsers, Google will need to be involved at some point

And we'll grant them the appropriate license to use MapML in their browser at that time. But we can't presume the other way around.

precluding solutions that would require vendor involvement is pretty silly - vendor involvement is basically the goal, is it not?

Yes. When and if G joins the community group we can use their contributions but we can't presume that their implementations are willingly contributed without them saying so, can we? I would bet money on it that there are some aspects of their implementation that are patented.

Despite that, there are established patterns of the Web and Web mapping that are much safer to draw from, e.g. OpenLayers, OGC services, etc etc. which even Google uses e.g. tiles, Web Mercator projection, URLs. No need to risk a cease and desist order based on sloppy IP handling. This is why other CG's actually have bots that check that comments on issues are by people who have signed the license agreement for the CG.

[AmeliaBR]

The tools being reviewed are not chosen as endorsements. Nor do they imply that the companies behind the tools endorse us. If you want, I could add a paragraph that says so, explicitly. For some use cases and capabilities, I expect the reviews to be critical of the limitations of the existing tools.

The tools are chosen as examples of what website authors and website users have come to expect from web maps. Therefore, the biggest decision factor on whether or not to include a tool is how widely it is used (with a secondary consideration being to represent different types of tools). As @cmhodgson notes, the Google Maps tools are the widest used on the web today. Excluding them would cancel out all the claims about being empirical and evidence-based.

And we'll grant them the appropriate license to use MapML in their browser at that time

If you want to pick and choose who gets to use the MapML document format, a W3C community group is not the place to specify it. The goal of this process is to create a royalty-free specification that anyone may implement without requiring special licence or permission.

I would bet money on it that there are some aspects of their implementation that are patented.

This is a fair point. However, we work around it by reviewing multiple tools. If the features we are specifying exist in many different tools from competing organizations, then they are unlikely to become the subject of a patent dispute.

[prushforth]

If you want, I could add a paragraph that says so, explicitly.

Thanks, I don't think it would hurt.

Therefore, the biggest decision factor on whether or not to include a tool is how widely it is used

I think we are converging on agreement here, but I would simply say I have tried to this point use how widely used a commonality between tools is, to generate a requirement, as opposed to how widely used. For example, street view is very widely used, but not common, and so has not been included in any of the documents I've produced to date (nor yours, I note).

Anyway, street view might be outside the norm, so here's a more important selection, and something that google does better than any other web map (that I've seen -- prove me wrong!): accessibility. If you've never needed those accessibility tools you might not realize it, but just ask a disabled user and I'm sure they'll tell you. Anyway, we would certainly not be able to use almost certainly patented features of that widely implemented web map in a standard, unless we got the same commitments from google as we have provided.

If you want to pick and choose who gets to use the MapML document format, a W3C community group is not the place to specify it. The goal of this process is to create a royalty-free specification that anyone may implement without requiring special licence or permission.

You're right, of course. We've already granted those commitments by starting the group. Here's hoping they'll do the same.

[prushforth]

I have tried to this point use how widely used a commonality between tools is, to generate a requirement

One more point, as an example. Web mapping widely and commonly uses the Web Mercator projection. Some say Google defined it, however Open Street Map, on the other hand, has published a wiki with details of that projection system. I therefore decided to call the projection "OSMTILE" in the MapML specification, despite that the name in the OGC WMTS 1.0 standard calls it "GoogleMapsCompatible" (or something like that). I would have opted for the standard name if it hadn't referred to a proprietary service.

[nchan0154]

Some notes on capabilities for the embeds and the Embeds API. The line between 'Embeds' and API is a blurry, as Amelia noted, so I will make note of which particular service' offers this capability in case we need to recategorize later. I am choosing to categorize the embeds as including the Embed API as functionally, they are more similar than the JavaScript API and used to be one and the same, it is just that Google recently monetized a large part of the embed service and while the embeds remain free, the Embed API is not free.

I have bolded some discussion points.

4.3.1 Generate a default map for a given area

Passes. This is likely to be the standard in terms of map embeds. It is relatively simple for a nontechnical user to be able to generate a map for a single location from the Google Maps site, no API key required. You can search for an area by latitude and longitude or by address.

4.3.2 Display a map using tile data from an author-specified web map service

Not possible with embeds, possible with Maps JavaScript API?

4.3.3 Display map tiles defined in various common coordinate systems

Not possible with embeds, seems possible with Maps JavaScript API.

4.3.4 Show pinpoint locations or custom markers on the map

Yes, users are able to generate a list of places and share a regular embed through the Google Maps UI. This is also supposed with greater functionality through the Maps JavaScript API.

4.3.5 Draw polygons or polylines as stylable, interactive vector graphics (separate from the image tiles)

Not supported with embeds. The Maps JavaScript API contains a drawing library.

4.3.6 Support hyperlinks from markers or vector features

While the embeds contain links to additional information (also accessible by keyboard), the information shown is controlled by Google, and there is no way to add custom links to to the markers within the embeds.

4.3.7 Display a basic map without JavaScript

Maps Static API allows you to fetch a basic image map without JavaScript. Unfortunately, this is not supported as the default fallback for the embedded widgets, and nothing is displayed when JavaScript is disabled.

4.3.8 Zoom the map independently from the rest of the page

In embed mode, a modifier key(control) can be used in conjunction with the scroll wheel to pan across the map. The embedded map can also be zoomed with keyboard accessible buttons. Pinch zoom gestures for touch devices are supported. The commands for these interactions are displayed as an overlay to the user when it appears the user is trying to navigate the contents of the map.

4.3.9 Pan the map display

The map display can be panned by clicking and dragging, or dragging with two fingers. There is no way to pan across the embedded map exclusively using the keyboard, but a link to the Google Maps application where you can use the arrow keys to pan is provided.

4.3.10 Load additional map tiles when they pan into view

Supported in all embed formats.

4.3.11 Wrap/duplicate data tiles when panning around the globe

Supported with the default embed with the Web Mercator projection. Alternate projections (non rectilinear ones) may not make sense with this kind of control.

4.3.12 Maintain reasonable scale of labels and lines when zooming

While the labels and lines are scaled, I am estimating that the labels only have a font size of about 8px-10px, and lines often are very thin and on a low contrast background with the default embed color scheme. I'm hesitant to label this as full support because of this. Thoughts?

4.3.13 Dynamically load different resolution map tile on zoom

Fully supported, the experience is seamless.

4.3.14 Hide or show (and maybe dynamically load) vector features and labels on zoom

Fully supported.

4.3.15 Display map data attribution and links

Embeds are attributed to Google.

4.3.16 Apply custom styling to map markers and vector features

Not possible with embeds, possible with the JavaScript API using a configuration object.

4.3.17 Apply custom styling to map controls

Not possible with embeds or the API, but you can implement custom controls in the JavaScript API. Looking at the wording of this capability, I'm thinking this means both of them should have 'no support' as it outlines a clear distinction between creating custom controls and styling existing controls. Should custom controls be a seperate capability?

[nchan0154]

Remainder of notes:

4.3.18 Toggle whether default controls are displayed

Possible with the JavaScript API, not possible with embed API.

4.3.19 Select map view from latitude and longitude point

Fully supported

4.3.20 Select map view from street address or place name

Fully supported. For the embeds, Google handles the search for you and maps the street address to a place ID. For the JavaScript API, you can utilize their Geocoding service in order to convert an address into geographic coordinates.

4.3.21 Reproject map tile data into a new projection or globe view

This is under discussion right now, but neither reprojecting as a globe view or changing map projections after loading the initial projection are supported by embeds.

4.3.22 Save the location or export to other application

This is partially supported. You are able to click through to the google maps and share a link to the same map through the web, SMS and email, which falls under saving the location, but it doesn't provide any addres or lat/long data that would let you export it to another application.

[AmeliaBR]

Possibly relevant addition to the intro: Amazon has based their mapping API on Google maps, to make it easier for developers to adapt code.

De facto standards developing based on the dominant user agent's proprietary API. Sounds like pre-web standards web!

[nchan0154]

@AmeliaBR
Now that @NickFitz has fleshed out the API section, I think we should remove Google Maps API (and all other APIs) from the embed/map viewers capabilities section. If we are going to keep these two parts as distinct sections, we shouldn't have tools in both sections and we should take care to clarify the difference between embeds and APIs in the reviewed section. I can draft this text if you like me to!

Editing for transparency: we are not going forward with this, see this comment for reasoning on why we are including API based tools in widget section #92 (comment)