Note: This diagnosis and fix come from Claude Code. It makes sense to me, but I'm not deep enough in the JupyterGIS internals to be 100% confident. Feel free to close this if it's off-base.

Problem

When jupytergis-tiler is used inside JupyterHub, tile layers added via add_tiler_layer() are not rendered on the map.

In JupyterHub, each user's Jupyter server is served under a URL prefix such as /user/username/. The JupyterGISHandler is therefore registered at /user/username/jupytergis_tiler/(.*). However, tile URLs were hardcoded to /jupytergis_tiler/... without this prefix, so browser requests never reached the handler — JupyterHub had no route to forward them to the user's server.

The issue does not occur in standalone JupyterLab, where base_url is /.

Fix

gis_document.py

Read the JUPYTERHUB_SERVICE_PREFIX environment variable (set by JupyterHub for all single-user servers) to prepend the correct base URL when constructing tile URLs:

base_url = os.environ.get("JUPYTERHUB_SERVICE_PREFIX", "/").rstrip("/")
url = f"{base_url}/jupytergis_tiler/{source_id}/tiles/..."

When JUPYTERHUB_SERVICE_PREFIX is not set (standalone JupyterLab), behaviour is unchanged.

handler.py

The proxy handler now forwards the HTTP status code and the Content-Type header from the upstream tile server response.

Without this fix, errors from the tile server were silently swallowed (always returning HTTP 200), and stricter environments such as JupyterHub (which may set X-Content-Type-Options: nosniff) could refuse to render tiles without an explicit Content-Type: image/png.

Testing

• Tile layers render correctly in a JupyterHub deployment (with JUPYTERHUB_SERVICE_PREFIX set)
• Tile layers still render correctly in standalone JupyterLab (without the env var)
• Tile server errors are now surfaced with the correct HTTP status code