Indexed vector sources

[tmcw]

Style, context, polish

• @chelm is there any git history for the initial development on this branch?
• demo/mapbox-gl-dev.js and demo/streets-mobile.json probably shouldn't be checked in
• esri- files follow a dashed naming convention that diverges from the underscored naming convention of the rest of the lib
• esri- code needs JSDoc strings like the rest of the lib
• esri-tile-pyramid differs more in functionality than proprietariness to the TilePyramid code, and it is exposed via GL styles as indexedVector: should it be titled IndexedTilePyramid instead?
• The new tile pyramid contains a lot of code verbatim from the existing one: parts in common should be unified by inheritance or modularization.

indexedVector tech

• Are there any benchmarks or tests that have informed your decision to have an indexed tile pyramid? I can imagine there being a performance benefit, but would prefer concrete numbers to point to. Also, is the avoidance of 404s currently commented-out?

merge blockers

• Tests
• vector-tile-js dependency needs open-source release Introduce the concept of an indexed vector tile  Esri/mapbox-gl-js#1 (comment)
• mapbox-gl-style-spec dependency needs open source release

---

High-level there are three outcomes:

1. indexedVector is a performance optimization. If it can't be confirmed as an improvement, then we may not accept it.
2. If indexedVector's performance wins are clear-cut then it's possible we'll accept it as a default and integrate it into v8 rather than having two ways to load vector tiles
3. For routes in the middle, we'll help get this branch landed

---

/cc @chelm @jcardonadcdev @ycabon

[tmcw]

This and the rest of the new functionality needs JSDoc documentation information to match the rest of mapbox-gl-js.

[tmcw]

Could this be re-titled IndexedTilePyramid to match its difference in functionality?

[chelm]

I've removed the concept of "indexedVector" for now, and all new files (esri-*) and datasources that were originally in this branch/PR are gone. In its place I've modified 5 files (in each very subtly). Will call each change out separately below.

[chelm]

@tmcw Thanks for starting this. The intention of checking the original code in (all the esri-* files) was to have a temp reference to how the original code was changed. I'll remove it since what I've done here is actually remove the concept of an "indexedVector" and have changed the behavior of the existing "vector" data sources.

I'll explain the changes better with line notes, and will sync the PR to remove unneeded cruft.

[chelm]

This is the entry point for the difference in behavior. If an index exists (as a url) on the data source "tileJSON" the index gets requested. The returned index is added to the tile pyramid.

[chelm]

Just to comment on the status here: The team inside Esri is focusing on cooking up some benchmarks on using a tile index across our stack. This will help us understand the impact of the index on tile generation (less tiles) and the impact at render time (data clipping vs requesting/rendering very small tiles). It may be some time still, but everyone is eager to keep this moving forward.

[odoe]

Here is a gist that discusses the concept of the Indexing of Vector Tiles and the justification for Clipping.

https://gist.github.com/odoe/ce6a150658526901ef27#file-vector-tile-pr-md

cc @tmcw @ycabon @jcardonadcdev

[ycabon]

related PR mapbox/vector-tile-js#37

[jcardonadcdev]

Tests used to compare processing times for indexed tile vs. non-indexed tile - https://github.com/jcardonadcdev/vt-performance-tests

[tmcw]

The Esri side of this fork hasn't been updated since November 2015, and Mapbox GL JS has changed massively since then. It doesn't look like there are any active branches on the Esri project anymore.

Happy to take a look at an updated branch that resolves some of the initial issues outlined in this PR! Closing this specific PR as stale.

[chelm]

😞