Hi Elk,
The Project method (and several others) present in GDAL sinvce 1.11, but
there is no binding to python yet.
About dates/releases when it'll be coded - hard to say, maybe somebody
provide a patch with such functionality.
Best regards,
Dmitry
16.05.2014 00:26, Ochs, Elke
Hi Andre,
The solution you proposed is something special. In common case this is
library responsible to solve such situation.
Following you logic, the gdal have to deny using global environment
variable GDAL_DRIVER_PATH and require that each developer set this
variable manually in code or
Hi Even, thanks.
A new run ended with the mentioned errors and a warning about a bad
polygon.
I thought it was a bad sqlite because QGIS couldn't load it, but ogrinfo
and ogr2ogr work well with it (I could convert to shapefiles).
giovanni
2014-05-15 20:06 GMT+02:00 Even Rouault
Solved the mistery :)
Osgeo4W's GDAL seems to not have splite, so the output SQLite db wasn't a
spatialite db.
giovanni
2014-05-16 10:12 GMT+02:00 G. Allegri gioha...@gmail.com:
Hi Even, thanks.
A new run ended with the mentioned errors and a warning about a bad
polygon.
I thought it was a
Hi list,
I'm a little disappointed because I have hoped to find in version 2 a
reinforcement (unification) of the semantics of operations against the reported
capabilities (cf OGRLayer.TestCapability)
For exemple, if I take the function OGRLayer.SetFeature (OGRFeature *
poFeature) which is
Even,
I think that RFC 36 should be included in your list of
related RFCs and should be reconsider for adoption since the unification
would make the probing even more expensive.
Regards,
Ivan
From: even.roua...@mines-paris.org
To: gdal-dev@lists.osgeo.org
Date: Thu, 15 May 2014 20:47:32
Hi Nicolas,
Hi list,
I'm a little disappointed because I have hoped to find in version 2 a
reinforcement (unification) of the semantics of operations against the
reported capabilities (cf OGRLayer.TestCapability)
Apart from the below example, are you thinking to other things ?
RFC 46 is
Ivan,
yes indeed, I missed that one. I'll update the RFC with it.
I think that the intent of RFC36 is covered by what is already proposed in RFC46
with the papszAllowedDrivers of GDALOpenEx().
I do not think that specifying the candidate driver(s) is that usefull in
utilities since the time to
Even,
Yes, it is hard to measure the impact of probing in a single file or any
interactive command line operations.
In the current API the class Driver doesn't expose the Open method:
Driver drv = gdal.GetDriverByName(QWERTY);
Dataset dst = drv.Open(ASDFG);
IMHO that is a missing
From my understanding of the RFC, legacy functions GDALOpen() would only
try to open the dataset using raster drivers and OGROpen() would only try
using vector drivers, so it shouldn't take more time than in gdal 1.x.
It also seems that this RFC addresses the need to specify the driver(s)
used to
Hi, I'm writing to you because I need support for the new Landsat-8
metadata format (_MTL.txt file)
I took a look at the latest version, 1.11.0, and I couldn't find anything
on the matter. So, I was thinking I could add support for the new format by
myself.
There are 3 groups of bands:
With this RFC, you could achieve this using GDALOpenEx()
e.g. GDALOpenEx( ASDFG, GDAL_OF_ALL, QWERTY)
On Fri, May 16, 2014 at 11:01 AM, Ivan Lucena lucena_i...@hotmail.comwrote:
Even,
Yes, it is hard to measure the impact of probing in a single file or any
interactive command line
I went through the whole RFC and it looks great!
Even, this looks like an incredible amount of work and I wanted to thank you
for undertaking it.
Ragi
--
View this message in context:
Hi Etienne,
That sounds great!
Thanks to point that out.
Regards,
Ivan
Date: Fri, 16 May 2014 11:25:13 -0300
Subject: Re: [gdal-dev] Call for discussion on RFC 46: GDAL/OGR unification
From: etourigny@gmail.com
To: lucena_i...@hotmail.com
CC: even.roua...@mines-paris.org;
Daniel,
There's no real need of a new API for that (although it might be cleaner to
have a dedicated one at some point). I'd note that your proposed API would
only work for a single subdataset, not a vector of them.
Anyway, the subdatasets mechanism already exist in many drivers and should do
GDAL gurus,
I'm trying to use the AIXM files from the FAA (downloadable here:
https://nfdc.faa.gov/webContent/56DaySub/2014-05-29/aixm5.0.zip ) in QGIS
and I'm noticing that there are some that with no warnings or complaints
just don't produce a polygon. (ogrinfo says POLYGON EMPTY)
Two examples
Le vendredi 16 mai 2014 20:18:22, Jesse McGraw a écrit :
GDAL gurus,
I'm trying to use the AIXM files from the FAA (downloadable here:
https://nfdc.faa.gov/webContent/56DaySub/2014-05-29/aixm5.0.zip ) in QGIS
and I'm noticing that there are some that with no warnings or complaints
just don't
Well, that explains that one. :)
I'm sure it must be the same story for the other files, various unsupported
GML features. Is there any way to make ogr2ogr warn when it encounters
something it doesn't support versus silently creating blank geometry?
Out of curiosity, is more robust GML/AIXM
Le vendredi 16 mai 2014 21:21:14, Jesse McGraw a écrit :
Well, that explains that one. :)
I'm sure it must be the same story for the other files, various unsupported
GML features. Is there any way to make ogr2ogr warn when it encounters
something it doesn't support versus silently creating
Hi Even,
There's no real need of a new API for that (although it might be cleaner
to
have a dedicated one at some point). I'd note that your proposed API would
only work for a single subdataset, not a vector of them.
Sorry, my bad. Should have been:
GDALDataset** pporSubDatasets;
virtual
I've read the SUBDATASETS domain section and took a look at the HDF5
format, in particular, but I don't think that that would work for me.
I think that should work.
Maybe
I'm not looking at the right place though.
The scenario:
LC82300942013289LGN00_B1.tif
21 matches
Mail list logo
