Skip to content

docs: Update empty-tiles.md with maplibregl support for empty tile content #3396

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

Merged
merged 2 commits into from
Feb 20, 2025

Conversation

andrewharvey
Copy link
Contributor

Since Maplibre GL v4.0.0 an empty response with 200 or 204 will be treated as a transparent tile

Motivation

update to documentation reflecting current support by maplibregl

Modifications

update to documentation

Verification

I tested this locally with

nc -c 'echo -ne "HTTP/1.0 204 No Content\r\nAccess-Control-Allow-Origin: *\r\n\r\n";' -l -p 8080 -k

# and

nc -c 'echo -ne "HTTP/1.0 200 OK\r\nContent-Length: 0\r\nAccess-Control-Allow-Origin: *\r\n\r\n";' -l -p 8080 -k

with the following

    const map = new maplibregl.Map({
        container: 'map',                                                                                                                                                                                                                      
        style: {
            'version': 8,
            'sources': {
                'osm': {
                    'type': 'raster',
                    'tiles': [ 'https://tile.openstreetmap.org/{z}/{x}/{y}.png' ],
                    'tileSize': 256
                },
                '204': {
                    'type': 'raster',
                    'tiles': [ 'http://localhost:8080/{z}/{x}/{y}' ],
                    'tileSize': 256
                }
            },
            'layers': [
                // bottom, drawn first
                {
                    'id': 'osm',
                    'type': 'raster',
                    'source': 'osm',
                    'minzoom': 0,
                    'maxzoom': 22
                },
                {
                    'id': '204',
                    'type': 'raster',
                    'source': '204',
                    'minzoom': 0,
                    'maxzoom': 22
                }
                // top, drawn last
            ]
        },
        center: [0, 0],
        zoom: 1
    });

no errors reported in the console and tiles from the 204 layer are drawn transparently.

I also reviewed the maplibre-gl-js source code, there are two code paths for loading tiles depending on how much the cache should be respected and both code paths seem to support a 200/204 response with no content.

Since Maplibre GL v4.0.0 an empty response with 200 or 204 will be treated as a transparent tile
@andrewharvey andrewharvey requested a review from a team as a code owner January 28, 2025 02:48
@blacha blacha changed the title Update empty-tiles.md with maplibregl support for empty tile content docs: Update empty-tiles.md with maplibregl support for empty tile content Jan 28, 2025
@blacha
Copy link
Member

blacha commented Jan 28, 2025

Hi @andrewharvey, thanks for this I did not know that maplibre had introduced 204 no content support!

Looks like it will soon be supported for terrain-rgb too! maplibre/maplibre-gl-js#5392

@andrewharvey
Copy link
Contributor Author

Ah nice, I didn't think to check the terrain sources too. In that case maplibre doesn't have complete support yet until that is addressed.

@blacha blacha enabled auto-merge January 28, 2025 03:29
@blacha
Copy link
Member

blacha commented Jan 28, 2025

to be fair when this documented was created, it was only looking at RGBA tiles :)

@blacha blacha closed this Jan 28, 2025
auto-merge was automatically disabled January 28, 2025 03:29

Pull request was closed

@blacha blacha reopened this Jan 28, 2025
@blacha
Copy link
Member

blacha commented Jan 28, 2025

whoops didnt meant to close this, I am just fighting with github actions, we don't get too many external pull requests.

@blacha blacha enabled auto-merge January 28, 2025 03:31
github-merge-queue bot pushed a commit that referenced this pull request Feb 19, 2025
### Motivation

There is a bug building `arm64` containers under `amd64` which is
causing segfaults, we currently use QEMU to cross compile the containers
which can be reasonably slow.

There is also another bug where external contributors cannot trigger
builds on pull requests to basemaps which leaves pull requests unable to
be merged. eg: #3396

The build process for containers was also split across two workflows
this merges the workflows into a single container building workflow.

### Modifications

Disable build pipelines for external pull requests as they do not have
access to our secrets, which causes them to fail.

Split container builds into a matrix build using arm64 runners for arm
containers and amd64 runners for x86 containers.

### Verification

Created a number of containers with `container` tag on pull requests and
pushed commits to the master branch on `blacha/basemaps`
@blacha blacha added this pull request to the merge queue Feb 20, 2025
Merged via the queue into linz:master with commit 3fa953c Feb 20, 2025
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants