-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add <meta> element values found only in MapML, especially zoom, extent and projection #7
Comments
Need to agree/fix whether the meta name=tcrs or meta name=projection |
whatwg/html#2335 suggests that new E.g. <meta zoom=""> instead of: <meta name="zoom" content=""> |
OK, sounds good, thanks for finding that reference. My experience with these meta values is that they can become a second, or third source of truth, and the UA will need some rules on priority. But let's put that aspect on hold for when we determine exactly which meta variables we will need. zoom seems to be an obvious one. |
Related issue |
We've implemented the Individual content elements may not conform to this extent; for example a This comment is the documentation of the syntax of the implementation, until the spec can be updated. Please correct / comment if I get something incorrect or incomplete. The element requires a
An extent is characterized by 4 coordinates ( two coordinate pairs). In the above example, the coordinate pairs are: (3,4),(4,5). In the case where the coordinate system is scale-independent, for example pcrs or gcrs, the extent may omit the zoom=value parameter:
or
Note that the coordinate system (gcrs,pcrs,tcrs,tilematrix) of the extent is inferred from the first axis name encountered. If axes from more than one coordinate system are encountered, the extent will be ignored. |
The implementation of this is not perfect, because we rely on Leaflet for rendering at this stage. In doing so, we represent extents using L.Polygon, which in turn relies on L.LatLng. So, extents that "fall off the edge of the earth" do not work well, despite that they are defined in tiles, or easting/northing etc. We will need to implement an extent renderer, which doesn't rely on transforming points to latlng for display. |
This need was created by the inline features concept
The text was updated successfully, but these errors were encountered: