OGC API Tiles as provider of tiles and MapML documents

We are seeing that OGC API tiles uses the same MapML tile templates. Actually the common OGC URI template can be expressed in MapML as:

<?xml version="1.0" encoding="UTF-8"?>
<mapml>
	<extent units="OSMTILE">
		<input name="tileCol" type="location" units="tilematrix" axis="column" />
		<input name="tileRow" type="location" units="tilematrix" axis="row" />
		<input name="tileMatrix" type="zoom" value="15" min="0" max="15"> 
		<link rel="tile" tref="https://.../tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}/" />
	</extent>
</mapml>

Actually we could make an extension of OGC API Tiles to suggest another Tileset metadata document that will make that a GET request to this endpoint \collections{collectionId}\tiles{TileMatrixSetId} negociating “text/mapml” as content type will return a mapml document pointing to the right collectionId.

This will completely connect OGC API tiles and MapML

For more details on the proposal, see the presentation done in the Maps for the web 2020 conferences in the second day of the first week called “Connection of the MapML initiative with OGC standards such as the new OGC API Tiles candidate or the old WMS”.

Linking to the slides:

• Connection of the MapML initiative with OGC standards such as the new OGC API Tiles candidate or the old WMS (slides)

In the talk you said that “MapML is the simplest way of adding geospatial information in web browsers”. I didn’t quite follow what led to this conclusion, and as compared to what. Can you elaborate here?

Thanks!

For a user, adding a map in a page will be extremely simple. Only a element in the page with a link to a MapML file. No need for JavaScript libraries, no need to know about APIs.

I think the use of the future tense “will” is great here, btw. That is the objective, indeed is to make authoring a map about the same level of complexity as <video>, <audio> or <img>. Nothing in that is meant to say that there are whole careers or more built on the complexities of authoring those media types, but it shouldn’t take a career in GIS to make a map on the Web. In fact, it should be perhaps the first thing taught to kids in school. So, it’s not only about saving money, although I imagine it could do that, but more about reducing barriers to entry.

I have concerns about things URL-like string, which are called templates in WMTS.

https://.../tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}/

Something like this. Can a document with such a string be called a hyper-document?

I feel this is incomplete as a hyperlink in the world of documents for web browsers. The implication is that by expanding this part({…}) based on some tiling rule, a large number of links will be generated. I could not find such a link-like description in other web browser standards.

What seems to me to be a rather close story to this is the video streaming by HTML VIDEO MSE, fragmented video files. Even there, there’s no mention of this kind of template that automatically expands the path of fragmented resources in a nice way. It seems to use its own javascript logic to specify the fragmented resources. It also seems that even the source fragment files are basically inline extracts. For example, an MPD file from MP4Box.

First, let me say that URI Template is a IETF standard: https://tools.ietf.org/html/rfc6570

Said that, I sympathize with what you said. we should not use href for something that is not a URI. In MapML the use of “<input” to define the variables in the URI template partially addresses of your concern. In the OGC API Tiles, the use of OpenAPI should clarify the meaning of the URI variables and, in principle, they are described there.

Still your concern persists. We are using a href for a this that is not a URI but a template. Actually, in MapML tref is used instead of href. In OGC API there will be a templated=true to tell the reader that the URL is not completed.

I have complained about the use of “link href” for tamplates in the OGC but the results of the discussion converged to worse solutions and I’m now trying to avoid the issue.

As I described in my paper, I think it would be more flexible and compatible with web browsers to consider a mechanism to generate URLs for freely designed tiles with short javascript.

As such a mention was made on day one, tiling is widely used in areas other than maps. But the attribute value “OSMTILE”, which seems to imply the expansion rule of the resource group of map tiles, seems to be dedicated to the map.

Supplemental.

As I showed in my paper, in-line expanded tiling can be easily described within the current browsers’ specifications. And in some cases, this kind of in-line expanded tiling even has an advantage over the equality divided tile pyramid with sequence functions that you might expect. Moreover, you can build an equality divided tile pyramid by making good use of those inline-expansion tiling features and piece of javascript code.

So, I think it would be a desirable standard to have a mechanism that can support various tiling logics according to the current browser specification as a basis, and to put a mechanism for the equally-divided tile pyramid on top of it.

Also, as the IETF document says about the template, it is something that changes to a URL depending on the expansion of the variable, so it would be essential to explain the variable.

In the example above, it would be {tileMatrix}, {tileRow}, {tileCol}. The descriptive information about how the variables are created includes the attribute values of the three input elements and the special keyword "OSMTILE" for the extent element. But to understand the tiling logic behind it, you will surely need to decipher that OpenAPI thing you pointed out. However, it seems to me that asking the browser to understand it is a challenge. Rather, as I’ve shown in my sample, a few lines of javascript code making the tiling logic explicit will allow the browser to interpret it naturally. This is similar to the problem of data to describe services (GetCapabilities), which can be seen in WMS and others, and which I pointed out in the paper.

I believe so; I wondered about this for a long time, but the clue I needed about hypertext, and URL templates, is not so much the syntax of the strings, but how the variables get their values. In the MapML proposal, as in HTML, server variables get their names from the <input name> attribute. In the MapML proposal, the values get their value automatically, based on the <extent> requirements. This mechanism allows the server and the client to be decoupled, or coupled indirectly, through the media type.

Per Roy Fielding:

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations.

Here’s the video of Joan’s presentation on this topic at the Maps for the Web workshop. Thanks @zcorpan for already posting the link to the powerpoint slides.

The live chat comments during the presentation were integrated with the spillover from @ghobona-ogc’s presentation, OGC (geospatial standard) APIs for web use

This thread is related to the mapml tile description.

Also, following posts appears to be related to the tiles.