The control div is now an empty container that we can always append to and
remove from without having to worry about GMaps changing styles on it. It
also makes sure that the control is appended before Google's own
attribution control, so the "Report a map error" link will always be
clickable.
Simple and effective: As soon as a map has a Google layer, the whole map viewport is added as control to the GMap. As soon as no Google layer is visible on the map any more, the map viewport is appended to the map container again. With this change, OpenLayers strictly limits its GMaps integration to the GMaps API.
Also note that there are no css overrides for the attribution any more. Instead, controls can now be conditionally positioned differently for Google layer by using the .olForeignContainer selector.
When a vector layer is exported to an OWSContext document, we throw an
exception when the layer contains no features, and the geometries are to be
exported inside of an InlineGeometry-element.
This commit fixes this behaviour by exporting sth. like this in such cases:
<Layer name="vector" hidden="0">i
<ows:Title xmlns:ows="http://www.opengis.net/ows"/>
<InlineGeometry/>
</Layer>
minScale and maxScale values of 0 and Infinity do not make sense in
OpenLayers, but they are used in WMS GetCapabilities 1.1.1 to indicate
that there is no minScale or maxScale restriction. Assuming that the
capability values for minScale and maxScale are passed as config options
to a WMS layer, it is better to not set minScale and maxScale when 0 or
Infinity are found in the ScaleHint.
Format classes that define member methods need to be mixed into other
format classes that use their writers. In this case, methods from
Filter.v1 were missing so a test for Format.WPSExecute failed.
Using the Timeline tab of the Chrome Developer Tools, no significant
difference of Paint events can be observed when requestAnimationFrame is
used. So I agree with @elemoine that there is no need to introduce
asynchronous behavior here.
As suggested by @mpriour, it would be nice if the user could determine how
date values are encoded in literal elements. Extending this beyond date
values, we can provide an `encodeLiteral` method that can be overridden to
provide application specific behavior.
By adding serverResolutions to the WMTS configuration, it is possible to
use WMTS layers as overlays, even if the map or the base layer is
configured with different resolutions than the WMTS.
