consider solidifying tilesource API as a prototype

mapbox / tilelive

fast interface to tiles with pluggable backends - NOT ACTIVELY MAINTAINED

BSD 3-Clause "New" or "Revised" License

532 stars 108 forks source link

consider solidifying tilesource API as a prototype #153

Open tcql opened 8 years ago

tcql commented 8 years ago

During some discussion in gis-devs slack, it was pointed out that not all tilelive Tilesource implementations have the full api (tilelive-mapnik implements getGrid, while tilelive-bridge does not. And API.md suggests that getGrid is standard for Tilesources).

It might be nice if we have a Tilesource function that stubs all expected methods on it's prototype, and rework existing Tilesources to inherit the prototype. This ensures that even if a source doesn't fully implement the Tilesource API, the stubs at least exist. I think this also solidifies expectations around what should be implemented by a custom Tilesource, and how to start building a custom Tilesource.

tmcw commented 8 years ago

(tilelive-mapnik implements getGrid, while tilelive-bridge does not. And API.md suggests that getGrid is standard for Tilesources).

I'd suggest that getGrid should not be part of the minimal tilelive API.

yhahn commented 8 years ago

Hmm, I understand the pains here. Some context:

Not a huge fan of JS inheritance as a way of enforcing a spec,
Tilelive "spec" is currently in somewhat of a discovery phase as the tile ecosystem has changed considerably since its inception. Per @tmcw's comment utfgrid's are a deprecated technology (replaced by vector tiles) and we've also seen more interfaces that require getTile inputs beyond z/x/y (retina? language support? other options?)

My take is to observe how our current generation of modules continue to adapt to the image => vector transition (with how raster tiles make it through a big question) and then to adjust our spec accordingly before looking to codify the spec further.