Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Stamen #1811

Merged
merged 3 commits into from
Oct 26, 2023
Merged

Remove Stamen #1811

merged 3 commits into from
Oct 26, 2023

Conversation

ocefpaf
Copy link
Member

@ocefpaf ocefpaf commented Oct 4, 2023

Fix #1803

@@ -22,7 +22,7 @@ It enables both the binding of data to a map for choropleth visualizations
as well as passing rich vector/raster/HTML visualizations as markers on the map.

The library has a number of built-in tilesets from OpenStreetMap,
Mapbox, and Stamen, and supports custom tilesets.
Mapbox, etc, and supports custom tilesets.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Conengmo I wonder if we should leave OSM as default and remove everything else in lieu of xyzservices.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or we could make xyzservices a required dependency (pure python, no dependencies) and offload all of it, while giving users all available tiles by default.

Copy link
Member Author

@ocefpaf ocefpaf Oct 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is kind of what I was thinking. Making it a mandatory dependency and using it everywhere instead of having the templates for CartoDB, which was the last one to survive the API key revolution ;-p

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we agree :). If we want to do that, we should expose xyzservices via the query_name method as we do in geopandas or contextily, so you don't need to interact with xyzservices directly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think @Conengmo ? Should I start that in this PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really interesting thought! Can you give me a moment? I don’t want to rush my thoughts here. I’ll get back this weekend if that’s okay.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not in a hurry 😄
But b/c this is kind of a breaking change I would like to hold the next release to ship this with it, if we decide to implement it.

PS: the devil is in the details, we have tons of examples and docs that will request some re-writing. However, the disruption on end user won't be too big, I hope.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have tons of examples and docs that will request some re-writing. However, the disruption on end user won't be too big, I hope.

Why? Apart from Stamen maps not being available, which is nothing we can influence, it should be completely backwards compatible. Can you point me to examples that would need re-writing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on mobile now to check but my guess are the names we use in the tile keywords in the do docstring and examples. Those would change to match XYZ, no? I'd love for us to use the same as geopandas to reduce the cognitive load on users

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If exposed via query_name they should, with the exception of "OpenStreetMap", which needs to be mapped to "OpenStreetMap.Mapnik" but we can sort this one case internally I suppose.

@ocefpaf ocefpaf marked this pull request as ready for review October 4, 2023 16:35
Copy link
Member

@Conengmo Conengmo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good initiative this! We have to remove these indeed.

I agree with making xyzservices a requirement and removing the tile templating from Folium. It's a good idea. xyzservices is light-weight and uses leaflet-providers directly. That's great for Folium.

I'd like to make it a non-breaking change. So Map(tiles="openstreetmap") and Map(tiles="cartodbpositron") are still supported. I like the idea of using Bunch.query_name() for this. And then mapping "openstreetmap" to "openstreetmap.mapnik" internally for backwards compatibility.

In that way the API for Folium won't change from a users perspective. They can still provide a tileset name (which will then use xyzservices internally), or a url + attribution, or a xyzservices TileProvider object.

I wouldn't do the xyzservices adoption in this PR. Removing Stamen is something we have to do anyway, whether we adopt xyzservices or not.

I would suggest to include this change in a 0.15.0 release we do after this one is merged. So there are no issues with the Stamen deprecation before the end of October. Also there's some stuff on main waiting to be released, so I'd rather not wait for more changes before we release. Note that we also need a 0.7.0 release for Branca in tandem with 0.15.0 for Folium.

Then we can do the xyzservices adoption. Add some tests and make sure our use cases are covered.

Who should do what? How are you in time @ocefpaf? I have some time next week. I'm also planning on using Closember again to go through our open issues once more.

docs/getting_started.md Outdated Show resolved Hide resolved
docs/advanced_guide/custom_panes.md Outdated Show resolved Hide resolved
tests/plugins/test_minimap.py Outdated Show resolved Hide resolved
docs/advanced_guide/custom_panes.md Outdated Show resolved Hide resolved
@martinfleis
Copy link
Collaborator

Sounds good to me. Happy to be of any assistance with the xyzservices implementation if @ocefpaf wants to take a first look at it. You can check how we expose it in contextily or geopandas for inspiration.

Copy link
Member

@Conengmo Conengmo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've addressed my own comments. If the tests pass I'll go ahead and merge this. Then push release notes so we can hopefully get a release out before the end of the month.

@Conengmo Conengmo merged commit a838646 into python-visualization:main Oct 26, 2023
12 checks passed
@Conengmo
Copy link
Member

Conengmo commented Oct 26, 2023

@ocefpaf I updated the changelogs. Could you make a Branca 0.7.0 and a Folium 0.15.0 release please?

@ocefpaf ocefpaf deleted the remove_stamen branch November 6, 2023 17:05
@ocefpaf
Copy link
Member Author

ocefpaf commented Nov 6, 2023

Apologies for the late response but my past few weeks have been complicated.

I'd like to make it a non-breaking change. So Map(tiles="openstreetmap") and Map(tiles="cartodbpositron") are still supported. I like the idea of using Bunch.query_name() for this. And then mapping "openstreetmap" to "openstreetmap.mapnik" internally for backwards compatibility.

Agreed.

I wouldn't do the xyzservices adoption in this PR. Removing Stamen is something we have to do anyway, whether we adopt xyzservices or not.

Done ;-p

I would suggest to include this change in a 0.15.0 release we do after this one is merged. So there are no issues with the Stamen deprecation before the end of October. Also there's some stuff on main waiting to be released, so I'd rather not wait for more changes before we release. Note that we also need a 0.7.0 release for Branca in tandem with 0.15.0 for Folium.

Should I start the engines from branca 0.7.0 and folium 0.15.0? I can do both today.

Then we can do the xyzservices adoption. Add some tests and make sure our use cases are covered.

Who should do what? How are you in time @ocefpaf? I have some time next week. I'm also planning on using Closember again to go through our open issues once more.

I cannot promise anything b/c I'll be moving into a new place in November. If you are willing to do it please go ahead and don't wait for me. If you don't get to this, I will have some time reserved for folium in december.

@ocefpaf
Copy link
Member Author

ocefpaf commented Nov 6, 2023

@ocefpaf I updated the changelogs. Could you make a Branca 0.7.0 and a Folium 0.15.0 release please?

On it... I missed this comment while answering above.

@martinfleis
Copy link
Collaborator

I can do the xyzservices implementation

@Conengmo
Copy link
Member

Conengmo commented Nov 6, 2023

Thanks for making the releases @ocefpaf! I hope you are okay, and good luck with whatever's going on 🍀

I'll update the changelog to include the merges of today, and edit the release to include our changelog.

@ocefpaf
Copy link
Member Author

ocefpaf commented Nov 6, 2023

I'll update the changelog to include the merges of today, and edit the release to include our changelog.

Apologies, should've done that. I thought we dropped the changelog here in lieu for the auto-generated changelog in the release notes. (I did that in some projects and things are blurry to me now. Sorry!)

@Conengmo
Copy link
Member

Conengmo commented Nov 6, 2023

no worries at all :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Stamen tiles are deprecated
3 participants