Errors when invoking Spatialite SQL Functions.

[Lionel G.]

Hello,
I'm using spatialite in an iPhoneOS environement.
I have compiled it (without GEOS and PROJ4) and it's running properly.
Then I generated my DB thanks to spatialitite GUI with some roads
imported from shapefiles (geofabrik).
Everything is OK when I perform some basic requests (from the code,
objectiveC) on my DB : for instance "SELECT * FROM roads where
PK_UID=893" returns the expected resultset.
Everything becomes less clear to me when performing requests that are
Spatialite specific and that rely onto the Spatialite SQL Functions :
nothing is working. I think I've missed a step here to get those
functions loaded into the DB but I can't figure out what and how to
solve this :(
Ex : A very simple request such as "select spatialite_version()" works
OK in Spatialite GUI, but when I try to perform it in my iPhoneOS
environement with exactly the same DB as in Spatialite GUI, I get an
error.
Can someone tell me what I'm missing here to get those Spatialite SQL
function running properly ? (They're running fine in Spatialite GUI,
but when I try to perform the same reqs in my code or even in the
SQLite Manager firefox plugin, nothing is working :/)

Versions used :
2010-03-19 10:59:59.486 testAppSpatialiteLib[2196:20b] Spatialite
version 2.3.1
2010-03-19 10:59:59.489 testAppSpatialiteLib[2196:20b] SQlite version
3.6.16

Some traces to describe my env :
(initialize verbose)
SpatiaLite version ..: 2.3.1 Supported Extensions:
- 'VirtualShape' [direct Shapefile access]
- 'VirtualText [direct CSV/TXT access]
- 'VirtualNetwork [Dijkstra shortest path]
- 'RTree' [Spatial Index - R*Tree]
- 'MbrCache' [Spatial Index - MBR cache]
- 'VirtualFDO' [FDO-OGR interoperability]
- 'SpatiaLite' [Spatial SQL - OGC]

Many thanks for you help,
Lionel.

[Lionel G.]

Ok, I'm replying to myself !
I still don't get it working but I'm progressing I think (and I
hope :/). If someone can tell me if I'm in the right direction..... :/
I think that if I cannot access the Spatialite functions through SQL,
this comes from the fact that the SQLite extension for Spatialite is
not properly loaded. I read the various installations procedures
here :
http://www.gaia-gis.it/spatialite/install-mac.html
I'm not very familiar with the extension usage in SQLite but I think
that this is the root cause.

From the documentation it seems that you can do a SELECT
load_extension(extension) to get it loaded dynamically, but this
relies onto the dynamic library mechanism that is not available on the
iPhone (only static libraries .a are available).

I'm using amalgation source files and so, I was wondering if I could
compile SQLite *AND* Spatialite in such a way that the result properly
loads the extension ?
Is this approach OK or there any other approach to get this running
onto the iPhone ?

Thanks for your help.
Cheers
Lionel.

[Noli Sicad]

Lionel.

I am very interested what you are working - running Spatialite in iPhoneOS.

I think this the part of the solution to your problem -
libsqlite3.dylib in iphone

How does one add libsqlite3.dylib to an iPhone project?
http://forums.pragprog.com/forums/83/topics/1849

Would be be able to share project to us?

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

[Lionel G.]

I think I got it ! :p
I dived into the code to check how the extension mechanism was
working.
This lost webpage (thanks google !) put me on the track :
http://www.mail-archive.com/sqlite...@sqlite.org/msg46986.html
about the init sequence.

The spatialite_init(1); actually calls the static init
init_static_spatialite that does all the extension registration
statically.
The code is properly commented at this place
/* used when SQLite initializes SpatiaLite via statically linked lib
*/

I was invoking the spatialite_init(1) but too late ! (after opening
the DB :/)
I move this spacialite_init(1); to the first line of my code and I've
been able to get the SELECT spatialite_version() returning me "2.3.1"
under iPhone :)

Just to share my happiness with you !
;)
I hope I've passed the hardest part and that I can now concentrate on
playing with spatialite !
If I'm making good progress about my use of spatialite, I think I'll
write a tutorial about how to get it running on the iPhone.
Cheers
Lionel.

[Lionel G.]

Hi Noli,
Thanks for your help but the root cause does not cause from the import
of the dylib for SQlite3.
Actually I was already able to compile SQlite3 for iPhone (older post
here : )
http://groups.google.com/group/spatialite-users/browse_thread/thread/5e6b035dbf3d1b91/0c5383d850fb0720

