Add coordinates expressions in WebGL tiles

[Dolpic]

Add the expressions tileCoordX/Y and tileMaxCoordX/Y to tiles using WebGL. This allows testing for the position of the current pixel in style expression. For example, this can be used to handle computations with edges of tiles. WebGL shaded relief example has been modified accordingly, avoiding artifacts in the rendering.

This is a fix for the issue #15477.

[tschaub]

Thanks for the proposed changes, @Dolpic. I don't have time right now to invest in this, but I think it would be ideal if we could come up with a solution that was more straightforward from a user's perspective. Your solution does provide a lot of control and flexibility in expressions, but also exposes a lot of detail it would be nice not to have to think about.

Minor, but it looks like you may have changed line endings for the edited files.

[mike-000]

Testing for a tile edge in the example will have no effect. Attempting to access the value of an offset beyond the edge already returns the value of the nearest valid pixel as demonstrated by https://codesandbox.io/s/webgl-tiles-forked-glpjtd?file=/main.js For interpolation across tile edges to work the tiles must have a buffer. Even with interpolation disabled as in https://openlayers.org/en/latest/examples/pmtiles-elevation.html "flat" lines along the tile edges can be seen when zoomed in.

[Dolpic]

Thanks a lot for your feedback!

I changed the character lines to be the correct ones, sorry for that.

Regarding the solution in itself, I see multiple options :

• Buffering each tile, so that tiles overlap, and buffers are discarded upon rendering, as suggested by @mike-000.
  If we delegate this responsibility to the user, it comes with an additional cost of data processing. It would be nice if users could use their maps without such a process.
  If we implement this feature in OpenLayers, it would solve issue Artifacts in example Shaded Relief (with WebGL) #15477 but comes with additional complexity in tile handling and knowledge a user needs to acquire to apply a style on a layer. This would also require additional computation and network costs from the overlaps.
  From my point of view, it would be a nice parallel feature with different outcomes than layer styling, that could be used by users for which the proposed solution is not the right one.

• Have a way for a tile to include data from other tiles in their computation.
  This one would be the ideal solution, as it is not suited to a tile-based renderer approach. I suppose it would require massive changes and is not desirable.

• Expose the position in the tile, and let the user decide how to handle "border effects".
  I completely agree that this exposes a lot of details for the user, as mentioned by @tschaub.
  I think it would be counterintuitive to expose the UV coordinates from WebGL textures (between 0 and 1), that's why tileCoordX/Y returns the coordinate in tile pixels. This metric is already exposed to users through other functionalities of OpenLayers.
  Having these values exposed does bring flexibility to users, and doesn't bring any additional complexity for those who do not require this feature (someone not using these expressions should not be aware of anything new).

With these additional expressions, users can easily implement multiple kernel-based filters (slope, shading, contour detection, blur, etc.) without having to maintain overlapping tiles.
This would be a similar reading operator as "resolution" or "time" are already.

Currently, handling pixel position is the solution used in the example Shaded Relief that doesn't show the same artifacts as in its WebGL equivalent.

The following examples demonstrate a potential use case :
COG styling without this feature
COG styling with this feature
We can clearly see the edges of the tiles in the first example. In the second example, this issue is solved.

This can be achieved with a very simple modification in how shading is computed but requires to have access to the WebGL coordinates. It uses the same behavior as Shaded Relief to handle tile edges.

[mike-000]

For the example Nextzen's buffered tiles can already be used with no extra code or loading https://codesandbox.io/s/webgl-shaded-relief-forked-zfd8m7?file=/main.js (use the cloaked API key from https://openlayers.org/en/latest/examples/osm-vector-tiles.html for the live domain). In #13647 I found this endpoint to be less reliable than AWS. The same tiles could also be used in the canvas shaded relief example, but currently would not be suitable for ol-mapbox-style.