Hi,
As it says in the documentation, when calling GDALDEMProcessingOptionsNew the
argument psOptionForBinay should generally be NULL. [
http://gdal.org/gdal__utils_8h.html#ac6e67c9ca37448286a6031e626e551ae ]
And that should be the case for applications that only has access to the GDAL
public
Hi List,
I'm working on a C# application using the GDAL C#-bindings (v2.1.2).
I have a (potentially) large single band GeoTiff (>100MB).
I need to use this raster file, apply a formula and save as a new tiff.
I already figured out I can use CreateCopy to create a copy of the input
raster.
Next I
Rutger,
Thanks, that did the trick.
-Steve
On 4/4/2017 6:15 AM, Rutger wrote:
Stephen Woodbridge wrote
On 4/3/2017 11:37 PM, jratike80 wrote:
Stephen Woodbridge wrote
Hi Jukka,
Ahh, good point, I always seem to forget that fact.
I have gotten the python code to add the new fields, but the
Stephen Woodbridge wrote
> On 4/3/2017 11:37 PM, jratike80 wrote:
>> Stephen Woodbridge wrote
>
> Hi Jukka,
>
> Ahh, good point, I always seem to forget that fact.
> I have gotten the python code to add the new fields, but the data is not
> getting written to the file.
>
> # open the shape
Hi all,
introducing (outing) myself as the coverage standard / WCS editor.
To avoid the problems that other standards have with axis order, coverages
contain the axis order explicitly, in the axisLabels attribute. Here an example:
http://www.opengis.net/def/crs/EPSG/0/4326";
*axisLabels=
