[gdal-dev] Negative NoData Value with Signed Byte Raster

[Jason Greenlaw - NOAA Affiliate]

Yes, I have used QGIS, and it works perfectly.  However, my requirement is
to create map services using ArcGIS Server, so unfortunately QGIS isn't an
option for this task.

Thanks,
Jason


On Thu, Apr 7, 2016 at 9:46 AM, Jerl Simpson <jsimpson at wxtrends.com> wrote:

> Just out of curiosity, have you tried using QGIS?
> It might solve the issue for you...or might just be a goose chase.
>
> Jerl Simpson
> V.P. Systems Engineering
> Weather Trends Internationalhttp://www.weathertrends360.com/
>
> This communication is privileged and may contain confidential information.
> It's intended only for the use of the person or entity named above.
> If you are not the intended recipient, do not distribute or copy this communication.
> If you have received this communication in error,
> please notify the sender immediately and return the original to the email address above.
> © Copyright 2016 Weather Trends International, Inc.
>
>
> On Thu, Apr 7, 2016 at 7:45 AM, Jason Greenlaw - NOAA Affiliate <
> jason.greenlaw at noaa.gov> wrote:
>
>> Trent,
>>
>> I am able to load the VRT in ArcMap, and while it does now recognize -128
>> as the NoData value, it is identifying the raster as unsigned byte despite
>> the <Metadata> section workaround given by Even, and thus does not properly
>> respect the NoData areas.  This is strange since it recognizes the original
>> GeoTIFF as signed byte.  I'm using ArcGIS 10.2.2, which may have something
>> to do with it.  Perhaps it's fixed with 10.3/10.4.
>>
>> I have used their Raster Functions before but have not played around with
>> the Image Analysis window - another reason to upgrade to 10.3+.
>>
>> Thanks for the tip,
>> Jason
>>
>>
>> On Wed, Apr 6, 2016 at 3:58 PM, Hare, Trent <thare at usgs.gov> wrote:
>>
>>> Jason,
>>>    VRTs work in ArcMap too - if that helps...? Also have you tried the
>>> powerful Image Analysis window. It is fairly flexible with output types
>>> (e.g. float, 8bit) for output at each functional step.
>>> http://desktop.arcgis.com/en/arcmap/10.3/manage-data/raster-and-images/rasters-with-functions.htm
>>>
>>> more:
>>> http://desktop.arcgis.com/en/arcmap/10.3/manage-data/raster-and-images/what-is-the-image-analysis-window.htm
>>>
>>> good luck,
>>> Trent
>>>
>>> On Wed, Apr 6, 2016 at 12:26 PM, Jason Greenlaw - NOAA Affiliate <
>>> jason.greenlaw at noaa.gov> wrote:
>>>
>>>> Thanks for the workaround and quick fix.  The VRT addresses the issue
>>>> on the data end.  Now it's only an ArcGIS problem :)
>>>>
>>>> Jason
>>>>
>>>>
>>>> On Wed, Apr 6, 2016 at 3:10 PM, Even Rouault <
>>>> even.rouault at spatialys.com> wrote:
>>>>
>>>>> Le mercredi 06 avril 2016 20:38:36, Jason Greenlaw - NOAA Affiliate a
>>>>> écrit :
>>>>> > Hello,
>>>>> >
>>>>> > I've run into a snag trying to assign a negative NoData value to a
>>>>> Signed
>>>>> > Byte raster.
>>>>>
>>>>> Jason,
>>>>>
>>>>> I've just pushed a fix for that in trunk (signed byte is a bit of a
>>>>> second
>>>>> class citizen as a data type in GDAL, hence the issues) to avoid the
>>>>> erroneous
>>>>> clamping. You're supposed to put negative values.
>>>>> You can workaround the issue by first creating a VRT by adding
>>>>>
>>>>>     <NoDataValue>-128</NoDataValue>
>>>>>     <Metadata>
>>>>>       <MDI key="PIXELTYPE">SIGNEDBYTE</MDI>
>>>>>     </Metadata>
>>>>>
>>>>> in <VRTRasterBand>
>>>>>
>>>>> and then gdal_translate the VRT as TIFF
>>>>>
>>>>> Even
>>>>>
>>>>>
>>>>> --
>>>>> Spatialys - Geospatial professional services
>>>>> http://www.spatialys.com
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>
>>>
>>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160407/a87b2dec/attachment-0001.html>