Back to main SpatiaLite page

good willing testers can download the pre-built executable binaries for Windows from the following URLs:
Windows 32 (x86)
Windows 64 (amd64)

---

news about June 2021 mid term updates

• Supporting FreeXL 2.0
  • Freexl 2.0 is now able to directly access spreadsheets based on modern XML formats.
    • this applies to MS Excel spreadsheets identified by the file suffix .xlsx
    • but it applies also to Libre/Open Office Calc spreadsheets identified by the file suffix .ods
  • Changes affecting SpatiaLite:
    • Virtual Tables based on the VirtualXL driver can now indifferently access .xls, .xlsx or either .ods spreadsheets.
      Format recognition is directly based on the file suffix.
    • The same applies to the SQL Function ImportXLS()
• Removing any functional dependency between mod_spatialite and libsqlite3
  • mod_spatialite being a loadable extension module to SQLite shouldn't have any functional dependency to libsqlite3
  • however for historical reasons the extension module called few SQLite's API not supported by the mirrored API interface provided by the loading process
  • this required the practical need for explicitly linking libsqlite3, a situation easily leading to logical conflicts and possible instability caused by two conflicting copies of the same library (may be of different versions or built by different compilers with different runtime support) in the same process.
  • now any SQLite's API not supported by the mirrored API interface has been completely removed, and mod_spatialite no longer depends on libsqlite3.
    this API cleanup interests the following facets of SpatiaLite:
    • removing any reference to sqlite3_rtree_query_callback():
      • this caused the definitive deprecation of the KNN module that is no longer supported, being replaced by KNN2 (please see below).
        you can learn more about the sterilization of KNN on this specific Wiki Page
      • as a side effect the SQL Function GetSpatialIndexExtent() too was definitely removed being based on the same API
    • removing any reference to sqlite3_rtree_geometry_callback(): this caused the final removal of the following SQL Functions (collectively known as GEOCALLBACKS) that are no longer supported:
      • RTreeWithin()
      • RTreeContains()
      • RTreeIntersects()
      • RTreeDistWithin()
      • Note: all the above SQL Functions were deprecated since many years and the GEOCALLBACKS build option was kept disabled by default.
    • removing any reference to sqlite3_enable_load_extension(): this API was called just in a single point by the Stored Preocedures module, and only when processing deeply nested Procedures.
      BEWARE: now executing complex Stored Procedures could eventually fail on mod_spatialite. Using the command line tool spatialite or the GUI tool spatialite_gui is warmly recommended for executing complex Stored Procedures

  • Note well: now mod_spatialite itself does not depend any more on liqsqlite3 and is fully based on the mirror API passed by the loading process. However this does not implies that dynamically loading mod_spatialte will not require to load in turn libsqlite3, because this is a dependency imposed by the PROJ library and there is absolutely nothing that mod_spatialite itself can do so to avoid such potentially harmful issue. The first preliminary tests seem to show that this will not probably be a serious cause of instability, but more extended tests are certainly required, most notably when using language connectors such as on Java, Python, PHP, C# .Net and alike.

• Supporting the brand new KNN2 module that is intended to be a more efficient full replacement to the previous KNN that is now deprecated.
  • Please read the Wiki Page about VirtualKNN2

---

Back to main SpatiaLite page