`msOGRFileOpen: Spatialite support in GPKG not enabled` with LogLevel `DEBUG 0` about mapserver HOT 9 CLOSED

according to the documentation this message shout appear at level 1:

fair enough. Addressed per #7062

from mapserver.

What do you get with

ogrinfo -dialect SQLite -sql "select spatialite_version()" [any_datasource]
where any_datasource can be any existing datasource (.json, .shp or whatever).

from mapserver.

ogrinfo -dialect SQLite -sql "select spatialite_version()" gpkg_test.gpkg
INFO: Open of `gpkg_test.gpkg'
      using driver `GPKG' successful.
ERROR 1: In ExecuteSQL(): sqlite3_prepare_v2(select spatialite_version()):
  no such function: spatialite_version

ogrinfo -dialect SQLite -sql "select spatialite_version()" gpkg_test.json
INFO: Open of `gpkg_test.json'
      using driver `GeoJSON' successful.
ERROR 1: In ExecuteSQL(): sqlite3_prepare_v2(select spatialite_version()):
  no such function: spatialite_version

Note: gdal was compiled without libspatialite as it is only needed for writing ( https://gdal.org/drivers/vector/sqlite.html#using-the-spatialite-library-spatial-extension-for-sqlite )

from mapserver.

So do you mean that the message about not enabled Spatialite should not be logged at debugging level 0? There are no errors in rendering?

from mapserver.

yes, since it is not an an error (in this case) it sholud not been printed on DEBUG 0 (Errors only)

from mapserver.

I agree. Could you try to edit the description and title to make it clear what is wrong?

from mapserver.

I feel this log message is appropriate. The lack of Spatialite support for GeoPackage will make some filtering operation slower

from mapserver.

I feel this log message is appropriate. The lack of Spatialite support for GeoPackage will make some filtering operation slower

ok, that is a nice information, to speed up the service. but ist not an error that prevents the service functionality.

according to the documentation this message shout appear at level 1:
Level 1 includes all output from Level 0 plus msDebug() warnings about common pitfalls, failed assertions or non-fatal error situations (e.g. missing or invalid values for some parameters, missing shapefiles in tileindex, timeout error from remote WMS/WFS servers, etc.)

from mapserver.

@rouault can you explain which filter operations are slower with the MapServer in GeoPackages without libspatialite? Are these relevant for WMS services (BBOX filter) or only for special WFS filter requests (Interstects etc.). Thanks.

from the GDAL doc:

Explicit linking against SpatiaLite library also provides access to functions provided by this library, such as spatial indexes, spatial functions, etc...

Does that really mean that without libspatialite no geometry index is used?

sorry, it goes further: According to the SpatialLite documentation [q], the data query must be specially adapted so that a SpatialIndex can be used. Does the MapServer do this automatically or does the creator of the MapFile have to take this into account?

from mapserver.