Use cases and requirements for standardizing Web maps

Hi WICG members,

There have been a number of Community Groups started in the spatial data domain, most of which seem to have gone dormant.

At a joint W3C OGC Linking Geospatial Data workshop last year, I proposed another community group with the aim of specifying and implementing maps i.e. cartographic maps for the Web. It is called the “Maps For HTML Community Group”. I would like to say up front that you are all welcome to join that group and offer advice / support / help. We have no intention of going dormant, at least not until we’ve made some decent progress.

The core idea is that maps are an important feature of the Web, yet there has never been an attempt to design a map feature which leverages the core strengths of the Web, namely HTML, CSS and JavaScript, at least not one which does not solely rely on the latter. Although this post is in the HTML area, and not the “Web Wishes” category, it is the group’s deepest wish that maps, cartography and spatial data become part of the Web platform. More specifically, we want Web users to have access to a diversity of maps, we want HTML authors to be able to leverage Web standards to easily add and progressively enhance maps in their pages, and for spatial data providers to be able to publish map data that is readily used / consumed on the Web, the platform which underpins today’s civilization. Furthermore, there exist well-worn cowpaths in the Web mapping world, and it seems like not too much of a stretch to imagine paving them.

Anyway, going back, we had those initial CG discussions in London, and there were some initial emails and rough outline-type ideas. I floated the idea of maps in HTML over here some time ago, and pointed out the existence of our group back then. The only feedback at that time was that browsers would not (ever) be interested in implementing such a feature, or at a least until it had gained some popularity via Web Components implementation.

That is understood and under consideration, of course. But we have to get there, and the only way to do so is to start.

So, based on the Responsive Images CG blogs and other info I’ve found here, it seems that one of the first things one should do is identify use cases and requirements, and which don’t actually imply a solution (caveat perhaps the constraints of Web architecture, for example).

So I have done that, and I would like to solicit your feedback on that document, the first draft of which can be found on github and in readable form on github.io.

Thanks for taking the time to read and think about this idea. Feedback / pull requests are welcome!

Cheers,

Peter Rushforth

Technology Advisor Canada Centre for Mapping and Earth Observation / Earth Sciences Sector Natural Resources Canada / Government of Canada peter dot rushforth at canada dot ca / Tel: 613-759-7915

Conseiller technique Centre canadien de cartographie et d’observation de la Terre / Secteur des sciences de la Terre Ressources naturelles Canada / Gouvernement du Canada peter dot rushforth at canada dot ca / Tél: 613-759-7915

Cool, thanks for sharing this!

Would it make sense to standardize the definition of zoom levels and x/y that tile servers typically use? Or the template structure that is typically used to describe a URL pattern for a tile server? (Maybe these are already defined somewhere, or maybe it would be useful to have a canonical description of them.)

Is the idea that an author could just define a element, point to a tile server and then the browser would natively handle the tiles, slippy map, UI, etc.? Or does it make sense to keep using JavaScript libraries, Leaflet or otherwise, to do that?

Can you elaborate on which map-related websites are interested in adopting the system you’re hoping to invent?

Would it make sense to standardize the definition of zoom levels and x/y that tile servers typically use?

Standardizing zoom levels is important, and having that definition shared between clients and servers via the media type definition is also essential.

The media type would define projection (coordinate systems) and zoom (which works like scale at a fixed location). I have begun defining the MapML media type here. A MapML response would have a defined projection and zoom, per the request. See below for more info on projection and zoom standards.

Or the template structure that is typically used to describe a URL pattern for a tile server?

That is a possibility, although it leaves much less flexibility than the media type approach, I think. That is the approach taken by virtually all of the tile services right now; it is essentially a “cowpath” that can be paved. Also, I’m not sure that asking HTML authors to put URL templates in HTML pages is a reasonable thing. URLs serving defined media types seems more robust and standard.

(Maybe these are already defined somewhere, or maybe it would be useful to have a canonical description of them.)

The map media type (aka “MapML”) is described here, although the section on projections needs more work. I put the projection definitions in the spec for the map type-extension element I’m working on, but I think they need to be moved to the MapML spec, and referred to from the map type-extension element definition. There’s more work to do there, for sure!

Is the idea that an author could just define a element, point to a tile server and then the browser would natively handle the tiles, slippy map, UI, etc.?

Exactly! The tile server would have to serve MapML, of course, but that doesn’t seem too difficult, as far as I can see. MapML is being defined for this purpose BTW, so it is unencumbered by legacy cruft. I wrote a servlet that will do this if you configure it with the URL template for the tile cache. It’s not the final word for the server, but it has got things going, anyway. I see a more robust integration into apache and other servers being eventually important.

The map type-extension element is described here: http://maps4html.github.io/HTML-Map-Element/spec/ . I can see that definition eventually being integrated into the HTML spec :-).

Or does it make sense to keep using JavaScript libraries, Leaflet or otherwise, to do that?

I definitely think it makes sense to continue to use JavaScript libraries, especially to progressively enhance the map user experience, which is a slightly different role than what those libraries currently provide. I think a fundamental API should be provided by the browser at the map element level, since it is the nexus of spatial information for the HTML author and user. Mapping libraries could take advantage of a browser-provided API to provide a diversity of help to the HTML author.

As future work I intend to prototype that API, I think it will be fun! Collaborators are welcome right from the start. Thanks for your questions. Let me know if anything is unclear!

That is a very interesting question. I am guessing adoption of the map (type extension) element might eventually peak somewhere between the audio element (thanks, Jake and Paul!), and the video element in usage. There’s no doubt that maps are everywhere on the Web, but I guess asking which specific web sites are interested in adopting the map type extension element is a bit like asking what video related websites were interested in adopting the video element before it was created. I do believe there is an immense need, if not yet demand, to add maps to the Web platform, in a way that respects the platform as a foundational part of society.

I work for a national mapping agency. In the past, my organization made paper maps. In my kid’s high school geography class, our maps are used to teach geography concepts - they are embedded in the textbooks. We are starting to phase out paper maps. How are kids going to learn geography in the future? From the Web, it seems clear. But, the Web doesn’t have maps. It has SVG, and MathML, and HTML and CSS, and JavaScript, which are all great, but they are not the foundation of maps. I believe the addition of maps to the Web platform is long overdue, in fact, but thankfully there are well-established patterns (tile server) and standards/libraries (Web Components) that can be used now to progressively implement that addition without having to boil the ocean.

Thanks for your question!

I notice that you introduce the concept of “mode” for the <map> element. I imagine this would be a hard sell, to have browser parsing engines swap out the meaning of the element, not to mention possible compatibility problems with existing content. In addition, I don’t see much semantic overlap at all between the two modes that would justify reusing the same element.

I know it’s early to talk about naming, but may I suggest <webmap> instead?

I looked into that a bit and found that HTML 2 defined Image maps, and a subsequent RFC defined client side image maps (essentially the <MAP> element today).

I pinged Dan Connolly about the semantics of image maps, and he indicated that they were, at least partially, introduced to represent cartographic maps as well as the simple 2D link array they currently supply. In other words, <MAP> currently means both <MAP> in the existing sense and possibly <webmap> too. In fact he provided a reference to a paper from the first www conference, which is available today only in pdf or via the wayback machine: tl;dr maps were on the Web early in the game!

In a future iteration of the map type-extension element, I intend to add the ability of the HTML author to supply image-map type links on their map (e.g. pushpins), which is a common use-case for Web maps today. I thought it might be possible to have a <MAP> element which would provide fallback to existing, if not “semantics”, but behaviour anyway, (providing that relevant content / images was provided). I may be dreaming, and like you said, it is a little premature, but thanks for the discussion, it is fascinating. I have filed an issue on the spec, to be revisited. In the end I guess what will matter is getting the new semantics and behaviour defined and built and accepted. I would not let the naming get in the way of that, for sure.

Cheers, Peter