On 29/08/2014 04:09, precy wrote:
I have 4(sometimes 5) raster images and projected these using gdalwarp. I've
tried stitching these images using these commands gdal_merge.py -n 0
-a_nodata 0 -of GTiff -0 output.tif a.tif b.tif c.tif d.tif e.tif. The first
3 images was stitched and the last 2 ima
Sylvain Duclos,
Thanks.
And is there is simple way to automaticaly convert s-57 maps to tiled raster
images with specified scale? May be not following s-52 specs.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Convert-S57-to-image-with-S52-rendering-tp4987897p515
It's my recollection from a question I posted here a little over a year
ago that except for a few special cases, autoIdentifyEPSG only works if
there is an authority node providing the EPSG. Hopefully someone will
give you an authoritative answer. I believe GeoTools has the capability
to find the
Hi devs,
What is the correct way to extract the EPSG code from an OGRSpatialReferenceH ?
Currently I'm finding that the following works only for SRS of some images and
not others:
const char *charAuthType = OSRGetAttrValue(gdal.srcSRS, "AUTHORITY", 0);
const char *charSrsCode =
I have 4(sometimes 5) raster images and projected these using gdalwarp. I've
tried stitching these images using these commands gdal_merge.py -n 0
-a_nodata 0 -of GTiff -0 output.tif a.tif b.tif c.tif d.tif e.tif. The first
3 images was stitched and the last 2 images was also stitched, but they were
I have a byte GTiff dataset that has a nodata value of 0 according to QGIS.
However, when I load it using the gdal python API, I get this:
>>> ds= gdal.Open('cdl10lu83.tif')
>>> band=ds.GetRasterBand(1)
>>> band.GetNoDataValue()
-3.4028230607370965e+38
Also when I run `gdalinfo` I see the same n
Even and Andre,
> I want to start off by saying a big thanks to Blake for taking his time
> > to tackle what can only be a very difficult problem.
> > From what I can observe, the current discussion seems to be around the
> > boundary of who should be responsible for ensuring thread safety around
Was likely intended to be "Reply all"
-- Message transmis --
Sujet : Re: [gdal-dev] RFC 47 and Threading
Date : jeudi 28 août 2014, 19:20:01
De : Blake Thompson
À : Even Rouault
Even and Andre,
> I want to start off by saying a big thanks to Blake for taking his time
> > to
Even,
> Yeah, that why was I suggested the reverse ;-) But an automatic renaming
> should be doable.
> Another danger of keeping IReadBlock and making it now responsible of
> ensuring
> its thread safety is for out-of-tree drivers that wouldn't realize they
> need
> to change something as code wou