On Fri, May 24, 2013 at 6:16 AM, Jaak Laineste (Nutiteq)
<j...@nutiteq.com>wrote:
>
> 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.
>
Excellent!
> 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.
>
I'm not sure why this is.
> 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.
>
The location to search for can be set various ways, but the easiest in code
is to call the following at startup.
CPLSetConfigOption("GDAL_DATA", "...");
> 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
>
Without PROJ.4 there will be no support for coordinate system
transformations (ie. convert a point from lat/long to utm), but coordinate
system lookups for the purposes of reading and writing files is fine.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
