Implement a standard syntax for <meta> element contents

[prushforth]

Discussion in MapML spec land

[prushforth]

@ahmadayubi Before updating the MapML specification of this, we need to harden the concepts here a little bit (talk about them in writing, once satisfied, change the implementation, then the spec). Once we are satisfied we can refactor the syntax to match the suggested modern syntax, if desired. Currently, we partially implement the following <meta> syntax for various concepts:

    <meta name="projection" content="WGS84"/>
    <meta name="zoom" content="min=0,max=10,value=3" />
    <meta name="cs" content="tilematrix" />
    <meta name="bounds" content="topLeftVertical=2,topLeftHorizontal=3,bottomRightVertical=4,bottomRightHorizontal=3" />

The idea behind these is to provide a default value for the document as a whole, where real content doesn't specify (overriding) values. In some cases, I don't think it makes sense to allow content to override (e.g. projection).

It might be best if you didn't have to relate two separate elements to understand the content of one of them, e.g. in the above snippet, you need to understand that the coordinate system used in specifying the bounds is tilematrix. So maybe we should require a cs=tilematrix in the content of the bounds.

Come to think of it, maybe the name=bounds here should actually be name=extent, since bounds is a Leaflet-ism in which 'top' and 'left' etc depend on the orientation of the axes of the coordinate system.

That said, I believe it might still be useful to support a name=cs <meta> specifier, to determine what the default coordinate system in use in the document actually is. That way, we can use, for example:

<meta name="projection" content="OSMTILE">
<meta name="cs" content="pcrs">

to identify that <coordinates> contents are to be considered/processed as though in projected Mercator units (meters), whereas if we encounter:

<meta name="projection" content="OSMTILE">
<meta name="cs" content="gcrs">

we would process <coordinates> contents as though encoded in unprojected longitude,latitude / wgs84 coordinates.

Not to be too bikesheddy, but instead of camelCase values, I think we should stick with top-left-vertical etc., since this is the way we've specified those combined keywords in MapML.

[prushforth]

I think the implication of having a document default <meta name="cs" content="..."> is that we need to allow <feature>, (<image>/<img>) and whatever else has coordinates in text to have an attribute/property that specifies the cs in use by that thing.