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
