You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 thatgetGrid
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.
The text was updated successfully, but these errors were encountered: