Hi, I have nothing at all to complain and I think that you managed to add the SQLite/Spatialite datastore very quickly. It just appears that in my Windows environment the mod_spatialite extension is not found if I put all the dll files into lib\ext which was the only place where I could make the SpatiaLite Plugin https://sourceforge.net/p/jump-pilot/code/HEAD/tree/plug-ins/SpatialitePlugin/ to find them.
I can see that if Spatialite is found then geometries are queries from the map viewport with ST_EnvIntersects. That is fine for limiting the number of features. However, for making the query fast you should consider using the spatial index if that exists. It is a bit complicated in Spatialite because it does not happen automatically. Documents https://www.gaia-gis.it/fossil/libspatialite/wiki?name=SpatialIndex and https://www.gaia-gis.it/fossil/libspatialite/wiki?name=switching-to-4.0 should help with it. I have been reading that loading extensions to SQLite can be tricky and for example SQLite may be compiled so that loading extension is strictly denied. We should not have that problem because we deliver also the sqlite jdbc driver that contains suitable sqlite build inside. Different Spatialite versions make also difference. If you are really interested in managing possible pitfalls I believe that browsing the source code and comments of the GDAL SQLite driver might be useful https://trac.osgeo.org/gdal/browser#trunk/gdal/ogr/ogrsf_frmts/sqlite. But based on your WKB, WKT, and Spatialite BLOB detection you have probably been reading it already and then you know also where to find the GeoPackage driver https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/gpkg. What is not handled anywhere that I have seen is the conflicts between 32 vs. 64 bit architectures. It would be very kind for the end users to send a clear message “WARNING: You are running OpenJUMP with {0} bit JRE but the {1} extension is compiled for {2} bit. Extension was not loaded”. I have no idea about how to detect the architecture of .dll or .so from java, though. -Jukka Rahkonen- Nicolas Ribot wrote: Jukka, The SQLite/Spatialite code in OJ is quite new and barely tested with all combinations of sqlite flavours. There is a lot of room for improvement, especially with regards to loaded extension. Currently, mod_spatialite loading is detected and a boolean is set to tell the code if spatialite functions should be used or not. It could be easy to add a component when creating the SQLite driver to tell if extension should be loaded or not. I'm a bit busy right but will look at these aspects soon. Nicolas On 15 December 2015 at 17:31, Rahkonen Jukka (MML) <jukka.rahko...@maanmittauslaitos.fi<mailto:jukka.rahko...@maanmittauslaitos.fi>> wrote: 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<mailto:Jump-pilot-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
