geos_ts_c.cpp + spatialite Error

Question

select distance(T1.Geom,T2.Geom) as Distance, T1.POI_ID, T2.LINK_ID from temp1 as T1, temp2 as T2 where T1.POI_ID = T2.POI_ID AND Distance < 100

temp1 having point geometry temp2 having line geometry

While I running above query through C# program I am getting Error ::

Assertion failed !

Program: ... File: geos_ts_c.cpp Line : 3472

(look attached snapshot)

I am having database in .db format. I am using SQLlite and spatialite for gis functionality.

From code ::

I am loading spatialite.dll and then with sqllitecommand running query..

ExecuteStatement("select load_extension('spatialite.dll')", con); SQLiteCommand selectCommand11 = new SQLiteCommand(selectSQL10, con); SQLiteDataReader dataReader10 = selectCommand11.ExecuteReader();

anybody have idea why I am getting this error ? and how can i resolve this ?

Answer 1

Final Comments ::

Hello Sandro,

Before some minutes I found one inlogical solution. (But can't
confirm because I am doing Testing right now)

Previously while each query run I was making connection to database
and closing it after use. (To save the garbage)
And each time loading 'spatiallite.dll'.

The solution most usually adopted by C or Java apps is exactly the one to open a DB connection immediately (at the very beginning of your own code), then closing this connection just before terminating the program and exiting. And to always use/re-use the same connection for all SQL queries executed by your code. Opening a new connection surely has a cost; thus perfoming many times a connect-disconnet cycle will certainly have a very bad performance impact. That's not all: each SQLite connection has its own page cache; repeatedly creating and destroying the connection will obviously negate any possible "optimization effect" coming form using a page-cache. A possible explanation about the many "memory issues" you were experiencing: - C# is based on garbage collection - but C components (as the sqlite / spatialite / GEOS DLLs) will anyway continue to use good, old, plain dynamic memory allocations based on classic malloc/free explicit calls and is exactely on the basis of this very simple considerations that I'm not a fan of C#; because this way you'll mix more or less at random very different memory allocation schemas, may be creating fatal "corrupted" conditions. - repeatedly opening/closing the connection could effectively create chaos between conflicting memory allocation strategies.

**I removed 'middle connection opening and closing, and also loading of
extension'.**

yes, this definitely seems to be the optinal approach. bye Sandro