edgar soldin wrote:
> yes. DBQuery seems to insist on having the parameter > "spatialite=mod_spatialite". seems like it does > not enable the autoloading. > Larry: any reason for that? I think it is the right thing to do because the key feature of DB Query is that it is robust. It can read and convert Spatialite BLOBs into JTS features with plain java without any native binaries. If user wants to enjoy extra features of the Spatialite extension and tolerate the pain of the dll hell it is not a big deal to add "?spatialite=mod_spatialite" to the connection string. The user interface may not be the most user friendly but the UI is the same for all databases. SQLite driver could of course try automatically if mod_spatialite is available and start in plain java mode if it is not but there can be other useful SQLite extensions as well. In the blog post http://openjump.blogspot.fi/2014/02/openjump-and-geopackage-part-2-spatial.html I show how DB Query can load the libgpkg extension instead of mod_spatialite. There may be other useful SQLite extensions around and with the simple while not most user friendly approach DB Query supports them all. It happens also that mod_spatialite is available but is just does not work. If there was an automatic detection of mod_spatialite users should still have a possibility to prevent it from loading. If someone gets interested in making the DB Query more user friendly there could be an UI component for editing the dbquery.properties file. -Jukka Rahkonen- ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
