Thoughts on API

[binste]

• Does it make sense to more directly integrate with Altair so a user could do mark_geoshape(tile=True) as proposed in Add support for tiles to geoshape mark vega-lite#8885? Once it's implemented in Vega-Lite, I think this is a great syntax but for this package I'm not sure as it would then change the type of the Altair chart to a layered chart. As a user I'd find this transition from alt.Chart -> alt.LayerChart unexpected. Also, this way it's clearer that the functionality comes from a separate package.
• Are add_tiles and create_tiles_chart good names? add_tiles is inspired from add_basemap in contextily
• Is it user friendly enough to pass an alt.Projection object to create_tiles_chart or better to expand the arguments, i.e. create_tiles_chart(scale=..., translate=...)?
• Instead of providing add_tiles and add_attribution functions, we could rely solely on create_..._chart functions and then the returned charts can be layered by the user themselves. For attribution, this would work and might simplify it. For add_tiles, we would always need to create the empty geoshape chart which is created in create_..._chart as else it is not a standalone working chart.
  • Way around this could be to introduce a new class TilesChart which only adds the geoshape layer when to_dict is called and if it is added to another chart it would loose that behavior (overwrite __add__).
  • TilesChart could also help with always keeping the attribution layer on top. There could be an escape hatch to convert it to a normal Altair class.

[mattijn]

Another thought: the create_tiles_chart almost feels like a mark_tiles, with specific mark properties like zoom, but without encoding channels.
I like the concept of TileChart too.