Raster bleeding and poor geolocation with Pixels of Unusual Size

[JosephTRichardson]

Following up from the problem I reported a month ago with large polygons rendering poorly -- our problem continues to be finding the best way to represent the coverage area of large datasets on the globe. We decided to try writing a simple raster of the coverage area and loading that as an image layer in osgEarth. To reduce the file size as much as possible, I burned a raster of 1 pixel per tile -- in the case of DTED0, that's 1-degree square pixels. osgEarth did not handle that very well.

There were three issues with that:

1. Only one half of the raster renders at once, or one half of the globe randomly disappears:
   
   Rotating the globe, the other half sometimes reappears. Curiously, we discovered that if we force the bounds of the raster to the world bounds (-180, -90, 180, 90), it renders better on the globe, but that's not an ideal solution.
2. The pixels bleed terribly. This is a single pixel-tile:
   
   This is improved slightly by turning on the alpha color filter:
   
   But that renders poorly when you zoom in, with parts of the tile disappearing:
   
3. Far most seriously -- the geolocation of the pixels is poor. This is the bounding box of the area, over where the pixel actually renders:
   
   Naturally, this can cause some serious problems in representing the coverage area of a dataset.

If we increase the resolution of the pixels, they both render better with less bleed, and are geolocated better. For example, 2x2 pixels, resolution ~0.5 degrees):

3x3, resolution ~0.33 degrees:

4x4, resolution ~0.25 degrees:

5x5, resolution ~0.20 degrees:

With each of these resolution increases is a corresponding file size increase when rendering the coverage of a global dataset. The ideal solution, in the first place, would have been a polygon rendering correctly. Since the 1-degree pixels don't render very well, we will have to find a median between rendering quality and file size. Do you have any tips on improving this?

Here is a zip containing both the global coverage rasters for pixel sizes from 1-degree up to 0.2 degrees, and sample individual tiles.
Pixels_Of_Unusual_Size.zip

[JosephTRichardson]

Also note this strange artifact at 0° longitude. This strip of tiles is missing from DTED0, but that's not the problem. Rather than a single gap, osgEarth displays a big gap and a little gap that isn't (as far as I can tell) present in the raster:

[gwaldron]

Hi Joseph,
Thanks for the screenshots and the data files. Some of these are mishandling of the input data, but some are just configuration issues.

Update: We pushed a bug fix to resolve the missing data and some sampling problems.

Regarding the "one pixel" GeoTIFFs:

OSGEarth renders GDAL imagery to textures of finite size so it can display these on the globe, and by default it tries to converse memory and performance with approximation and downsampling. Zooming in close to Pixels Of Unusual Size like this will act "pathologically" because OSGEarth is trying to project exact geospatial coordinates onto relatively low-resolution (256x256px) tile textures.

You can mitigate this behavior by forcing the terrain engine to render higher-resolution levels of detail, and by asking for nearest-neighbor sampling on your GeoTIFF:

<gdalimage>
    <max_data_level> 19 </max_data_level>
    <interpolation> nearest </interpolation>

Regarding the Blurry Edges:
This is a function of hardware filtering. By default it is interpolating over a large area using LINEAR filtering, but you can override that as well:

<gdalimage>
    <mag_filter> 19 </mag_filter>

Hope this helps.