[gdal-dev] Specifying NODATA values for the TMS (mini)driver

[Homme Zwaagstra]

Hello,


I'm currently running a TMS tile server generating geotiff tiles from DEM data which I'm consuming with the GDAL TMS driver using an XML file along the following lines:


<GDAL_WMS>
    <Service name="TMS">
        <ServerUrl>http://localhost:8080/terrain/${z}/${x}/${y}.tif</ServerUrl>
    </Service>
    <DataWindow>
        <UpperLeftX>-20037508.34</UpperLeftX>
        <UpperLeftY>20037508.34</UpperLeftY>
        <LowerRightX>20037508.34</LowerRightX>
        <LowerRightY>-20037508.34</LowerRightY>
        <TileLevel>20</TileLevel>
        <TileCountX>1</TileCountX>
        <TileCountY>1</TileCountY>
        <YOrigin>top</YOrigin>
    </DataWindow>
    <Projection>EPSG:3857</Projection>
    <BlockSizeX>256</BlockSizeX>
    <BlockSizeY>256</BlockSizeY>
    <DataType>Float32</DataType>
    <BandsCount>1</BandsCount>
    <MaxConnections>50</MaxConnections>
    <ZeroBlockHttpCodes>204,404,500</ZeroBlockHttpCodes>
</GDAL_WMS>

This all works perfectly except for the fact that the responses interpreted as <ZeroBlockHttpCodes> are filled with a default value of 0. This obviously isn't great for elevation data :) Ideally I'd like to be able to specify a fill or NODATA value somewhere in the XML, something like:


<GDAL_WMS>

...

    <NoData>-9999</NoData>

or

    <FillValues>-9999</FillValues>

...

</GDAL_WMS>


The contents of a <NoData> tag might be a comma separated list for multiband rasters.


Would an enhancement request to support this be acceptable? Otherwise can anyone suggest any workarounds for the issue?


My current thoughts are that I could generate zero filled tiffs and return those instead of 404 responses, and wrap the TMS XML with a VRT that assigns an appropriate NODATA value. This is far from ideal however, as there are a lot of potential 404s and generating data for this is wasteful in terms of processing and bandwidth.


Best regards,


Homme

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180627/0f8797e1/attachment-0001.html>