[gdal-dev] Some OGR drivers do not work

[Frank Warmerdam]

On Mon, May 20, 2013 at 9:26 AM, Jaak Laineste (Nutiteq)
<jaak at nutiteq.com>wrote:

> Hello,
>
> I compiled GDAL 0.10 release for Android, with basic driver package. I
> left cURL and other more complex dependencies for later. It works with
> partial success:
>
> a) Snags during compiling:
>  1. had to disable gif driver, as there was "undefined reference to
> `GIFAbstractDataset::GetMetadataItem". I don't see any real use of that
> anyway.
>  2. from tif_open.c I removed lines 99 and 100 (asserts for 64bit types),
> as they appear not to work on 32bit ARMv7 (they assert false). Would it be
> safe enough? Interesting is that I did not have this problem with GDAL 0.9
>

 Jaak,

When using a built-in libtiff build, libtiff uses the GDAL GIntBig and
GUIntBig types for 64 bit integers.  So this failure means that the
definitions for these types in gdal/port/cpl_port.h are not actually
64bits.  That looks like:

#if defined(WIN32) && defined(_MSC_VER)

#define VSI_LARGE_API_SUPPORTED
typedef __int64          GIntBig;
typedef unsigned __int64 GUIntBig;

#elif HAVE_LONG_LONG

typedef long long        GIntBig;
typedef unsigned long long GUIntBig;

#else

typedef long             GIntBig;
typedef unsigned long    GUIntBig;

#endif

What is an appropriate 64bit integer type on Android?  You are likely
falling into the case that just uses long and unsigned long which is not
great on a 32bit platform.

Note that not getting this type right is likely behind some of the other
failures you are seeing.


 3. Some other tweaks and changes as described in [1] to get also Swig Java
> bindings working
>
> b) Runtime problems. Main problem is that some OGR drivers do not open
> some of test files, even if ogr.GetDriver() reports them. See [2] for
> reported the list. There is no any error message, and debugging this via
> Android NDK would be a bit too much for me.
>

You could customize error handling to log to a file or some other suitable
mechanism from gdal/port/cpl_error.cpp, and also turn on debug output.  For
a logging error handler do this near the start of your program:

  CPLSetConfigOption("CPL_LOG", "/tmp/your.log");
  CPLPushErrorHandler(CPLLoggingErrorHandler);

to enable debugging output do:

  CPLSetConfigOption("CPL_DEBUG", "ON");

I haven't used the logging error handler for a long time so it might be
quirkly/broken/wrong.

Thanks for reporting on your findings!

Best regards,
Frank


>  1. Working files: shapefile, esripolygon.json, dxf, csv
>  2. Not working: KML, GML and GeoJSON. By not working I mean Open
> (<file>,false) returns null.
>
> So my questions:
> 1. Is there a way to troubleshoot runtime problems
> ? org.gdal.gdal.gdal.GetLastErrorMsg() seems to report nothing after Open
> error. Maybe some dependency missing from compilation?
> 2. Any hint how to fix tif_open.c problem properly?
>
> Thank you,
>
> [1] https://github.com/nutiteq/gdal/wiki/AndroidHowto
> [2] https://github.com/nutiteq/hellomap3d/wiki/Ogr-layer
>
>
> Jaak
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130520/3974eb48/attachment-0001.html>