developmentseed / lonboard

A Python library for fast, interactive geospatial vector data visualization in Jupyter.
https://developmentseed.org/lonboard/latest/
MIT License
628 stars 31 forks source link

[BUG] Layer Attribution Option #545

Open wildintellect opened 4 months ago

wildintellect commented 4 months ago

Context

What results were you expecting?
Some external layers require attribution as part of their licensing and terms of use. Many mapping libraries implement this as an attribution key on a layer definition that becomes a rendered over the map static text (sometimes HTML is supported).

BaseMap Layers might already have this specified in their style json, but will likely come up with many layer types particularly BitMapTileLayer where an external XYZ tile service is used. https://maplibre.org/maplibre-style-spec/sources/#attribution https://maplibre.org/maplibre-gl-js/docs/API/classes/AttributionControl/

This may not be a critical feature for users viewing their own notebooks, but will be an issue as they shared rendered notebooks or export images.

kylebarron commented 4 months ago

This is somewhat related to ideas I've had about letting users add to the underlying Maplibre map, e.g. through custom basemap styles https://github.com/developmentseed/lonboard/issues/494. But there's also a question of how tied Lonboard should be to Maplibre. It makes some things like this simpler but also makes other things harder, because tying us to maplibre ties us to Web Mercator

vgeorge commented 3 months ago

In #561, we fixed the styles for the MapLibre attribution control and added the custom_attribution parameter to the Map class to allow passing a custom attribution. However, we still need to:

prusswan commented 2 weeks ago

This is somewhat related to ideas I've had about letting users add to the underlying Maplibre map, e.g. through custom basemap styles #494. But there's also a question of how tied Lonboard should be to Maplibre. It makes some things like this simpler but also makes other things harder, because tying us to maplibre ties us to Web Mercator

Which other projections do you plan on supporting that is not web mercator? If you are considering broader support in the form of WMTS, there is OWSLib (not sure how well it will work with an interactive plot). On the JS front, OpenLayers has comprehensive WMTS support but it is probably easier to add Lonboard functionality to OpenLayers than the other way around.

kylebarron commented 1 week ago

deck.gl can render cartesian coordinates, so in principle we can render data in any coordinate system. We'll only be able to provide basemap data via Maplibre in Web Mercator, because Maplibre only supports Web Mercator. But we could have some minimal context information (country boundaries?) in other projections, to render under the data to give some context.

I've never used OpenLayers and I don't see us integrating with it.

prusswan commented 1 week ago

deck.gl can render cartesian coordinates, so in principle we can render data in any coordinate system. We'll only be able to provide basemap data via Maplibre in Web Mercator, because Maplibre only supports Web Mercator.

For data in non-standard projections that need a basemap overlay, you can consider supporting WMS data layers (which supports fetching dynamic tiles by bounding box and crs). This is not very different from the current BitmapTileLayer which works for XYZ tilesets (which could be generalized into WMTS but that is substantially more work).

kylebarron commented 4 days ago

I think in the near term, if we supported non-web mercator we wouldn't try to support basemaps.