Map Markup Language

A draft specification for this new format is available, and I am greatly interested in your views about it. It is based on HTML and MicroXML syntax. As such it is designed to be consumed by browser-like applications. There is currently a custom element prototype client.

The objective of the format is to capture map semantics, such that a client can consume the format and present a map if desired.

You can find the draft spec here. If you would like to contribute, you are welcome to fork it etc., but I would be grateful if you joined the Maps for HTML CG, or WICG for substantive contributions.

I’m happy to answer questions here as best I can.

Thank you.

Cheers, Peter Rushforth

FWIW, the repeating “Unofficial draft” background makes it quite hard to read the text.

Sorry about that! Fixed.

Thanks

Hi, There’s a new version of MapML available, that takes into account some of the discussion we had during OGC Testbed 13.

We’ve added a <template> element as an alternative to the extent@action attribute.

The <template> element allows the map author to describe a tile cache or an image service that uses a URL template for access to tiles and images. The <template> variables must be listed as <input&gt elements of the appropriate type.

This facility makes it easy to create a static MapML document that can describe a global dataset with multiple layers, without needing a specialized MapML service.

https://maps4html.github.io/MapML/spec/#the-template-element

I would be very interested in any comments you might have.

Thanks! Peter

We have replaced the <template> element with a templated <link> element. For example (view source link)

Hi, I am a web mapping framework developer . Do you know svgMap? I have worked on w3c etc. for more than 10 years to make standards for web mapping using SVG. Its architecture is quite heterogeneous compared to those of OGC’s specs and implementations, so it may take time to understand, but this material may help with that. I think this material I published recently will help you to understand it.

And this submission will be start point of svgmap in w3c. https://www.w3.org/Submission/2011/04/

Thanks to independent and ongoing development, I believe that SVGMap has features that are not found in other Mapping architectures. Therefore, I believe that the contribution of SVGMap will allow us to evolve better Web Mapping.

Note: I did not know which service is actively using maps4htmlCG, so I multi-post it with gitter.

Thanks for that link. You have obviously put a lot of work into your proposal. I admit I don’t fully understand the ideas at this point, and it is always hard to get other people to read enough to understand your perspective on things.

Anyway, I would be interested in reading more about the SVGmap framework and architecture. Perhaps if I understand it enough, there will be aspects we can share and incorporate into an eventual proposal to the browser community.

Maps and spatial information are obviously extremely important to decision making. I think that maps and spatial information are, or could be involved in almost all decisions, if we only thought about it in that way. In some ways, the Web is the perfect decision-making engine for humanity, and all that is missing from that engine is an understanding of location.

Are you going to be at TPAC 2018? i would love to meet up there and talk about maps.

I found thedocumentation of SVGMap on your site. I am reading it more closely now.

Hello, prushforth.

I am sorry that the reply was delayed. I was busy in order to attend TPAC 2018 as KDDI’s AC Rep., Because I had to suspend the operation development of the in-house integrated web mapping system which is my main work for a long time. Therefore I am sure to meet you with TPAC 2018.

I also strongly agree with the view that the map is a very important information medium for mankind. Especially I am evaluating important characteristics of non-language media from the background that I am poor in English

As you are investigating SVGMap technical document, I would also like to study the Map Markup Language architecture and specifications.

Points in the background I designed SVGMap are the following two points.

• From a very primitive sense I held over 20 years ago, I believe that maps and various other illustrations should be able to share many concepts, except for some unique features . Therefore, I hope to prevent the reinventment of the wheel by combining them with the map as much as possible. That is technically a common use of TAG sets and APIs. And this is true not only for maps but also for concepts called geospatial information. Illustration on the Web is represented by raster graphics PNG, JPEG and vector graphics. Unfortunately vector graphics web standards are not yet well established compared to raster. SVG has been in the history of suffering for 20 years, but still I think that is important.

• Since the nature of hyperdocuments on the Web is very simple and powerful, I want to make it available for maps. Here, I want to apply unique features of the maps such as being able to synthesize various information on a common canvas and visualize it (also called it mashup on the Web) and visualize it for overlooking information (I think this is mainly realized by navigation by zooming and panning). Since SVG has functions for various hyperdocuments, it is preferable to exploit functions that need further expansion as much as possible utilizing it. However, there are still many issues in SVG. And it is hoped that further integration with CSS and HTML will be further promoted.

