Opened 10 years ago

Closed 10 years ago

#5584 closed defect (invalid)

Tile-based datasets are offset or drop pixels mid image

Reported by: mattmendick Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: 1.11.0
Severity: normal Keywords: block tile offset rounding
Cc:

Description

I am writing a raster driver which reads from a proprietary tiled dataset format (unfortunately I cannot share this publicly), but it behaves extremely similarly to the MBTiles format. My driver takes IReadBlock requests just the same as the MBTiles driver does given the block offsets. The tiles that it requests are pre-rendered 256x256 tiles stored in sets of files that can be accessed and streamed out directly. It also supports pre-rendered overviews given it's pre-rendered zoom levels, just as MBTiles does. Normally we use it to serve tiles out directly as most do with the MBTiles format and don't involve GDAL in that process at all, but I am now attempting to use our file format as a backend datasource for a WMS server through MapServer.

In order to use GDAL (as a data accessor for MapServer), I wrote a driver to read our dataset format, and have come across a strange issue. These issues not only happen with my driver, but with any tile-based format that I can find data for, such as MBTiles or the TMS WMS minidriver. At lower zoom levels (zoomed out) it seems that pixels are being dropped from the middle of the image, starting at the center. At higher zoom levels (zoomed in) there is an offset of several pixels. I don't know where this could be as I am not very familiar with the GDAL library as a whole, but there must be a rounding error at some point in the calculation of the extents of each of these tiles, which is getting exaggerated as one zooms in deeper.

To test this, you can use the gdal_wms.xml file (and in mapserver the test.map mapfile) to retrieve tiles from openstreetmap and overlay them on top of the standard tiles served out by that service. I've been using openlayers to display the openstreetmap base layer and then overlaying it with a 0.5 opacity wms layer being served from the gdal_wms.xml configuration and it will appear blurry to illustrate the difference between the tiles and the wms returned image.

Any help someone is able to give in finding this assumed rounding error would be very appreciated! I am continuing to look through the GDAL code, but have no found anything yet.

Attachments (4)

gdal_wms.xml (650 bytes ) - added by mattmendick 10 years ago.
GDAL WMS/TMS Minidriver config xml file
test2.map (2.7 KB ) - added by mattmendick 10 years ago.
mapfile
osm_tiles.png (237.2 KB ) - added by mattmendick 10 years ago.
OSM Tiles, looks right
osm_wmstms.png (237.5 KB ) - added by mattmendick 10 years ago.
OSM served with wmstms, missing some pixels

Download all attachments as: .zip

Change History (7)

by mattmendick, 10 years ago

Attachment: gdal_wms.xml added

GDAL WMS/TMS Minidriver config xml file

by mattmendick, 10 years ago

Attachment: test2.map added

mapfile

by mattmendick, 10 years ago

Attachment: osm_tiles.png added

OSM Tiles, looks right

by mattmendick, 10 years ago

Attachment: osm_wmstms.png added

OSM served with wmstms, missing some pixels

comment:1 by Even Rouault, 10 years ago

The errors occur when you are requesting at non-integral zoom levels, i.e. when subsampling or oversampling is needed ? Do you replicate that with gdal_translate of with a GDALRasterIO() call ? If so, that would be helpfull to indicate the exact arguments to use to reproduce.

comment:2 by Even Rouault, 10 years ago

"with gdal_translate OR with a GDALRasterIO() call"

comment:3 by mattmendick, 10 years ago

Resolution: invalid
Status: newclosed

Sorry for the long delay, but at the moment it now seems that gdal_translate is performing correctly, and that some combination of my OpenLayers + Mapserver test setup is causing the distortion. When I use QGIS things seem to line up properly. It does however seem that there is nothing wrong with GDAL, and I apologize for the wild goose chase!

I appreciate the response rouault, in any further postings I will most definitely post the specific gdal_translate steps to reproduce. Thanks for the tip and reminder.

Note: See TracTickets for help on using tickets.