On 06/10/2010 19:35, Even Rouault wrote:
Le mercredi 06 octobre 2010 18:42:14, Eli Adam a écrit :
The results of -tap are what I expect, pixels aligned with 0,0. Although I
have a separate question at the end.
ok, I've applied the patch in trunk in r20778
Thanks.
Yesterday evening, I was t
Hi Even,
thanks for clarification
2010/10/6 Even Rouault :
> Le mercredi 06 octobre 2010 20:17:29, Alexander Bruy a écrit :
>> Hi,
>>
>> Seems, that OGR reports wrong capabilities for SQLite/SpatiaLite layers.
>> At least for DeleteFeature capability. I always get FALSE when test this
>> capabili
Alexander Bruy wrote:
Hi,
I've develop some GIS tools with Delphi and want to use GDAL/OGR. I can't find
any existing Pascal bindings, so I start to write them by myself. Now
I have ObjectPascal
(Delphi and FreePascal compatible) bindings for OGR.
When I compile and run small test application (
Le mercredi 06 octobre 2010 20:17:29, Alexander Bruy a écrit :
> Hi,
>
> Seems, that OGR reports wrong capabilities for SQLite/SpatiaLite layers.
> At least for DeleteFeature capability. I always get FALSE when test this
> capability, but I can delete features from layer passing to the ExecuteSQL
Hi,
Seems, that OGR reports wrong capabilities for SQLite/SpatiaLite layers.
At least for DeleteFeature capability. I always get FALSE when test this
capability, but I can delete features from layer passing to the ExecuteSQL
method DELETE statement.
Is this bug or feature?
Thanks
--
Alexander
Hi,
I've develop some GIS tools with Delphi and want to use GDAL/OGR. I can't find
any existing Pascal bindings, so I start to write them by myself. Now
I have ObjectPascal
(Delphi and FreePascal compatible) bindings for OGR.
When I compile and run small test application (simply open a shape,
dis
On Wednesday 06 October 2010 14:38:31 Joel Odom wrote:
> Is there a canonical way to pick an OGR driver based on a file name or on a
> generalized connect string?
No, but you can do a generic open, as in:
datasource = ogr.Open(filename)
Cheers,
--
--
Iván Sánche
I used gdal_translate to convert a geotiff to an ecw file.
C:\Program Files\FWTools2.4.7>gdal_translate -of ECW f:\test\mytif.tif
f:\test\myecw.ecw
Input file size is 2353, 2353
0...10...20...30...40...50...60...70...80...90...100 - done.
However, the corner coordinates are different between the
Le mercredi 06 octobre 2010 16:35:38, sagar_sahay a écrit :
> After tweaking the path variable I got this exception:
>
> Native library load failed.
> java.lang.UnsatisfiedLinkError:
> /home/gdal/gdal-1.7.2/swig/java/libgdaljni.so:
> /home/gdal/gdal-1.7.2/swig/java/libgdaljni.so: wrong ELF class:
Le mercredi 06 octobre 2010 18:42:14, Eli Adam a écrit :
> The results of -tap are what I expect, pixels aligned with 0,0. Although I
> have a separate question at the end.
ok, I've applied the patch in trunk in r20778
>
> Prior to the patch I ran this:
> gdal_rasterize -tr 100 100 -a Elevatio
The results of -tap are what I expect, pixels aligned with 0,0. Although I
have a separate question at the end.
Prior to the patch I ran this:
gdal_rasterize -tr 100 100 -a Elevation -l town town.shp townrasterb.tif
and got this:
gdalinfo townrasterb.tif
...
Origin = (7267911.066051597706974,5
Thanks for the help Chaitanya,
Sorry about the late response. I saw the temporary fix with swq.h. I'm
confused about one aspect of this workaround though. It says that I should
copy the swq.h file into the gdal installed tree. So this is the step after
compiling gdal-1.7.2 ? For some reason it se
On Wed, Oct 6, 2010 at 7:34 AM, Frank Warmerdam wrote:
> Livneh Yehiyam wrote:
>
>> I agree that the amount is small per file, but in our application we need
>> to keep thousands of files open, and keep memory consumption to a certain
>> limit.
>>
>
> Ah, I'm starting to grasp your issue. I will
On 06/10/2010 16:34, Frank Warmerdam wrote:
Hermann Peifer wrote:
$ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte
-a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg -burn
1 -where CODE=111 lu001l_luxembourg.shp out.tif
OGR: OGROpen(lu001l_luxembourg.shp/0x1978ae0
After tweaking the path variable I got this exception:
Native library load failed.
java.lang.UnsatisfiedLinkError:
/home/gdal/gdal-1.7.2/swig/java/libgdaljni.so:
/home/gdal/gdal-1.7.2/swig/java/libgdaljni.so: wrong ELF class: ELFCLASS64
(Possible cause: architecture word width mismatch)
Exception
Hermann Peifer wrote:
$ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte
-a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg -burn
1 -where CODE=111 lu001l_luxembourg.shp out.tif
OGR: OGROpen(lu001l_luxembourg.shp/0x1978ae0) succeeded as ESRI
Shapefile.
GDAL: QuietD
On 06/10/2010 15:20, Hermann Peifer wrote:
On the other hand...
The new, target aligned tiffs do only have NODATA values, which seems to
be related to ERROR 1:
$ gdal_rasterize --debug on --config GDAL_CACHEMAX 2000 -ot byte
-a_nodata 0 -co compress=lzw -tr 255 255 -tap -l lu001l_luxembourg -b
Ivan,
I have specified -Djava.library.path="~/home/gdal/gdal-1.7.2/swig/java". Is
there any other way to include the files which you had mentioned in the
reply. If so please let me know.
Thanks,
Sagar
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/GDAL-JAVA-problem-tp
Daniel Morissette wrote:
Now, according to http://trac.osgeo.org/gdal/wiki/LargeFileSupport
GDAL/OGR already enables large file support if your OS supports it .
Obviously that did not work in this case.
Daniel,
The above topic says that GDAL supports reading large files, it doesn't
necessarily
Sagar,
In order to make it to work you NetBeans need to have access to GDAL shared
libraries, the GDAL Java wrapper shared libraries and the GDAL.JAR file. I
would guess that the GDAL Java wrapper not been in the path would be the usual
suspect (libgdalconstjni.so, libgdaljni.so).
Regards,
Iv
Hi Ivan,
Can you please help me with compiling the GdalInfo class in Ubuntu with
Netbeans. My problem is that the program is throwing an exception when it
reaches the gdal.AllRegister() method and the exception says the following:
Native library load failed.
java.lang.UnsatisfiedLinkError: no gd
Taking this thread back to the list.
The problem here seems to be that the stat() calls fail because the
samba share uses large (64 bit) inode values which are too large for the
32 bit st_ino member of the stat struct.
I have found two possible solutions on the Web, but didn't test either one:
1
On 05/10/2010 19:40, Even Rouault wrote:
Le lundi 04 octobre 2010 17:23:47, Frank Warmerdam a écrit :
gdal_translate, gdalwarp, ...
Even,
I would suggest "-tap" for "target aligned pixels" to go with "-tr". I
would think that gdalwarp, gdal_rasterize, and perhaps gdal_merge.py and
gdalbuild
Thanks, Frank.
I understand the purist argument against this, though I think that 90% of
the time you can look at a connection string for a data source and determine
what the output driver should be. I'd like to see this feature in the
future, but I understand that it would need a caveat that it
Joel Odom wrote:
Is there a canonical way to pick an OGR driver based on a file name or
on a generalized connect string? (For example, if the file name ends in
".shp", it would select the Shapefile driver.) Thanks.
Joel,
No.
I really wanted to send this out with just that one word answer,
Is there a canonical way to pick an OGR driver based on a file name or on a
generalized connect string? (For example, if the file name ends in ".shp",
it would select the Shapefile driver.) Thanks.
--
http://www.operationliberate.com/
___
gdal-dev ma
Livneh Yehiyam wrote:
Frank,
I agree that the amount is small per file, but in our application we
need to keep thousands of files open, and keep memory consumption to a
certain limit.
Livneh,
Ah, I'm starting to grasp your issue. I will humbly suggest that the idea
of keeping thousands of f
27 matches
Mail list logo