When you want to use Spatialite for SQlite, you cannot rely on the one
that is part of the SDK : it's too old. You have to compile SQLite on
your own as well to get a proper version that is going to match
Spatialite.

I have a running Xcode project here :
http://bit.ly/aTKsI6

It's not the one I'm working on now (no SQL invokations in it) , but
in this one, Spatialite is already being properly compiled for iPhone
(without GEOS PROJ however).

I'm still checking my env for spatialite and it works ok, I'll share
it with the group.
Cheers
Lionel.

On Mar 19, 11:09 pm, Noli Sicad <nsi...@gmail.com> wrote:
> Lionel.
>
> I am very interested what you are working - running Spatialite in iPhoneOS.
>
> I think this the part of the solution to your problem -
> libsqlite3.dylib in iphone
>

> How does one add libsqlite3.dylib to an iPhone project?http://forums.pragprog.com/forums/83/topics/1849

>
> Would be be able to share project to us?
>
> Regards, Noli
>

[Lionel G.]

Hello again,
I'm progressing but have trouble to sort out things...
Depending on the king of SQL request I invoke in the code, some work,
some others don't (most of them actually :/).
As I didn't include PROJ and GEOS (to keep it "simple" at first) , I
can imagine that SQL functions that rely on such libraries won't work.
That's ok.
When I invoke from the code :
SELECT spatialite_version(), I get "2.3.1" =>OK
SELECT geos_version(), I get NULL => OK
SELECT proj4_version(), I get NULL => OK

But from the doc http://www.gaia-gis.it/spatialite/spatialite-sql-2.3.1.html
, invoking something such as
SELECT IsZipBlob(Geometry) FROM roads where PK_UID=894
does not seem to have any dependency to GEOS or PROJ.
So my understanding is that I shoudl be able to get this running, even
if GEOS and PROJ are omitted.
Is my asumption right / wrong ? :(

Some more information :
when I set a breakpoint into
fnct_spatialite_version (sqlite3_context * context, int argc,
sqlite3_value ** argv)
and invoke SELECT spatialite_version() from the code, I enter the
function => OK

But when I set a breakpoint into
fnct_IsZipBlob (sqlite3_context * context, int argc, sqlite3_value **
argv)
and invoke SELECT IsZipBlob(Geometry) FROM roads where PK_UID=894,
I don't enter this function :(

If anyone can confirm me or not that GEOS / PROJ4 are required to get
SQL isZipBlob running, I'd be very grateful.
Thanks,
Lionel.

On Mar 19, 11:20 pm, "Lionel G." <lionel.guegan...@gmail.com> wrote:
> I think I got it ! :p
> I dived into the code to check how the extension mechanism was
> working.
> This lost webpage (thanks google !) put me on the track :

> http://www.mail-archive.com/sqlite-us...@sqlite.org/msg46986.html

[Lionel G.]

Hi,
Just to keep you informed of my progress, and if in the meantime,
sometimes can send feedback about his experience about getting
spatialite working on the iPhone...
Now, thanks to some cross compiling scripts found on web side to
compile open source projects, I 'm able to compile and link spatialite
+ GEOS + PROJ4.
However, I get an issue when running, the generated static library for
GEOS and/or PROJ4 seems to have an issue....
Still fighting but still hoping to get this running !
Lionel.

On Mar 20, 7:17 pm, "Lionel G." <lionel.guegan...@gmail.com> wrote:
> Hello again,
> I'm progressing but have trouble to sort out things...
> Depending on the king of SQL request I invoke in the code, some work,
> some others don't (most of them actually :/).
> As I didn't include PROJ and GEOS (to keep it "simple" at first) , I
> can imagine that SQL functions that rely on such libraries won't work.
> That's ok.
> When I invoke from the code :
> SELECT spatialite_version(), I get "2.3.1" =>OK
> SELECT geos_version(), I get NULL => OK
> SELECT proj4_version(), I get NULL => OK
>

> But from the dochttp://www.gaia-gis.it/spatialite/spatialite-sql-2.3.1.html

[Lionel G.]

Ok I think the libs are now OK.
Here is the result available here :
http://bit.ly/dAB21v
binaires as static libs for spatialite / geos / proj4 for iPhone
Simulator x86 and iPhoneOS ARM.
I still have trouble getting a GEOS SQL request working properly but
at least, those ones are working :
2010-03-24 22:04:59.446 testAppSpatialiteLib[69734:20b] SELECT
spatialite_version() = 2.3.1
2010-03-24 22:04:59.447 testAppSpatialiteLib[69734:20b] SELECT
geos_version() = 3.1.1-CAPI-1.6.0
2010-03-24 22:04:59.448 testAppSpatialiteLib[69734:20b] SELECT
proj4_version() = Rel. 4.6.1, 21 August 2008

This one is KO :/ I don't have any idea why, so if someone has an idea
why such request could fail (SQL error in syntax ) even if the env
seems to be ok, thansk for sharing ! ;)
2010-03-24 22:04:59.448 testAppSpatialiteLib[69734:20b] SELECT
AsText(Geometry) FROM roads where PK_UID=894
KO :(

Lionel.

[Lionel G.]

Ok, after fighting with XCode, I now have a clean environement with
spatialite (2.3.1) running properly on the iPhone, simulator + device
with all the spatial queries running fine.
I've made a demo XCode project that embeds the demo1.c demo2.c demo3.c
demo4.c sources files and that executes them to check if everything
runs fine : and that's fine ;)
Even if I didn't get much feedback from the group for this iPhone
stuff, if anyone is interested in such environement, I'd be happy to
share it.
Cheers
Lionel.

[noel frankinet]

Lionel G. a �crit :
Hello lionel,

Im definitely interested, it was on my todo list

Best regards
No�l Frankinet

[Lionel G.]

Hi Noel,
Here's the link to the zip containing the XCode project that embeds a
standalone spatialite for iPhone
http://bit.ly/9hJjw2
Your feedback is welcome.

HOWEVER, since yesterday I'm playing with all this stuff, performing
spatial request with spatial indexes (wahou , that's fast, even on a
3G iPhone :) and I discovered that I have a different behavior
between x86 and ARM grrrrrrrr ! Actually, there's something going
wrong when manipulating SQL "double" type .
Ex : I'm performing a request such as
SELECT name, ref, Distance(Geometry, MakePoint(%f,%f,4326))*10000 AS
dist FROM ......

From the spatialite documentation the "Distance(...." returns a
double .
When I get it back on x86, the values look OK (I'm using
sqlite3_column_double(statement, 2) )

When I execute the same on ARM, I get "INF" displayed or any other big
big big value that looks very very wrong.

The rest works ok but I only get trouble with this mapping of the
double between the SQLite layer and my code.

Any hint would be fairly appreciated :)

