ValueError: could not broadcast input array from shape (256,256,4) into shape (512,512,4) about contextily

[dmaldona]

I am having the same issue.

[martinfleis]

Thanks! I guess that we just cut a release with the new default and point users to new Stadia service if they want to keep using Stamen tiles.

[peanutfun]

Thank you, I did not realize I needed to register! Worked fine once I added the API key to the URL 🙌

For reference:

• https://tiles.stadiamaps.com/tiles/stamen_toner/{z}/{x}/{y}{r}.png gives the ValueError
• https://tiles.stadiamaps.com/tiles/stamen_toner/{z}/{x}/{y}.png gives the ValueError
• https://tiles.stadiamaps.com/tiles/stamen_toner/{z}/{x}/{y}@2x.png gives a plot with the warning tiles

Adding an API key from the Stadia Maps registration to any of these URLs provided the map as expected.

[ianthetechie]

@peanutfun Good to gear you got it sorted :) For anyone finding this issue wanting to know the full resolution, here are some details that I think should help.

We have been basically letting everything slide through since the deprecation announcement in July, but these tiles DO require an API key going forward. I'm not up on whether contextily has a way to manage API keys, but you can add it as a query string parameter like ?api_key=YOUR-API-KEY-HERE to your URLs.

@jorisvandenbossche has the right idea. Stamen never collected any information on who was using their tiles, so there was no way to contact everyone using the old Fastly URLs. The solution we settled on was a "warning" tile. Since ~1 week ago, all unauthenticated requests will now get these warning tiles pseudo-randomly. Currently it's ~every 16th tile on the map, and will increase as the old URL shutoff date approaches.

[martinfleis]

Because Stadia allows both domain whitelisting and API key authentication, passing the key requires a bit more than usual. See the snippet below.

import geopandas
import geodatasets
import contextily

nybb = geopandas.read_file(geodatasets.get_path("nybb")).to_crs(3857)

# get the provider object to adapt
tiles = contextily.providers.Stadia.StamenToner
tiles["url"] = tiles["url"] + "?api_key={api_key}"  # adding API key placeholder

ax = nybb.plot(alpha=.5)
contextily.add_basemap(ax=ax, source=tiles(api_key="my_key_here"))

[chudlerk]

Having the same issue outside of Jupyter notebook (using Spyder, personally). Same issue pops up even with the most basic example from the documentation.

import contextily as cx
import geopandas

data_url = "https://ndownloader.figshare.com/files/20232174"

db = geopandas.read_file(data_url)

