Hi Maning-
> I tried to decompress the kmz nd converted the doc.kml. ogr2ogr did
> not convert the kml (for good reasons) because it is a mixture of
> placemark, polygons and lines
This is a known limitation of the current driver. I would suggest rearranging
your data into layers comprised of onl
Frank,
I've noticed some issues when using /vsimem/ to open a VRT dataset (among other
formats). The code usually fails @ GDALClose or FlushCache, when the dataset
tries to perform a VSIMemFile::SetLength, and ultimately a realloc. Many
formats I can only VSIUnlink, and don't try to close the
hi list,
RSAT2's NITF product comes in "imagery_##.ntf" and "product.xml"
gdalinfo output for these two are listed below.
Georeferencing is off between the two files (their corners don't match
using OpenEV).
Q1: Is it true that imagery_##.ntf uses affine transform (see
GeoTransform tag), and pro
2009/6/25 Mateusz Loskot
> Jorge Arévalo wrote:
>
>> I have a question: What's the best way to test a new driver's code? I've
>> loaded this TIFF file into PostGIS using gdal2wktraster.py:
>> http://rapidfire.sci.gsfc.nasa.gov/subsets/?subset=USA1.2009168.terra.2km,
>> and I think that I can simp
Bryan Keith wrote:
Hello,
I'm using BuildPolygonFromEdges in ogr in an attempt to take some lines
and convert them to polygons. For a number of my sets of lines
BuildPolygonFromEdges fails. I think this is because the lines aren't
closed. Is there a way to put a tolerance into BuildPolygonFro
I was wondering if I should file a bug report for this. I noticed that the
ENVIDataset class reads the RPC information from an ENVI .hdr file and places
the values in metadata objects prefixed with "RPC_" off of the default domain.
It was my understanding they shouldn't have the prefix and shoul
Hello,
I'm posting this a second time because I see that by replying to an older
gdal-dev message, my first message was put in that thread by some e-mail
clients that sort threaded messages. Sorry for the repeat.
I'm using BuildPolygonFromEdges in ogr in an attempt to take some lines
and convert
Jorge Arévalo wrote:
I have a question: What's the best way to test a new driver's code? I've
loaded this TIFF file into PostGIS using gdal2wktraster.py:
http://rapidfire.sci.gsfc.nasa.gov/subsets/?subset=USA1.2009168.terra.2km,
and I think that I can simply do gdalinfo PG: to test if my dr