Cheers
Lionel.

[noel frankinet]

Lionel G. a �crit :

> Hi Noel,
> Here's the link to the zip containing the XCode project that embeds a
> standalone spatialite for iPhone
> http://bit.ly/9hJjw2
> Your feedback is welcome.
>

Hello Lionel,

Thank you very, it's much appreciated. I still struggling with Iphone
plaform, I'm used to windowsCE.

> HOWEVER, since yesterday I'm playing with all this stuff, performing
> spatial request with spatial indexes (wahou , that's fast, even on a
> 3G iPhone :) and I discovered that I have a different behavior
> between x86 and ARM grrrrrrrr ! Actually, there's something going
> wrong when manipulating SQL "double" type .
> Ex : I'm performing a request such as
> SELECT name, ref, Distance(Geometry, MakePoint(%f,%f,4326))*10000 AS
> dist FROM ......
>
> >From the spatialite documentation the "Distance(...." returns a
> double .
> When I get it back on x86, the values look OK (I'm using
> sqlite3_column_double(statement, 2) )
>
> When I execute the same on ARM, I get "INF" displayed or any other big
> big big value that looks very very wrong.
>
> The rest works ok but I only get trouble with this mapping of the
> double between the SQLite layer and my code.
>
> Any hint would be fairly appreciated :)
>

I had this of problem with pocketPC (also running arm or xcode). I was
devlopping a GIS application. I end up using fixed math, replacing all
double with long. I had a tremendous speeed gain.
I was told that arm processsor use software routines to handle double,
but I'm not sure.

I'll have a look to your code

Thanks again
Noel

[Lionel G.]

Thanks for your feedback Noel.
Actually this bug is strange. AsText (that returns a char*) for
instance works OK on both platforms (iPhoneOS and simulator) but the
GLength (that returns a double too) give the same kind of result as
Distance : when I try to display it with a %f, most of the time I get
a "INF" displayed.

If you want further information about my whole build process, and you
want to restart all from scratch , I can provide you the cross
compilation scripts I used for GEOS, PROJ4 and Spatialite.

Cheers
Lionel.

[noel frankinet]

Lionel G. a �crit :

