Syntax and semantics of <meta name="projection" content="...">

[prushforth]

When parsing MapML documents without context, we can discover features and tiles. We call these "static", because they are not requested or returned from a server by means of a URL template, which we call "templated" when discussing. When the document contains <feature> elements, we require a way of determining what the coordinate system is used for encoding in their descendant <coordinates> elements, and consequently how and whether they should transformed for rendering.

By default, we think we should (be able to) assume that the coordinates values are encoded in the gcrs - geodetic / geographic coordinate reference system associated to the projection / TCRS, in longitude-latitude coordinate order.

We need to devise a <meta> syntax and associated semantics to be used to describe or identify the default or base crs used for coordinate encoding when the above assumption should not be true, for example when the author has content already encoded in pcrs coordinates and does not wish to or does not have the ability to transform the coordinates into gcrs encoding. This is most important for rendering "static" document content in which there is no request spatial coordinate / zoom level context from which to deduce the coordinate reference system, or for content in templated request-responses for which the service wishes to explicitly specify the crs being used in the response (see Background, below).

Possible options

1. <meta name="projection content="name=APSTILE,cs=pcrs">
2. <meta name="projection" content="APSTILE"> \n <meta name="cs" content="pcrs">

Thoughts?

N.B. We actually have code currently that supports the convention. Once we get decided on the semantics necessary, we'll change all the code over to the recommended WHATWG syntax for new meta variables.

Background

Our current idea for the <tile> element is that it have an optional? zoom attribute, in addition to its mandatory row and col attributes. Taken together, these identify how and where to render the tile feature or its contents. Worth noting is that when requesting tiles from a server via a <link rel="tile" tref="..."> template, there is no zoom, row or column metadata for the response except that understood by the client in the request context; a png or what-have-you that is returned from such a request is tied to a particular zoom and location without ambiguity by its request context.

In a document that contains <tile> elements, we've established that we need the zoom attribute for a tile, to tie the tile into the tile matrix in which it fits, so that a single document may contain tiles from different zoom levels. We call this "native" zoom; the zoom level of the tile in its native server habitat. We have specified a proposed meta element that allows the author to describe the min and max zoom levels to which the tile may be scaled, as well as the (potentially default) native zoom of the document, both smaller and larger, by means of <meta name="zoom" value="min=j-n, max=j+m, value=j">, where "value" identifies the (default) native zoom of tiles that don't actually carry a zoom attribute.

We believe the same zoom level considerations, including a zoom attribute could and should apply to <feature> elements, especially those parsed in "static" documents.

One aspect that requires more discussion for features than it apparently does for tiles, is the coordinate system in which the coordinates of the feature are specified. For tiles, it seems "obvious", or at least more or less hard-coded, that the coordinate system is "tilematrix", and the location of tiles is specified by their row/col attributes, as well as their zoom as described above.

Features, by contrast, have a <geometry> child element which contains one or more child <coordinates> elements. The coordinate values enclosed by the latter may be, and commonly are specified in either gcrs OR pcrs coordinates. (Aside: Could /might they in future be encoded in tcrs coordinates?)

When requesting content from a server (a "templated" scenario), the client has to fill in the parameters of a request, using a URL template into which it substitutes input variable values. In doing so, the 'context' of the request is established: the zoom level is defined, the 2d extent of the request is established, and especially, the coordinate system in use by the input variables is assumed to be the coordinate system of the response, whether the latter include tiles, features, images, all or none of the above.

[Malvoz]

Once we get decided on the semantics necessary, we'll change all the code over to the recommended WHATWG syntax for new meta variables.

I'm not 100% sure it's safe to switch to the recommended syntax outside of specs/browser implementations, see issue relating to future web compatibility considerations: #174.