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 jlacroix, 18 years ago

blocked: 1581

comment:2 by assefa, 18 years ago

Julien,

 If you do these changes, here are the other metadata that you might want to
change for consistency :
   - wms_timeextent
   - wms_timeitem
   - wms_timedefault

 Also notes :

   - If the value of  wms_dimension_time_units is diffrent from the ISO8601, It
can not really be used in the capabilities since mapserver won't be able to
support it
   - wms_dimension_time_nearestvalue is also not supported so It should always
be set to 0 in the capabilities. Some issues might arise with the other
parametsrs. Just make sure to consider it.

  Beside that I don't see any problem.

comment:3 by jlacroix, 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 dmorissette, 18 years ago

Cc: steve.lime@… 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 sdlime, 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 jlacroix, 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.