Opened 18 years ago
Last modified 18 years ago
#1663 new defect
[WMS Time] Change wms_time parameter for context 1.1.0
Reported by: | jlacroix | Owned by: | mapserverbugs |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | WMS Server | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
In bug 1581, we added support for map context 1.1.0. One of the enhancement was to support dimensions, just like time support. However for supporting multiple type of dimensions, we need a way to handle multiple dimensions. To support this, we can implement the same type of metadata that we have with the style. wms_dimension_%s_<param> where %s is the dimension name ("time" for example) and <param> is the context parameter This would add the following elements: wms_dimension_time_unitsymbol wms_dimension_time_units wms_dimension_time_uservalue wms_dimension_time_default wms_dimension_time_multiplevalues wms_dimension_time_nearestvalue This change would impact WMS server/client time support. The wms_time would become wms_dimension_time_uservalue on the client side. On the server side, the user could configure the output of the capabilities of the time dimension with the units, default and nearestvalue metadata. Of course the old parameter would still work, they would be the default value. They would all be grouped in a single function in mapows.c Assefa let me know what you think.
Change History (6)
comment:1 by , 18 years ago
blocked: | → 1581 |
---|
comment:3 by , 18 years ago
I also noticed that the WCS code use time related metadata like: wms_timeposition and wms_timeperiod. Do you think they should be changed too? Normally the MapContext is only on the client side, however we are beginning to configure the server related metadatas with mapcontext variables... So this would add to the list: wms_dimension_time_item wms_dimension_time_extent wms_dimension_time_position wms_dimension_time_period With of course the support of the old metadata names. Are you ok with that? Also the server configuration would be up to the user, if they specify manually in the mapfile different nearest values or units, it's up to them. If one day we support different ones, the parameters will be there.
comment:4 by , 18 years ago
Cc: | added |
---|
Steve, your advice on this with respect to WCS would be welcome. Basically the question is: should we, or does it make sense at all to try to unify the naming of time metadata accross all protocols (WMC, WMS and WCS) using a wms_dimension_time_... scheme or should we keep that local to WMC? Does WCS allow using dimensions other than time?
comment:5 by , 18 years ago
Sorry guys, I missed this one. Too much email these days. I believe WCS does support other dimensions besides time, z for example. I need to go back to the WCS code quickly (and the spec) to comment further. I'll try and do that today and add to this bug. Steve
comment:6 by , 18 years ago
Since there's more than one dimension in WCS, I think I'll revise my position. I'll hardcode the wms_time parameter in the context stuff and let alone the rest of mapserver. When we will have time to review all the dimensions handling in all MapServer, we will talk again. I'ss keep that bug open for the dimension revision though.
Note:
See TracTickets
for help on using tickets.