Since the document of SVGMap is mostly Japanese, information in English relies on machine translation by google translation, so it may be inconvenient for you.

• Homepage of SVGMap: https://svgmap.org/
• Technical tests and subprojects: https://www.svgmap.org/devinfo/devkddi/lvl0.1/

Regards,

Satoru

Hi Satoru,

Great!

Not at all. Thank you for taking the time to write.

Agreed.

Absolutely, this is an important principle of Web standards design, also somewhat codified.

I think that what gets standardized by common practice should in principle become standardized at the appropriate level

Yes!

This is essential. It is what geospatial interoperability is all about. The MapML proposal is designed for this.

This is a core processing semantic of maps, yes.

We will have great discussions!

This is excellent, thank you.

Ok, I’ve been told that the specifications are hard to follow. Perhaps using the demo page will give you a better understanding by doing “View source” etc. https://geogratis.gc.ca/mapml/en/ and https://geogratis.gc.ca/mapml/client/map-carte.html are some examples including vector and raster data.

Safe travels! Talk with you soon. Peter

Hi Peter,

Thank you very much for comments on many sympathies.

Still I do not fully understand, but by reading the source code of the site you showed in addition to the spec sheet, I interpreted that MapML has the following three features.

• It has a mechanism for set a map panel (canvas) with a UI for displaying a map on a web browser : < map> element
• It has a mechanism to express one “map” content. It combines layers as resources on the Web such as raster tiles and vector data to form a set of layers. : < map> element and < layer-> element
• It has independent markup language that mainly serializes vector data (geometry such as point, lineString, polygon) by microXML : document format with < mapml> document root element

Please note, as SVGMap that I design treats them separately, I think that the first and second features are another thing as my viewpoint.

First, about the third feature, the description language with < mapml> root element. I felt its similarity with geoJson, classical GML, KML. I felt I needed to know the motive for you to design this. There are a couple of my imagination, including elimination of the complexity of GML by microXML, pursuit of higher consistency with html. Here, I expected SVG to probably have the same purpose as these. For that reason I have been designing SVG with geographic information extensions applied as geographic information data format. The reason I chose SVG is basically because I wanted to merge the geographic information with the data format of other web content. SVG has a common concept with many geometries of geographic information. However, it goes without saying that standardization of SVG has a history of suffering.

Next on the data of the layer set which is the second feature. I think that such a concept has not been seen before in the map and the geo community. Usually it has been written in javascript source. And I agree with the idea that such a tag set should exist. Here, I also made SVG have its role in SVGMap. SVG has a function to embed web contents based on a painter model such as image element forignObject element and iframe element (SVG 2.0). There are also iframe elements and img elements in html, and it is possible to synthesize layers by manipulating CSS. Therefore, I thought that I needed to know the motivation you designed the < layer-> element.

Lastly on the first feature to set the map panel on the browser (< map> element). I think that such a concept has not been seen before in the map and the geo community. And it was not considered in SVGMap. In the javascript framework called SVGMap.js, I built it at random. I certainly agree that such elements you designed are necessary. Overriding the < map> element is an interesting idea.

