On Wed, 14 Aug 2019 at 11:02, Andrea Aime <[email protected]>
wrote:

> On Wed, Aug 14, 2019 at 7:49 PM Jody Garnett <[email protected]>
> wrote:
>
>> This proposal is targeted towards 2.16? We are days away from the RC
>> deadline ...
>>
>
Andrea did you have any feedback on this? I would expect hold off until
after freeze, wait a month and back port?

Same goes for the existing TIME and ELEVATION support for vectors, they
> could be done via CQL_FILTER. But CQL_FILTER cannot be discovered by a
> generic OGC WMS client, custom dimensions are instead part of the WMS
> standard.
>

That makes perfect sense, a real gap in the standards not having a good
overview of available values for attributes.

- Do you have an example of WMS 1.1 and WMS 1.3 snippet advertising custom
>> dimensions, an identical approach as for time
>>
>
> It's really the same as the exiting support for raster custom dimensions
> (WMS does not tell you if a particular layer is vector or raster).
> Here is an example taken from a GeoServer serving a raster data set with
> dimensions time, elevation and REFERENCE_TIME:
>

Thanks.

>
>
>> - there is a risk of conflict between dimension parameters
>> (population=100 in the demo) and other keys, perhaps something similar to
>> vendor options should be considered? Imagine if I had a dimension named
>> format, angle or env?
>>
>
> The WMS specification handle this by asking the client to add a "DIM_"
> prefix in the request, so if the dimension is called "REFERENCE_TIME" the
> client will add a parameter &DIM_REFERENCE_TIME=value in the KVP request.
>

Okay there is a small mistake in the proposal where &poluation=10000 was
used.

I am +1 on the proposal, +0 on including it in the 2.16-RC timeframe...
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to