[gdal-dev] Some OGR drivers do not work

[Jaak Laineste (Nutiteq)]

2013/5/20 Frank Warmerdam <warmerdam at pobox.com>

>
>
>
> 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.
>

I now recompiled with #define HAVE_LONG_LONG 1 (manually added it to
cpl_config.h) and it seems to work now.

 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.
>
>
I tried that now with mixed results. The file logger works with GDAL, but
not with OGR. So for this specific issue could not use it. But I managed to
hack at least error messages (stdout) to Android own logger, and got the
info what I needed:

1. esrigeojson file - opens ok, this has own parser I guess

2. KML and some other files - no error message, no open. I suspect same
problem as 5. below.

3. GML file:
ERROR 1: Unable to create Xerces C++ or Expat based GML reader, Xerces or
Expat support
-> should add Expat or Xerces, simple (in theory)

4. GPX file
ERROR 6: OGR/GPX driver has not been built with read support. Expat library
required
-> adding Expat should do it, simple

5. other geojson file - error:
 ERROR 4: Unable to open EPSG support file gcs.csv.

This last one brings me to two questions:

a) where can I define folder from where the EPSG support files are read
from? When I had similar problem with proj.4, then I did ugly hack (almost
hardcoded) to pj_open_lib.c, and there is PROJ_LIB variable, but I could
not find similar thing for GDAL. Android JNI does not provide easily
packaged files for C++, but that's another story.

b) how are gdal/osr and proj.4 related in general. If I compile gdal
without proj.4 then does OSR provide some kind of lite standalone
replacement for it?

Jaak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130524/50dc865b/attachment.html>