Here, I think that functions such as zooming, panning, and layer control, which are bound to the < map> element, are not only useful for geo maps. For example, the zoom pan function is also widely used for viewing Ultra High Resolution Graphics (such as Deep zoom: https://en.wikipedia.org/wiki/Deep_Zoom, https://openseadragon.github.io/) and vector graphics data. And the layer control function is widely used in the technical drawing field. Therefore, I think that it is desirable to seek versatility not only for maps but also for these broad graphics use cases.

Well, I’d like to explore the layer again. Elements for embed of external resources used in svgMap to achieve similar layer functionality allow multi-level embed. As a result, the structure is tree-like, deviating from the basic layer concept. And in SVGMap, this tree structure is used not only as a superordinate concept of layers but also as a structure for constructing a tile pyramid of multi zoom levels. As a result, it is possible to implement a highly efficient vector tiling method. This is described in the second half of the slide of Quad Tree Composite Tiling previously introduced. The tiling architecture of SVGMap is notably different from that of map / geo community.

That is my study so far. Because it could not take much time, it may contain many misunderstandings.

I’m looking forward to discussing with you on TPAC.

Regards,

Satoru

Hi Satoru,

I agree with this, but, and it has been a long time since I read SVG, but at the time I felt that SVG was not conceived for geographic features. We should discuss this point, as I don’t want to speak badly about anybody’s work, especially if I am ignorant of it.

On the other hand OGC Simple Features, represented by KML and more recently GeoJSON, is also an established standard for geography. On the one hand KML is not directly suitable, since it does not separate concerns of styling and content, and on the other hand GeoJSON, being JSON, is Web developer / JavaScript friendly, not necessarily browser-standards-friendly. So for the reasons that you mention (elimination of complexity where unwarranted, consistency with HTML), I felt that the Simple Features model needed adaptation to Web standards.

I also thought that SVG would be very important in map creation, especially annotation and legend graphics etc., so I thought that the geospatial standards community pitching in with the SVG community would strengthen the position of both on the Web. MapML is a lot about standardizing coordinate reference systems and making their definitions part of the standard. There’s no reason that I can think of that SVG, or any other HTML content for that matter couldn’t be drawn on a map as part of a layer content, and pan and zoom with the layer as required. I would like to discuss this idea with you.

That’s true, but it is found in HTML, including the painters model: the <img usemap="mapname"> is the ‘basemap’ layer and the <area> elements are the layers. Also, the <video> and <audio> elements, and now <picture> too, have their <source> child elements, so I imagined that the HTML author could use a similar simple mechanism for stacking map content. I would have used <source>, but its semantics are ‘choice’ not ‘checkbox’. Also, ‘layer’ is meaningful for maps.

I think that the <map> element should come with builtin controls that make the map accessible by default, but clearly any map controls that the browser provides will not be suitable for high-end mapping applications. So that is something I want to collaborate more on with the WICG community: what is the DOM API that the map and layer can provide that will allow the Web developer to provide a more progressively enhanced user experience? SVG is obviously valuable here for interactive graphics and animations.

I’ve been thinking that perhaps the map element could have its controls built into a native shadow root, and that the developer could turn that off and provide a script-controlled ‘static’ control layer, perhaps something like html / svg markup here. Leaflet has an internal abstract structure it calls the control ‘pane’, which has a simple vocabulary for placing controls on the pane (e.g. upper-left, lower-right etc). Perhaps CSS layouts could help here.

Yes.

Vector tiling is becoming important especially in consideration of bandwidth, although I am not an expert in it and I will learn from you. Collaboration between the Web and geo communities is one of the goals.

Peter

Hi Peter,

I am glad that I could meet you at TPAC.

I think that it is half true. Current svg will not reflect the geographic information feature definition straight. On the other hand, since the concept of graphics and the concept of features of geographic information are common, I think that fusing is possible by improving issues. I implemented a bidirectional conversion function in SVGMap.js and its surrounding libraries which is not perfect between svg and geojson.

Yes, especially wikipedia is very important to focus on the publication of illustrations including maps by svg.

I think so.

Although browser vendor cooperation is very encouraging, the evolution of browsers that rely solely on their native implementation results in a heavy burden on them. Especially due to the remarkable spread of the application of the browser in recent years. I also expect not only the progress of browsers by native, but also situations in which implementers based on javascript like us can contribute more directly to the evolution of browsers. I think that polyfill and web components are part of the advancement of technology for such change. Efforts to increase stakeholders by expanding use cases to non geo fields, such as technical drawings and ultra high resolution graphics, will also boost native implementation.

Satoru

Strong agree! I would like to take this opportunity to congratulate Mozilla and Firefox on their current release of Custom Elements in FF, as well as the architects and developers who have pushed Web Components to their current status. This (Web Components) is the killer feature that enables low-cost, low-risk iteration on proposals for the Web.

On the other hand, we need to have the experts help / guide us in designing the layers of this high-level proposal so that it fits appropriately with the Extensible Web concept. We intend to iterate on the design, and hopefully the <map> and <layer> elements can approach a suitable proposal, with associated Web Platform Tests as we cycle on the ideas.

Cheers, Peter