RC5b compiled in iOS without a problem.
Here's unit test result for iphone iOS 4.2 i.e. iPhone Simulator/4.2.
The unit test does not have a map display yet. The result is from the
console in Xcode IDE.
~~~~~~~~~~~~~~~~~~~~~
[Session started at 2011-03-11 20:15:50 +1100.]
2011-03-11 20:15:54.926 Spatialite2.4.0_LibEnv[79541:207] Spatialite
version 2.4.0-RC5
SpatiaLite version ..: 2.4.0-RC5 Supported Extensions:
- 'VirtualShape' [direct Shapefile access]
- 'VirtualDbf' [direct DBF access]
- 'VirtualText' [direct CSV/TXT access]
- 'VirtualNetwork' [Dijkstra shortest path]
- 'RTree' [Spatial Index - R*Tree]
- 'MbrCache' [Spatial Index - MBR cache]
- 'VirtualSpatialIndex' [R*Tree metahandler]
- 'VirtualFDO' [FDO-OGR interoperability]
- 'SpatiaLite' [Spatial SQL - OGC]
PROJ.4 version ......: Rel. 4.7.1, 23 September 2009
GEOS version ........: 3.3.0-CAPI-1.7.0
2011-03-11 20:15:54.929 Spatialite2.4.0_LibEnv[79541:207] Opening
/var/root/Library/Application Support/iPhone
Simulator/4.2/Applications/65838C8D-E5A0-47EF-9226-276A0CDE228F/Spatialite2.4.0_LibEnv.app/pacaRoadsIndex.sqlite
2011-03-11 20:15:54.935 Spatialite2.4.0_LibEnv[79541:207] OPEN OK
2011-03-11 20:15:54.936 Spatialite2.4.0_LibEnv[79541:207]
================================ TEST1
2011-03-11 20:15:54.937 Spatialite2.4.0_LibEnv[79541:207] req is
SELECT * FROM Roads Where MbrContains(Geometry, MakePoint(7.013891,
43.557964))
2011-03-11 20:15:55.168 Spatialite2.4.0_LibEnv[79541:207] -
2011-03-11 20:15:55.425 Spatialite2.4.0_LibEnv[79541:207] Avenue Saint Louis
2011-03-11 20:15:55.430 Spatialite2.4.0_LibEnv[79541:207] Avenue Saint-Jean
2011-03-11 20:15:55.433 Spatialite2.4.0_LibEnv[79541:207] -
2011-03-11 20:15:57.142 Spatialite2.4.0_LibEnv[79541:207]
==============================TEST GEOS
2011-03-11 20:15:57.146 Spatialite2.4.0_LibEnv[79541:207]
010100000000000000000024400000000000003440
2011-03-11 20:15:57.148 Spatialite2.4.0_LibEnv[79541:207]
===================GEOS seems working!
Thanks.
Noli
> --
> You received this message because you are subscribed to the Google Groups
> "SpatiaLite Users" group.
> To post to this group, send email to spatiali...@googlegroups.com.
> To unsubscribe from this group, send email to
> spatialite-use...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/spatialite-users?hl=en.
>
>
As I mentioned in the previous post that I use the build_iOS script to build
https://github.com/mweisman/ShapeKit/tree/master/lib_src
1. Proj4.7.1
2. GEOS 3.3.0 trunk - March 9
Then, I created Xcode project and use the static libraries of Proj
4.7.1 and GEOS 3.3.0 to build Spatiailite.
I included libiconv.dylib from iOS framework (built-in) and added
localcharset.h from navit
1 warning.
/Volumes/SPARE/SpatialiteRouteMe/Tests/SpatialiteLibEnv25RCb/Spatialite_LibEnv/../libspatialite-amalgamation-2.4.0_5/spatialite.c:
In function 'yy_destructor':
/Volumes/SPARE/SpatialiteRouteMe/Tests/SpatialiteLibEnv25RCb/Spatialite_LibEnv/../libspatialite-amalgamation-2.4.0_5/spatialite.c:59665:
warning: unused variable 'result'
Noli
I've updated my local repository to 2.4.0 RC5 and merged it with my
android branch. The attached patch can be applied to the canonical
source tarball and then you can build spatialite using the android NDK.
An Android.mk file is included for this purpose.
The patchset includes the following changes:
- Adds jni/Android.mk and jni/Application.mk
- Introduces debug/info/error functions which are used instead of
fprintf/printf. On Android these redirect output to logcat.
- Removes duplicate init code from spatialite.c
Note that I'm currently compiling a minimal spatialite. Proj, geos and
iconv are not included which means a lot of features are dropped. Proj
and geos could probably be added rather easily, but I don't have a need
for this myself just yet.
Regards,
Pepijn
The result of running ndk-build is a librtree.so, libspatialite.so and
libsqlite.so. The latter one I don't include in my apk to make sure I
use the platform sqlite library.
Then all you need to do is load rtree and spatialite as sqlite
extensions using the android.database.sqlite API. And this is where the
hacking starts. The sqlite version that is shipped with Android has
extension support built-in but not enabled by default. You need to
somehow call sqlite3_enable_load_extension with the right sqlite3
handle. Turns out this value is actually stored in the
android.database.sqlite.SQLiteDatabase instances as the field
mNativeHandle. It's not public but you can read the value using the
following bit of code
private int getDBHandle( SQLiteDatabase db ) {
try {
Field field = db.getClass().getDeclaredField( "mNativeHandle" );
field.setAccessible( true );
return field.getInt( db );
} catch ( NoSuchFieldException e ) {
return -1;
} catch ( IllegalAccessException e ) {
return -1;
}
}
All that remains to be done is to write a small JNI library that takes
in the sqlite handle and calls sqlite3_enable_load_extension. Once that
call has been done you can load the extension using 'SELECT
load_extension...'
Needless to say all the above is completely unsupported and could break
quite easily in the future, but for now it does work (tested on eclair
and froyo).
Pepijn