Adding support for MVT source using WMS protocols

[xevxx]

We are loading vector tiles onto our map using the WMS protocol using code like below

 let formatMimeType = "application/vnd.mapbox-vector-tile";
 var sourceOptions = {
     url: 'your geoserver url'
     params: { 'TILED': false, 'FORMAT': formatMimeType },
     projection: 'EPSG:3857',
     strategy: ol.loadingstrategy.bbox,
     crossOrigin: "Anonymous",
     serverType: 'geoserver',
     transition: 0,
     hidpi: false,
     style: this.style
 }
var mvtFormat = new ol.format.MVT({
    featureClass: ol.Feature,
    layerName: '_layer_'
});
 var wmsTileSource = new ol.source.TileWMS(sourceOptions);
 var mvtVectorSource = new ol.source.VectorTile({
     ...sourceOptions,
     url: undefined,
     format: mvtFormat,
     tileUrlFunction: function (tileCoord, pixelRatio, projection) {
         return wmsTileSource.tileUrlFunction(tileCoord, pixelRatio, projection);
     }
 });
var layer = new ol.layer.VectorTile({
     renderBuffer: 200,
    source: mvtVectorSource,
})

The current implementation of MVTImageryProvider assumes that vector tiles are loaded through XYZ protocol.

To allow the WMS MVT to work I created a fork and created a new Provider based on a mix of the MVTImageryProvider and OLImageryProvider code. This is available to look at here - master...xevxx:ol-cesium:master.

The changes are:

• a new file provider MVTWMSImageryProvider merging functionality from MVTImageryProvider and OLImageryProvider
• Changes to core.ts to use the new provider if the source.urls is undefined in vectortiles type (may need a better method)

let isTms = true;
 if (!source.urls) {
   isTms = false;
 }

• added a new property 'olcs_extent' to push in the extent of the the dataset in 3857 - a lot of my data is not in 3857 and olLayer.getExtent() returns null in my config (even if I set it it would likely be in local projection)

let extent = olLayer.getExtent();
if (!extent && olLayer.get('olcs_extent')) {
  extent = olLayer.get('olcs_extent');
}
const rectangle = extentToRectangle(extent, projection);

Is this something that you would want to merge into the code base, if so please let me know and I can initiate a pull request (if there are any rules/ procedures I need to follow for these then please let me know and I will endeavour to (not a big github user)

Thanks for all the hard work on the library

[gberaudo]

Hi @xevxx, alias Mendoza ;),

Thanks for sharing your code, it may be useful to someone in the community.

The reason we request tiles in a grid is to take into accoung the heterogeneous levels of details of a 3D scene.
Contrary to 2D where the resolution is the same for every pixel in the viewport, these are different in 3D:

• we need precise data for what is close to the camera;
• less and less precise data for what is farther away (to not be overwhelmed with data).

I only looked quickly to your code so I am not sure exactly what it does.
In 3D, are you sending several requests to your geoserver MVT endpoint?
What the issue with using the TMS grid?

[xevxx]

Thanks for the reply, we are displaying user editable data in our 2d/3d map which can be updated / edited on the fly by users in 2d and had originally setup our app to use GWC TMS and had a cache invalidation of -1. (All edits are made on full vector features pulled for editing at the time) but when not editing data is displayed as MVT.

I'm pretty sure the MVT tiles are still generalised by GeoServer for the different zoom levels, same as TMS.

We were informed by the good fellows at Geosolutions that GWC TMS and with a cache invalidation of -1 was very inefficient setup and they recommended using the MVT as WMS method for this user editable data as shown above.

The changes to ol-cesium are my attempt to display these layers on the 3d map based on your existing code.

I had then extended the ol.source.vectortile to allow me to use the WMSGetfeatureInfo method to show the attribute info of the rasterized MVT features on the 3d Map.