<br><br><div class="gmail_quote">2013/5/20 Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Mon, May 20, 2013 at 9:26 AM, Jaak Laineste (Nutiteq) <span dir="ltr"><<a href="mailto:jaak@nutiteq.com" target="_blank">jaak@nutiteq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hello,</div><div><br>
</div>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:<div><br></div><div>a) Snags during compiling:</div><div>
1. had to disable gif driver, as there was "undefined reference to `GIFAbstractDataset::GetMetadataItem". I don't see any real use of that anyway.</div><div> 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</div>
</div></blockquote><div><br></div></div><div> Jaak,</div><div><br></div><div>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:</div>
<div><br></div><div><div>#if defined(WIN32) && defined(_MSC_VER)</div><div><br></div><div>#define VSI_LARGE_API_SUPPORTED</div><div>typedef __int64 GIntBig;</div><div>typedef unsigned __int64 GUIntBig;</div>
<div><br></div><div>#elif HAVE_LONG_LONG</div><div><br></div><div>typedef long long GIntBig;</div><div>typedef unsigned long long GUIntBig;</div><div><br></div><div>#else</div><div><br></div><div>typedef long GIntBig;</div>
<div>typedef unsigned long GUIntBig;</div><div><br></div><div>#endif</div><div><br></div><div>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. </div>
<div><br></div><div>Note that not getting this type right is likely behind some of the other failures you are seeing.</div></div></div></div></div></blockquote><div><br></div><div>I now recompiled with #define HAVE_LONG_LONG 1 (manually added it to cpl_config.h) and it seems to work now. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div> 3. Some other tweaks and changes as described in [1] to get also Swig Java bindings working</div><div><br></div><div>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.</div>
</div></blockquote><div><br></div></div><div>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:<br>
</div><div><br></div><div> CPLSetConfigOption("CPL_LOG", "/tmp/your.log");</div><div> CPLPushErrorHandler(CPLLoggingErrorHandler);</div><div><br></div><div>to enable debugging output do:</div>
<div><br></div><div> CPLSetConfigOption("CPL_DEBUG", "ON");</div><div><br></div><div>I haven't used the logging error handler for a long time so it might be quirkly/broken/wrong.</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>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:</div>
<div><br></div><div>1. esrigeojson file - opens ok, this has own parser I guess</div><div><br></div><div>2. KML and some other files - no error message, no open. I suspect same problem as 5. below.</div><div><br></div><div>
3. GML file:</div><div><div>ERROR 1: Unable to create Xerces C++ or Expat based GML reader, Xerces or Expat support</div></div><div>-> should add Expat or Xerces, simple (in theory)</div><div><br></div><div>4. GPX file </div>
<div><div>ERROR 6: OGR/GPX driver has not been built with read support. Expat library required</div></div><div>-> adding Expat should do it, simple</div><div><br></div><div>5. other geojson file - error:</div><div><div>
<div> ERROR 4: Unable to open EPSG support file gcs.csv.</div></div></div><div><br></div><div>This last one brings me to two questions: </div><div><br></div><div>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.</div>
<div><br></div><div>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?</div><div><br></div><div>Jaak</div></div>