-
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
Specify <input type="datetime"/> or datetime-local or datalist-based values of date-times. #12
Comments
WMTS supports different dimension as well. In the WMS capabilities it is possible to specify a list of values or an interval and a period. In WMTS capabilities only a list of values per layer is specified. In other discussions we have introduced the idea of
|
I think we need to be able to specify inputs within the extent element which are presented to the user. My current idea is that they could be displayed in the layer control under the layer entry in a " folder" or other way to allow them to be interacted with when necessary, but who's value will be used by the templates on pan or zoom (when retrieving content). The "folder" idea can be seen in the layer control, in which I am hiding a (hard-coded) opacity slider http://geogratis.gc.ca/api/beta/mapml/en/cbmtile/cbmt/ but I was thinking that we could designate this as the "abstract" way to accommodate other inputs that could get input from the user, like a datetime or band as you suggest, other dimension value. What might be cool is to think of a CSS way to animate that value. I have no idea if that is possible. |
WMS supports different dimensions, including "time". Need to allow MapML authors to include <input type="datetime"/> which supports a (defined subset of ISO 8601). Suggest that min/max/step attributes enable user input in either local or UTC, and with increments defined by
@step
.Identifying how to implement the MapML
<input type=datetime.../>
in HTML+ JS should be considered, since HTML<input type=datetime>
is deprecated and<input type=datetime-local>
might not be completely appropriate since some / many WMS would have an associated UTC time parameter that would have to be translated from a local to UTC time value for extent submission.The text was updated successfully, but these errors were encountered: