lqt.it> writes:
>
> On Wed, 9 May 2012 19:50:15 + (UTC), Jukka Rahkonen wrote:
> > However, the Rasterlite file size has probably been
> > around 4 gigabytes when the error occurred. Did I meet some file size
> > limit or tile count limit of the Rasterlite driver?
> >
>
> Hi Jukka,
>
> on
Hi,
I have added an option on the Postgres driver for OGR to avoid computation
of the SRID of a spatial request when the SRID is known. Is it possible to
add it to the code repository ?
--
Alexandre Gacon
ogr_pg.patch
Description: Binary data
___
gda
Thanks for the suggestion. I tried to convert GeoTIFF to jpg - and there
wasn't the problem. Then I tried to convert a small GeoTIFF (20 mb) to XYZ -
it still waited for some time (~10 secs) after displaying the "Done."
message. I think what is happening is that I was converting a set of very
large
Kaarigar is using gdal_translate on Windows 7 64 bit from Geoinformatica
stack, which I've compiled with MingW/MSYS on Windows 7 32 bit.
I just tried similar command line on Windows Server 2008 R2 64 bit and I
don't see it stalling after conversion.
Best regards,
Ari
On 05/10/2012 02:34 AM,
do you get the same problem when converting to another format (say
gtiff) or using other files as input?
Etienne
On Wed, May 9, 2012 at 9:17 PM, kaarigar wrote:
> I can convert a single image to XYZ from command line. And can also convert
> multiple images to command line via batch file - if I p
I can convert a single image to XYZ from command line. And can also convert
multiple images to command line via batch file - if I press CTRL-C after the
conversion for one file is 100% done - it will continue to the next file.
There are no errors or warnings. The conversion to XYZ is successful. I
More questions? Can you convert one image into an xyz? It sounds like you
can. Are there no errors or warnings?
On Wed, May 9, 2012 at 5:34 PM, kaarigar wrote:
> Here's the command line:
>
> gdal_translate -ot Float32 -of XYZ -co "COLUMN_SEPARATOR=," n40w124.tif
> n40w124.xyz
>
>
> Kyle Shann
Here's the command line:
gdal_translate -ot Float32 -of XYZ -co "COLUMN_SEPARATOR=," n40w124.tif
n40w124.xyz
Kyle Shannon-3 wrote
>
> Sounds like your doing something wrong, it shouldn't hang. Can you share
> your command line args or a snippet of your batch file?
>
> kss
>
--
View this me
Sounds like your doing something wrong, it shouldn't hang. Can you share
your command line args or a snippet of your batch file?
kss
On Wed, May 9, 2012 at 5:06 PM, kaarigar wrote:
> I hope this is the right forum to pose this question to.
>
> I am using gdal_translate on Windows 7 64 bit to b
I hope this is the right forum to pose this question to.
I am using gdal_translate on Windows 7 64 bit to batch convert a lot of
GeoTIFF files to XYZ ASCII. (I got gdal_translate when I installed
Geoinformatica tools, based on GDAL version 1.9Dev). However, at the end of
each conversion gdal_trans
Is it possible to use an OGC call in a VRTRasterBand?
This electronic communication and any attachments may contain confidential and
proprietary
information of DigitalGlobe, Inc. If you are not the intended recipient, or an
agent or employee
responsible for delivering this communication to th
On Wed, 9 May 2012 19:50:15 + (UTC), Jukka Rahkonen wrote:
However, the Rasterlite file size has probably been
around 4 gigabytes when the error occurred. Did I meet some file size
limit or tile count limit of the Rasterlite driver?
Hi Jukka,
on any platform there is an intrinsic physical
Hi,
I got the following error when testing Rasterlite with a biggish source data set
gdal_translate -of rasterlite -a_srs epsg:3067 -co driver=PNG 50t.vrt
rasterlite:50t.sqlite,table=50t_rasteri
Input file size is 288000, 48
0...10...20...30...40...50...60...70.ERROR 1: sqlite3_step() failed
Hello everyone,
when using the method OGRDataSource::CopyLayer with a PostGIS data
source my data gets copied perfectly, however I'm seeing that the
sequence for the feature id is not properly set up to the last
existing id (ie. the current stays at 1).
Obviously attempting to create a new featur
Ahem,
It seems to be so that compression makes resulting tiff files smaller. In some
cases they can then fit to almost full disk even there is not enough room for an
uncompressed version.
An explanation for why I did not notice that disk was too full was that the LZW
compression is so effective
15 matches
Mail list logo
