-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Remove Stamen #1811
Conversation
@@ -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. |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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. |
There was a problem hiding this 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.
@ocefpaf I updated the changelogs. Could you make a Branca 0.7.0 and a Folium 0.15.0 release please? |
Apologies for the late response but my past few weeks have been complicated.
Agreed.
Done ;-p
Should I start the engines from branca 0.7.0 and folium 0.15.0? I can do both today.
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. |
On it... I missed this comment while answering above. |
I can do the xyzservices implementation |
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. |
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!) |
no worries at all :) |
Fix #1803