The MapML Proposal - Part Two

I gave a presentation (slides) that covered the core of the MapML proposal (video), but I was unable to go into details that serve to paint a full picture of the proposal as it stands. While I feel that the proposal is pretty solid from a hypermedia design perspective, opinions seem somewhat divided.

While I am still working on the deck to improve animations and explanations, I would like to share the video of the presentation that I gave on Part Two of the proposal. We want (need, actually) your specific feedback about the proposal, whether you are a Web browser developer OR a Web map developer.

Anyway, I don’t quite understand all the divided opinions about the proposal, so apart from “it’s too complex”, would you please listen and tell us exactly what it is about the proposal that does not work or is unfinished, both from the Web browser developer point of view and the Web map developer perspective. I’m not sure it’s possible to divide the proposal into “primitives” and “high-level features”, but I do believe that if agreed upon, the development of the proposal could be phased to deliver useful pieces incrementally.

And, could I politely ask you not to say “it’ll never fly because Google”, because I don’t believe that to be true, and it’s been said (many times) before. Thanks.

1 Like

@PeterR I have two straightforward questions.

First, Each elements*1 under the mapml element feels pretty close to svg. For example, I’ve heard on gitter that it requires features that svg doesn’t yet have, such as styling and linking to subpaths.

If you have a document that lists the reasons, including the above, why you decided to create unique elements instead of svg, please provide it. It could be the page numbers of your slides.

*1: That’s probably all the elements listed in chapter 5. However, there is another discussion of the tile element.

Second, Can you tell me why you need mapml instead of GeoJSON? If svg meets the requirements for the map, is it okay as a substitute for mapml?

P.S. It seems to me that the map element and layer element specifications (section 4) can be considered as another specification separate from the mapml specification (section 5).

The <feature> element was conceived as a semantic receiver for GeoJSON: the <properties> child would contain “regular”, styleable, linkable HTML that was intended as metadata for the feature, while the <geometry> element would contain OGC simple features geometries that have more semantic constraints than svg paths do (I think). We can discuss those constraints, but they’re related to real-world feature-ness I believe.

The GeoJSON model of arrays to describe these geometries has its own semantics, and the arrays can be transformed to SVG, WebGL, etc. by procedural logic (it is required actually). That’s great, because such procedural logic could also easily generate <geometry> values with very little change. However, I did not want to have the proposal rely exclusively on procedural logic to be supplied by Web sites.

In OGC testbed 15, we prototyped the rendering of MapML tiles, in which the geometries that were split by tile boundaries used <span class="noline"> ...</span>, so that in principle the sub-geometries that should not be drawn, or styled differently, could be targeted by CSS selectors. This worked quite well, except that the feature geometries had to be broken up and serialized as SVG paths with different DOM nodes representing the sub-parts, so that they could be targeted by CSS selectors.

That is a core reason: even though the HTML design principles say that not everything has to be modeled with deep semantic markup, we feel that targeting parts of geometries with CSS selectors is a very common need, even beyond the use case of hiding tile boundaries, and after the workshop, I feel it may have accessibility considerations as well.

So that is one reason to expose the geometry as semantic markup, but I think that future experiments could show that the best reason may be that geometries can encode links (<a href="..."></a>) in maps that can be used to federate map layers in the same way that HTML documents ‘federate’ web sites in a crawlable manner. And I also imagine that accessibility needs may demand the ability to mark up <geometry> parts without breaking the geometry integrity.

Finally, <geometry> as markup has been done before, in KML with some limited success and in GML with less success. Those two applications failed to deliver the styling and linking, and indeed the accessibility that I have mentioned above, mostly because they weren’t HTML, I think.

If you have a document that lists the reasons

There may be other good reasons, but I can’t think of them at this moment. I tried to make a thorough description of the proposal and it’s reasons here. It has taken some criticism for being too long already.

Second, Can you tell me why you need mapml instead of GeoJSON?

I think you mean <feature>, because <mapml> is proposed to be a document (root) element for the text/mapml media type, so that it can be referenced by <layer src="..."></layer> elements. So these are different things in the proposal. Please correct me if I’m wrong, but I answered what I thought the question was intended.

P.S. It seems to me that the map element and layer element specifications (section 4 2) can be considered as another specification separate from the mapml specification (section 5 2).

It used to be that way, but that was found to be an issue that complicated understanding the proposal as a whole, so we are moving towards a single specification at the current time. The intention is to eventually write the specification as a pull request to the WHATWG HTML specification, once we are ready with sufficient implementation experience, support, feedback etc.

@PeterR Thanks for the detailed explanation. As you can imagine I wish we could describe geographic information as SVGs.

If the basic structure of geographic information is what the geo industry considers to be a simple feature, and even if it doesn’t perfectly match the naming and semantics of each of the elements of the SVG, it’s still possible to work out a way to bridge the gap without increasing the complexity and size of the content too much. I feel. Because they are all vector data.

I don’t know how much the geo industry recognizes the value of svg, but the value of it being a vector data description format that web browsers can draw natively is good enough for me.

Incidentally, in the framework I’m developing, a mechanism for interconversion between geoJson and SVG elements is included, although it may be a bit sloppy.

1 Like