Never mind, please. I was confused about the way rotations are supposed to
work in grdrotater. I got it working now.
Thank you very much for your help! My problem is solved.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Moving-the-poles-tp5127897p5127999.html
Sent from
Ridge,
How did you install GDAL?
This usually happens when python cannot find the gdal libraries. Setting
PYTHONPATH env variable may help.
On Mon, Mar 10, 2014 at 10:17 AM, ridgewang ridgew...@gmail.com wrote:
Hi,
I want to use gdal_merge.py to merge two image files. But it reports
On 10/03/2014 05:47, ridgewang wrote:
Hi,
I want to use gdal_merge.py to merge two image files. But it reports
cannot load _gdal library and %1 is not a valid win32 module. Here the %1
means the _gdal, maybe. In python CUI, I run 'import osgeo.gdal' or 'import
gdal' command, it
Hi,
I saw a blog about using prepared statements for bulk inserts into SQLite
http://blog.quibb.org/2010/08/fast-bulk-inserts-into-sqlite/
Results show that with prepared statements the inserts/second rate in the
test were at least 3 times better than with standard transactions
Could prepared statements make similar boost for saving spatial data into
SQLite/Spatialite/GeoPackage? Or does GDAL SQLite/Spatialite driver already
utilize them?
Yes, they do already.
Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
On Mon, 10 Mar 2014 12:23:22 + (UTC), Jukka Rahkonen wrote:
Hi,
I saw a blog about using prepared statements for bulk inserts into
SQLite
http://blog.quibb.org/2010/08/fast-bulk-inserts-into-sqlite/
Results show that with prepared statements the inserts/second rate in
the
test were at
I run the echo %pythonpath% and it displays the right directions. And I add the
system python direction before the gdal python direction, it still reports the
same error. I installed by run the gdal-1.10.1.win32-py2.7.msi.
发自我的 iPhone
在 2014-3-10,14:13,Chaitanya kumar CH chaitanya...@gmail.com
Hello,
I am able to render s57 chart in my application using gdal, i am finding
difficulty in filling the areas with specific colors.
please help me in this regards.
--
Thanks Regards,
Girish Deshpande
___
gdal-dev mailing list
Hi all,
Is there a way to configure the proxy for opening data through the ECW
protocol with the ECW driver. For WCS/WMS, I know you can use the
GDAL_HTTP_PROXY configuration option, but that doesn't seem to work for ECW.
Would it make sense to have something like the following in the ECW
André,
If you've tested that successfully, you could create a patch in Trac with that.
Should rather be something like :
proxy = CPLGetConfigOption(GDAL_HTTP_PROXY, NULL);
if( proxy != NULL )
NCSecwSetConfig(NCSCFG_ECWP_PROXY, proxy);
Even
Hi all,
Is there a way to configure the proxy
Hi List,
Bringing back an old thread but with a slight change.
I'm now trying to get GDAL to mosaic and export from the ASCII files to a
GeoTIFF.
But the GeoTIFF writer in GDAL is doing the exact same thing as the ASCII
writer was - it's taking *50.597* (source value) and converting it into
Hello,
On Thu, Mar 6, 2014 at 8:05 PM, Even Rouault
even.roua...@mines-paris.org wrote:
Le jeudi 06 mars 2014 18:45:50, Jorge Arevalo a écrit :
Hello,
I'm trying to create a new table in CartoDB using the GDAL CartoDB
driver and Python bindings. I'm getting a HTTP 400 error.
This is the
Have you tried using a 36bit (float) instead of 64bit (double) output?
double is usually the default output type and has more significant digits
(~16) than your source, so it's representation is ok in double format
see [1] for an explanation on floating-point precision
the following argument
Hi Etienne,
I was looking for something like that but the
http://www.gdal.org/frmt_gtiff.html page didn't list it explicitly.
That said, looking at the gdalinfo now (a little late) I see that it's
already defaulting to Float32. I also tested with the -ot Float32
arguement, but there was no
Le lundi 10 mars 2014 18:55:36, Jonathan Moules a écrit :
Hi Etienne,
I was looking for something like that but the
http://www.gdal.org/frmt_gtiff.html page didn't list it explicitly.
That said, looking at the gdalinfo now (a little late) I see that it's
already defaulting to Float32. I
Hi,
I restored DECIMAL_PRECISION and added SIGNIFICANT_DIGIT and also
reformatted the NODATA_value, although that may or may not be correct
as per Even's remarks. See:
http://trac.osgeo.org/gdal/ticket/3732
for a review.
On Mon, Mar 10, 2014 at 1:21 PM, Even Rouault
Hello,
I'm working with a MIF file, contaning just 5 multipolygons (in form
of regions, in MapInfo terms). But the file weights 700MB. So, the
multipolygons are really big. I'd like to transform my file to SHP or
PostGIS using ogr2ogr, but any operation takes forever.
My current approach is to
Hi OGRers,
(Would that be pronounced ogres ? :-) )
I need to create _a lot_ of blank SHP files with schemas that I
currently have in CSV files.
(For me) the easiest way is to create a script that reads the CSV files
and generates empty (geometry wise) Mapinfo MID-MIF filesets.
I then use
Well, attach a debugger to the ogr2ogr process and see where the time is
spent.
your SQL clause could be replaced by -fid 1, but I'm not sure that the reason
for the slowness.
Hello,
I'm working with a MIF file, contaning just 5 multipolygons (in form
of regions, in MapInfo terms). But
19 matches
Mail list logo