http://trac.osgeo.org/gdal/ticket/4431
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/GDAL-Java-Binding-meomory-problem-under-intensive-method-calls-tp7155011p7168002.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
Le samedi 07 janvier 2012 14:18:12, easyl a écrit :
> Ja, I am re-writing now the ogrtindex.cpp from
> http://svn.osgeo.org/gdal/trunk/gdal/apps/ogrtindex.cpp in Java.
>
> It seems be rather easier than ogr2ogr or ogrinfo.
>
> I found a Clone call in cpp code
>
>poFeatureDefn = poLayer->GetL
Ja, I am re-writing now the ogrtindex.cpp from
http://svn.osgeo.org/gdal/trunk/gdal/apps/ogrtindex.cpp in Java.
It seems be rather easier than ogr2ogr or ogrinfo.
I found a Clone call in cpp code
poFeatureDefn = poLayer->GetLayerDefn()->Clone();
But in Java binding (1.8.1) there is no Clone(
> Can I implement ogrtindex in Java as well?
I've scanned quickly ogrtindex.cpp and I believe that all the APIs it uses are
exposed in the Java bindings, so yes it looks like it is doable. I see that
there's a large part of the code that does various checks. You can probably skip
some of them if y
your are right!
It fixed the problem!!
Actually I have another question (after fixing the violation bug).
Can I implement ogrtindex in Java as well?
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/GDAL-Java-Binding-meomory-problem-under-intensive-method-calls-tp7155011p7
Hi,
ok I found what was going on. The issue is the call to ogr2ogr which calls
ogr.RegisterAll(). The effect of calling ogr.RegisterAll() when it has already
been called is to reload the drivers, which will invalidate any opened
datasource, like the one you use indirectly for the source layers. Th
directly using ogr2ogr and ogrinfo from
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/
I made a following test cae.
somehow I noticed that the error occurs when the S57 data more than 1mb
==
public class TestViolation {
public static void main(Str
Jean-Claude Repetto wrote:
>
> On 07/06/11 22:54, mett wrote:
>
> I think your results are correct, because PROJ.4 gives exactly the same
> ones :
>
> proj -I -f "%.12f" +proj=lcc +lat_1=64.25 +lat_2=65.75 +lat_0=65
> +lon_0=-19 +x_0=50 +y_0=50 +datum=WGS84 +units=m +no_defs
> 258321.
On 07/06/11 22:54, mett wrote:
Jean-Claude Repetto wrote:
Probably because your projection is not cylindrical. What projection are
you using ?
The projection is
`PROJCS["User-Defined WGS84/Lambert Conformal Conic (IS.)",GEOGCS["WGS
84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.257223563,
Jean-Claude Repetto wrote:
>
> Probably because your projection is not cylindrical. What projection are
> you using ?
> Jean-Claude
>
> The projection is
> `PROJCS["User-Defined WGS84/Lambert Conformal Conic (IS.)",GEOGCS["WGS
> 84",DATUM["WGS_1984",SPHEROID["WGS
> 84",6378137,298.257223563,AUT
On 07/06/11 22:26, mett wrote:
Hello,
thank you very much for your reply. For example:
Upper Left = (*258321.25943477*, 655225.28062628)
Lower Left = (*258321.25943477*, 574605.28062628)
here the X value is the same (258321.25943477), so, I would aspect that also
the conversion is the same relate
Hello,
thank you very much for your reply. For example:
Upper Left = (*258321.25943477*, 655225.28062628)
Lower Left = (*258321.25943477*, 574605.28062628)
here the X value is the same (258321.25943477), so, I would aspect that also
the conversion is the same related to the X value (in fact is a
Sagar,
this is normally just a matter of having all the needed .so (libgdal.so and the
4 JNI .so) in your LD_LIBRARY_PATH and gdal.jar in your java classpath.
I'd encourage you to try on the command line first.
See http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix
__
Even,
I am actually trying to run the ogr2ogr.java from the link which you have
specified. In that if I don't load all the .so files individually it gives
me an exception at .AllRegister() method and the execution stops, but when I
load them individually it catches the exception and displays the
Sagar,
don't load the .so directly. Let gdal.jar do the dirty work for you !
Use the import org.gdal.XXX imports and then gdal.AllRegister() or
ogr.RegisterAll() instead.
See the examples in
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps
Le jeudi 07 octobre 2010 11:03:36, sagar_
Hi Even,
Thanks for that, that error has been resolved. But the following warning as
keeps coming , would you know what this means:
Native library load failed.
java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path
I am loading all the .so files individually
S
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:
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
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
,
Ivan
> ---Original Message---
> From: sagar_sahay
> To: gdal-dev@lists.osgeo.org
> Subject: [gdal-dev] Re: GDAL JAVA problem
> Sent: Oct 06 '10 08:43
>
>
> Hi Ivan,
>
> Can you please help me with compiling the GdalInfo class in Ubuntu with
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
I just notice this message therefore I thought I would share some thoughts.
There has been an experiment in geotools a while ago in order to
support ogr as a datastore to access more formats (s57 where are you
:-) ), the result is an unsupported module in our svn
http://svn.osgeo.org/geotools/tru
Wanted to CC the list in the first place as it might be of general interest...
Le Monday 09 March 2009 19:53:35, vous avez écrit :
> Paul,
>
> Frank has already almost said everything ;-)
>
> You need to be able to build (or get):
> - GDAL/OGR with OGDI support
> - the Java bindings by folllowing
23 matches
Mail list logo
