Larry Reeder wrote: > On Mon, Apr 8, 2013 at 1:03 PM, <edgar.sol...@web.de> wrote: > On 08.04.2013 20:48, Michaël Michaud wrote: >> > Just wanted to share this thought, but I admit that Spatialite is > > a mature project which can add nice capabilities with a smaller >> > effort. >> ok, as far as i understand for now. DBQuery is working and in use. it uses >> native libs, but on the other hand we will probably not get this >> functionality going java only. >> so, let's polish up native libs and DBQuery and consider to add it to PLUS >> after 1.6.0. > > One clarification: my plugin doesn't directly load native libraries. It > uses the sqlite JDBC libraries, which handle the loading spatialite and other > sqllite extensions. I also share some of the same concerns that Michaël > mentioned, and think that adding native libraries introduces risk and > complexity: > 1. A bug in the native libraries can cause the JVM to crash, taking down OJ > in the process (not just a stack trace but an outright crash. > 2. When done right, Java is write once, run everywhere. With native libs, > you have to provide a library version for each platform you are deploying to: > Windows 32bit/64bit, Linux 32/64, Mac OSX PowerPC/Intel, etc. > 3. Regarding the spatialite lib, you not only need to include the correct > version of that, but the correct versions of everything it depends on, > including proj, geos, sqlite, and others. > 4. Adding all these libs would reproduce in native code much of what OJ > already does in Java.
Good analysis. About 3), I use Spatialite myself very much and Spatialite versions and dependencies can make really bad problems. the Sqlite database file holds only the data and some metadata. All the intelligence is in the SQLite binaries and extensions. I can easily create a Spatialite data file which is utilizing advanced features like views with reprojected geometries (=instruction to use Proj4 library for doing on-the-fly re-projecting), simplifield geometries (=instruction to use GEOS library for doing on-the-fly simplifying), virtual network for routing (needs Spatialite virtual network module). However, if I send this database file to someone who has different binaries on his computer and compiled without Proj4, GEOS, Virtual network and others (or compiled with different version) he can't access these advanced features. Spatialite is not always even backward compatible. The only reason for me to accept all this mess is that Spatialite is so fast and works so well and when different computers and users have compatible binaries it is so handy to be able to copy and send the whole database with all the tables, views and indexes as a one single file. >> Larry: would you be willing to accept patches on the regard above? would be >> a good opportunity to reuse a native lib loader that i created for the RXTX >> using gps extension originally. > > Ede, I'm always open to new patches, I just don't think a native lib loader > is needed due to SQLite JDBC handling the loading. > Finally, the main purpose of the DBQuery plugin is to provide a bridge > between OJ and spatial databases that it might not support (if any now), as > well as provide a way to submit ad-hoc queries that don't have or need > backing tables to return features. While I'm glad my recent changes make it > more useful for spatialite users, adding all the native libs to support > spatialite would weigh it very heavily toward the spatialite side. If the > main goal is to improve spatialite, perhaps a better approach is to build up > the current sqlite/spatialite plugin to do so? I agree. DBQuery plugin is very robust because it does not try to be too clever. With Spatialite the robustness means that I can always read geometries and attributes from normal database tables and non-spatial attributes can be queried with SQL. This covers actually most use cases even I may lose some views and other features. The possibility to load Spatialite as extension is still a very good addition for advanced users. It is probably best not to deliver any native binaries with the plugin and just mention where to get some tested ones. Perhaps you could still include the SQLite JDBC driver in the zip? There is something that would perhaps need a patch and it is the "Unknown WKB type 0" problem. Almost everything I find from the web with that phrase seems to be related to OpenJUMP. But is it so that others do not have similar problems with reading multigeometries from Spatialite than I do? -Jukka Rahkonen- > -lreeder > > >> ..ede > > ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