> Thanks for your feedback Noel.
> Actually this bug is strange. AsText (that returns a char*) for
> instance works OK on both platforms (iPhoneOS and simulator) but the
> GLength (that returns a double too) give the same kind of result as
> Distance : when I try to display it with a %f, most of the time I get
> a "INF" displayed.
>
> If you want further information about my whole build process, and you
> want to restart all from scratch , I can provide you the cross
> compilation scripts I used for GEOS, PROJ4 and Spatialite.
>

Yes please do Lionel. I can provide the same setup for pocket PC if
interested.
When I'm ready, I'll try to investigate your problem (maybe you use %Lf
for double value ?)

No�l

[Lionel G.]

You'll get 2 scripts there (1 that can be used for PROJ4 and GEOS, the
other one is for spatialite, as for spatialite, you need to express
the paths to GEOS and PROJ4 (headers + lib) as input , see
http://www.gaia-gis.it/spatialite/how_to_build_libspatialite.html for
further details) :

http://bit.ly/aTKsI6

Basically you need to take care of the paths to gcc, and the SDK in it
(I'm still using leopard, and targeting 3.0 sdk).
Also don't forget to set the output paths.

Download the source files for GEOS, PROJ4, spatialite (as
amalgamation).
Put the script in the root dir (there should be a configure script in
there)

then run the script.
I'm generating the static libs and headers in libs_output.

I keep on trying to understand where the "double" bug comes from :
when I'm invoking the X(Start(POINT(.... that also returns a double,
this one works fine ! So there should be a diff between all those
methods that return double: most of them seem to fail but some
don't :/

Cheers
Lionel.

[noel frankinet]

Lionel G. a �crit :

> You'll get 2 scripts there (1 that can be used for PROJ4 and GEOS, the
> other one is for spatialite, as for spatialite, you need to express
> the paths to GEOS and PROJ4 (headers + lib) as input , see
> http://www.gaia-gis.it/spatialite/how_to_build_libspatialite.html for
> further details) :
>
> http://bit.ly/aTKsI6
>
> Basically you need to take care of the paths to gcc, and the SDK in it
> (I'm still using leopard, and targeting 3.0 sdk).
> Also don't forget to set the output paths.
>
> Download the source files for GEOS, PROJ4, spatialite (as
> amalgamation).
> Put the script in the root dir (there should be a configure script in
> there)
>
> then run the script.
> I'm generating the static libs and headers in libs_output.
>

Thanks again, I'll try that.

> I keep on trying to understand where the "double" bug comes from :
> when I'm invoking the X(Start(POINT(.... that also returns a double,
> this one works fine ! So there should be a diff between all those
> methods that return double: most of them seem to fail but some
> don't :/
>

I suspect an overflow/ underflow issue, or little endian/big endian
problem, did you generated the sqlite file on a pc ?

[Lionel G.]

I'm running on MacOS X (leopard) not on windows.
Yes I was thinking about this little / big story but cannot figure out
how to check this :/

On Apr 1, 3:38 pm, noel frankinet <noel.franki...@skynet.be> wrote:
> Lionel G. a crit :
>
>
>

[noel frankinet]

Lionel G. a �crit :

> I'm running on MacOS X (leopard) not on windows.
> Yes I was thinking about this little / big story but cannot figure out
> how to check this :/
>

You could try a simple file with a double in it, write on mac, read on
iphone ?

[Lionel G.]

Actually since I work with iPhone and SQlite (I was already using
SQlite before using spatialite, but I never had to recompile it
however), I never had trouble reading double from a sqlite DB file.
But those double (such as returned by Distance) are computed in
spatialite.c in C functions:

static void
fnct_Distance (sqlite3_context * context, int argc, sqlite3_value **
argv)
{
/* SQL function:
/ Distance(BLOBencoded geom1, BLOBencoded geom2)

Depending on how this code is compiled (or how the library on which
it relies is compiled), this may cause side effects.

Later on in the code, this goes into GEOS :

SQL Distance (as invoked in SQL) -> fnct_distance (spatialite.c) ->
gaiaGeomCollDistance (spatialite.c) -> GEOSDistance (GEOS !)

So the whole chain needs to be properly compiled to work.

Lionel

[noel frankinet]

Lionel G. a �crit :

Maybe something weird in the way the blob are converted (struct
alignment maybe, I've been bitten more than once by that)

No�l

[Lionel G.]

Actually, in the GEOS environnement, there is a file called
"platform.in" that during the build process leads to the generation of
a platform.h that is used during compilation.

I didn't touch anything, but when I generate it for ARM, I still get
this in it :

//Defines NaN for intel platforms
//Don't forget to define infinities
#define DoubleNotANumber 1.7e-308
#define DoubleInfinity 1.7e+308
#define DoubleNegInfinity -1.7e+308

So I suppose that I should do something for ARM here :/ But I'm not
sure what ?!
Lionel.

[noel frankinet]

Lionel G. a �crit :

Yes, this should checked with the arm double handling capabilities, I'm
not sure either. I google for it

[Lionel G.]

In the latest release of GEOS (3.2.1) they've changed the way those
values are defined in the platform.h :

//Defines NaN for intel platforms

#define DoubleNotANumber std::numeric_limits<double>::quiet_NaN()

//Don't forget to define infinities

#define DoubleInfinity std::numeric_limits<double>::infinity()
#define DoubleNegInfinity -std::numeric_limits<double>::infinity()

#define DoubleMax std::numeric_limits<double>::max()

I'm going to give a try to this release, I'll keep you informed.

Lionel.

[Lionel G.]

In the latest release of GEOS (3.2.1) they've changed the way those
values are defined in the platform.h :

//Defines NaN for intel platforms

#define DoubleNotANumber std::numeric_limits<double>::quiet_NaN()

//Don't forget to define infinities

#define DoubleInfinity std::numeric_limits<double>::infinity()
#define DoubleNegInfinity -std::numeric_limits<double>::infinity()

#define DoubleMax std::numeric_limits<double>::max()

I'm going to give a try to this release, I'll keep you informed.

Lionel.

[Lionel G.]

(sorry for the double previous post)
It still does not work but looks more "consistent" : Distance( always
return an "inf" double with GEOS 3.2.1 (I also recompiled spatialite
and linked to the GEOS 3.2.1)
In conclusion it's different if I change GEOS , so in theory, the
asumption that this bug in double value comes from GEOS should be
correct..... :/

[hamish keith]

Hi Lionel

I know this is mega old but I am struggling with spatial-lite iOS for the first time and yours seems to be the best post.

I am down to 5 errors, all in spatiallite.h where it doesn't recognise the type sqlite3.  I wanted to download your 'clean project' as I am sure I can work it out but I note it is down - any chance of getting hold of it?

Hamish

[a.fu...@lqt.it]

On Thu, 1 Nov 2012 07:05:17 -0700 (PDT), hamish keith wrote:
> I wanted to download your 'clean project' as I am sure I can work it
> out but I note it is down - any chance of getting hold of it?
>

Hi Hamish,

you are probably working on some really archaic version, or
using completely outdated documentation ;-)

the SpatiaLite project isn't "down" at all: happily it's
well alive, continuously growing and still under full active
development.

the main Web page is now:
https://www.gaia-gis.it/gaia-sins/

here you can find the latest "stable" version:
https://www.gaia-gis.it/fossil/libspatialite/index

and here is the still experimental brand new v.4.0:
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.0.0-RC1

and finally you can easily get the latest snapshot version of the code
from the Fossil repository; here you'll find a quick how-to guide:
http://www.gaia-gis.it/gaia-sins/about-fossil.html

bye Sandro




--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

[hamish keith]

Awesome!  thank you so much.  I am still getting errors when building in XCODE 4.x but am now down to 2 (both of them are not recognising sqlite3 type).  I am going to start again and see if I can get it going.  

Naturally any tips are so appreciated but I hope that having an up to date library will help ;-)

thanks

Hamish

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.

To post to this group, send email to spatialite-users@googlegroups.com.
To unsubscribe from this group, send email to spatialite-users+unsubscribe@googlegroups.com.

[hamish keith]

Hi.  Sorry to be a nag but now I am just totally frustrated.  I am getting the libraries to compile and the console is returing me  SpatiaLite version ..: 2.3.1 Supported Extensions: - 'VirtualShape' [direct Shapefile access] - 'VirtualText [direct CSV/TXT access] - 'VirtualNetwork [Dijkstra shortest path] - 'RTree' [Spatial Index - R*Tree]  .....

BUT when I run a query it fails to prepare in both the iphone emulator AND and iphone itself.  Catching the error simply says that function GLength does not exist.

It hurts me to say but does anyone know of a idiots guide for xcode 4.5 and iOS6?

Hamish

[Triplecat]

Hi Hamish,
I am new to this, but in your original post you mentioned that you compiled SpatiaLite without  PROJ and GEOS libraries. As far as I know, PROJ contains the list of cartographic projections library that would be required for spatial queries, and GEOS is the geometry engine that would include spatial functions and operators. Maybe that is where the GLength function is stored. Anyway, just thought I would add my two cents, not sure if I am correct at all on this one.
Jen

Hamish

To post to this group, send email to spatiali...@googlegroups.com.
To unsubscribe from this group, send email to spatialite-use...@googlegroups.com.

[a.fu...@lqt.it]

Hi Jen,

> I am new to this, but in your original post you mentioned that you
> compiled SpatiaLite without PROJ and GEOS libraries.
>

compiling libspatialite disabling PROJ and GEOS is a legitimate option;
anyway, you should be well conscious that this way you'll get a
severely
"gelded" libspatialite, still supporting the basic minimal core but
completely lacking any sophisticated Spatial Analysis capability.

> As far as I know, PROJ contains the list of cartographic projections
> library that would be required for spatial queries
>

not exactly true; the list of 4000+ geodesic parameters corresponding
to the EPSG dataset are simply data, and are actually stored into the
SPATIAL_REF_SYS metadata tables.
the PROJ.4 library is absolutely required in order to compute a
reprojection
from some Spatial Reference System (SRS) to a different one.
in SQL terms; omitting to link libproj will completely disable
ST_Transform()
and few other functions (e.g. the ones supporting KML)

> GEOS is the geometry engine that would include spatial functions and
> operators.
> Maybe that is where the GLength function is stored.
>

absolutely right; ST_Length(), ST_Area(), ST_Intersects(), ST_Buffer()
and
many other Spatial SQL functions are fully based on GEOS; omitting to
link
libgeos will automatically disable all them.

an useful resource to be checked for a complete reference:
http://www.gaia-gis.it/gaia-sins/spatialite-sql-4.0.0.html

the most recent version of the documentation supporting Spatial
SQL functions now clearly shows (using a "color-code") which
specific module is absolutely required in order to activate each
single function. e.g.:
- ST_GeomFromText() depends on the "base" module, i.e. it should
surely be supported even in a minimal core configuration
- ST_Union() depends on the "GEOS" module, i.e. disabling GEOS
will surely disable ST_Union

[Aaron]

Hi Sandro,

I've been looking for a step-by-step guide to build the latest version of Spatialite (3.0.1 amalgamation), GEOS (grabbed the nightly build) and PROJ.4 (4.8.0) on the iOS platform. Right now I've been using the following instructions that are quite outdated:

http://spatialteam.blogspot.com.au/2011/04/building-spatialite-for-iphone-ios.html

When I attempt to add the source files for GEOS, and PROJ.4 it is not exactly clear which files from those downloaded are meant to be integrated into the project. Right now when I add the /src folder of the PROJ.4 Xcode (4.5) asks me to provide some sort of make file for the code base. I don't know exactly why.

Anyway, much of this is over my head right now because I'm still figuring my way around Xcode. 

In your opinion, if we were able to get Spatialite built for the iOS platform would it be reliable? You mention that compiling PROJ and GEOS gives you a "gelded" libspatialite. Why is that? What issues could we be facing if we went this route?

Also, Lionel seems to have gotten the closest to this but his projects are nearly a year old and re-working them with the latest version is proving difficult. Do you have any idea how he achieved this? 

Thanks,

- Aaron

[a.fu...@lqt.it]

Hi Aaron,

> I've been looking for a step-by-step guide to build the latest
> version
> of Spatialite (3.0.1 amalgamation), GEOS (grabbed the nightly build)
> and PROJ.4 (4.8.0) on the iOS platform. Right now I've been using the
> following instructions that are quite outdated:
>

I'm really sorry, but I have absolutely no idea about all this.
I've never used an iOS device in my life, and I've never attempted
to build anything for this specific platform.
My personal ignorance is absolute, so I cannot say nothing useful.

> In your opinion, if we were able to get Spatialite built for the iOS
> platform would it be reliable? You mention that compiling PROJ and
> GEOS gives you a "gelded" libspatialite. Why is that? What issues
> could we be facing if we went this route?
>

there is an obvious misunderstanding here: I said exactly the opposite.

<<disabling PROJ and GEOS is a legitimate option; anyway, you should be
well conscious that this way you'll get a severely "gelded"
libspatialite>>

i.e. you'll surely get a "gelded" (=limited) libspatialite if you
*omit*
including (=disable) PROJ and/or GEOS in your build process.
but if you actually include (=enable) both libraries I see no reason at
all suggesting this would be an unreliable or "gelded" configuration.