Improve Java decoding benchmark

[springmeyer]

Context

The Java decoding benchmark compares the speed of MLT decoding against two different libraries implementing https://github.com/mapbox/vector-tile-spec:

• https://github.com/ElectronicChartCentre/java-vector-tile
• https://github.com/sebasbaumh/mapbox-vector-tile-java

Problem

Both vector tile libraries are doing extra work that is not representative of what Maplibre needs.

Maplibre needs:

• "Lightweight layers": decoded layers that store offsets to features and only decode features when accessed by layer.feature(idx).
• "Lightweight features": decoded features containing just an id, extent, and properties only
• Then, as needed, Maplibre will call a function on those features called feature.loadGeometry() to on-demand, fetch a two-dimensional Array<Array<Point>> representation of geometries.

Rather what the Java vector tile libraries do are:

ElectronicChartCentre/java-vector-tile

• Creates a feature iterator when a layer is parsed. This is less work than fully decoding all features at Layer creation but does not allow skipping decoding of features that are not needed
• Decodes the geometry at Feature creation (rather than deferring geometry decoding to when needed)
• When decoding the geometry, a full JTS geometry is allocated

sebasbaumh/mapbox-vector-tile-java

• Reads all geometries of all features of all layers at once and reads geometries into JTS geometries

Solution

We need to correct the Java benchmarks to compare against MVT decoding that is representative of what Maplibre expects.

[springmeyer]

MVT decoding that is representative of what Maplibre expects.

@mactrem here is a library in java that can be used to compare against: https://github.com/springmeyer/vector-tile-java. Let me know if you have any questions.