ax = db.plot(color="red", figsize=(9, 9))
cx.add_basemap(ax, crs=db.crs.to_string())

  File C:\ProgramData\Miniconda3\lib\site-packages\spyder_kernels\py3compat.py:356 in compat_exec
    exec(code, globals, locals)

  File c:\users\kchudler\onedrive - research triangle institute\documents\hydromet_tools\storm_analysis_system\untitled1.py:18
    cx.add_basemap(ax, crs=db.crs.to_string())

  File C:\ProgramData\Miniconda3\lib\site-packages\contextily\plotting.py:129 in add_basemap
    image, extent = bounds2img(

  File C:\ProgramData\Miniconda3\lib\site-packages\contextily\tile.py:225 in bounds2img
    merged, extent = _merge_tiles(tiles, arrays)

  File C:\ProgramData\Miniconda3\lib\site-packages\contextily\tile.py:628 in _merge_tiles
    img[y * h : (y + 1) * h, x * w : (x + 1) * w, :] = arr

ValueError: could not broadcast input array from shape (512,512,4) into shape (256,256,4)

[martinfleis]

This seems to be an issue with Stamen Terrain tiles. The code from the @chudlerk's post fetches 9 tiles, but their shape are not consistent

(256, 256, 4), (256, 256, 4), (256, 256, 4), (256, 256, 4), (256, 256, 4), (256, 256, 4), (256, 256, 4), (256, 256, 4), (512, 512, 4)

See that the last one has double the resolution. I wonder if that is intention or some artifact of the transition to Stadia tile service. Maybe @ianthetechie will know?

In the meantime, you can use different tiles which do not seem to have the same issue, like cx.providers.OpenStreetMap.HOT or any other.

[jorisvandenbossche]

Can you try with a different provider source? For example cx.add_basemap(ax, source=cx.providers.OpenStreetMap.Mapnik)

I think this error is due because the default of Stamen is going to be removed (see #220), and it seems that they now changed the tiles to have a message, like:

for https://stamen-tiles-a.a.ssl.fastly.net/terrain/6/28/23.png. And this image has a size of 512x512 instead of 256x256 like the normal tiles.

[jorisvandenbossche]

I suppose they give you such a tile once every few or with some logic, so that we see only some of the tiles have this other size.

In any case, time to do a release so we have the changed default out?

[martinfleis]

In any case, time to do a release so we have the changed default out?

Ideally with #222 in and a fix for tests (not sure how, yet, probably by relaxing the checks or depending on more stable tiles).

[ianthetechie]

Hey, thanks for the summons @martinfleis.

See that the last one has double the resolution. I wonder if that is intention or some artifact of the transition to Stadia tile service.

That'd be a bit of an accident. We currently don't discriminate on the 1x/2x resolution on these error tiles since most maps display them correctly. As @jorisvandenbossche noticed, we started serving these "brownout" warning tiles yesterday for every 16th tile. We will increase the frequency as the month goes on. If you access the tiles using a Stadia Maps API key, you'll get the correct tiles.

Stamen announced back in July (https://maps.stamen.com/stadia-partnership/) that they were shutting down their Fastly CDN as it became too expensive. You will need an API key to continue access Stamen tiles. They remain free for non-commercial use, but commercial use and higher volumes require a paid plan. You can sign up for a key here: https://stadiamaps.com/stamen/onboarding/create-account.

[ianthetechie]

Sounds good. You know where to shout if you need some help with that (or just a quick once-over). You can find the updated URLs here: https://docs.stadiamaps.com/guides/migrating-from-stamen-map-tiles/#switch-your-tile-urls.

[galenseilis]

Can you try with a different provider source? For example cx.add_basemap(ax, source=cx.providers.OpenStreetMap.Mapnik)

I think this error is due because the default of Stamen is going to be removed (see #220), and it seems that they now changed the tiles to have a message, like:

for https://stamen-tiles-a.a.ssl.fastly.net/terrain/6/28/23.png. And this image has a size of 512x512 instead of 256x256 like the normal tiles.

Yes, using a different provider source provided an acceptable workaround.

[galenseilis]

Thanks! I guess that we just cut a release with the new default and point users to new Stadia service if they want to keep using Stamen tiles.

Sounds good. Thanks.

[peanutfun]

I still experience the original issue when switching to the new Stamen URLs at the Stadia service:

>>> contextily.add_basemap(plt.gca(), source="https://tiles.stadiamaps.com/tiles/stamen_toner_lite/{z}/{x}/{y}{r}.png")

ValueError: could not broadcast input array from shape (256,256,4) into shape (512,512,4)

It seems like the resolution of the tiles changed and contextily cannot handle that. Is there any workaround? I would like to keep using the Stamen maps with contextily.

[jorisvandenbossche]

It seems that new link is still giving the same "warning" tiles every x requests (eg I tried https://tiles.stadiamaps.com/tiles/stamen_toner_lite/3/1/1.png several times). Maybe that's because you didn't provide an API key? (if that's the case)

[jorisvandenbossche]

@ianthetechie would it be possible to generate a version of the warning tile at 256x256 ?

[ianthetechie]

Yeah, that's a good question @jorisvandenbossche. I'll look into that. Our current tile is 512 because all the major web renderers handle it fine, but we probably should offer a 256 version as well.