MapServer icon indicating copy to clipboard operation
MapServer copied to clipboard
verified publisher icon MapServer

GetFeatureInfo works only for first record in FlatGeobuf TILEINDEX (MapServer 8.6.0-beta2)

Open MathewNWSH opened this issue 2 weeks ago • 1 comments

Hi all,

MY MAPFILE: https://pastebin.com/6A98L6V7 I am running into an issue with WMS GetFeatureInfo when using FlatGeobuf (FGB) as a TILEINDEX source in MapServer. The problem appears to be related to how MapServer / OGR handles multiple records inside a FlatGeobuf tile index.

Environment:

  • MapServer: 8.6.0-beta2
  • GDAL: 3.12.0
  • PROJ: 9.7.0
  • OS: Debian Bookworm (Docker)

TileIndex structure: I am using FlatGeobuf as a tile index, with a schema similar to a classic shapefile tile index. The TILEITEM column is called "location" and contains both the file path and the layer name, separated by a comma:

location data/CLMS_UA_LCU_S2021_V025ha_BA001L1_SARAJEVO_03035_V01_R01_20250523.fgb,CLMS_UA_LCU_S2021_V025ha_BA001L1_SARAJEVO_03035_V01_R01_20250523 data/CLMS_UA_LCU_S2021_V025ha_AT001L3_WIEN_03035_V01_R01_20250418.fgb,CLMS_UA_LCU_S2021_V025ha_AT001L3_WIEN_03035_V01_R01_20250418

Each referenced FlatGeobuf file contains exactly one vector layer, and the layer name matches the name provided after the comma in the tile index.

Problem description:

  • I have vector layers configured in MapServer using CONNECTIONTYPE OGR with TILEINDEX pointing to an FGB file.
  • The layers are only visible at large scales (MAXSCALEDENOM 300000), where vector data is queried.
  • When issuing a WMS GetFeatureInfo request at an appropriate zoom level:   - GetFeatureInfo works correctly for features coming from the FIRST record in the tile index.   - Features coming from any subsequent tile index record never return GetFeatureInfo results.
  • The request itself is valid (correct bbox, x/y, tolerance, scale), and rendering works correctly   for all tiles — only GetFeatureInfo is affected.

Additional observations:

  • Reordering records inside the FlatGeobuf tile index changes which dataset GetFeatureInfo works for.   Whichever record is first starts working; the others stop working.
  • If I bypass the tile index and connect directly to a single FlatGeobuf file using:   CONNECTION "path/to/file.fgb"   DATA "layer_name"   then GetFeatureInfo works as expected.
  • To further isolate the issue, I created a separate MapServer layer only for the Vienna dataset   (the dataset affected by the problem), with an explicit CONNECTION and DATA pointing directly   to the FlatGeobuf file and its internal layer name (no TILEINDEX involved).
  • In this setup, with the layer name explicitly defined, GetFeatureInfo works correctly and   consistently for Vienna features.
  • This strongly suggests that the problem is not related to the data itself, styles, templates,   or scale settings, but specifically to the use of FlatGeobuf as a TILEINDEX source during   GetFeatureInfo processing.
  • It appears that during GetFeatureInfo MapServer / OGR only evaluates the first tile index   record and does not properly iterate over or reset OGR datasets for subsequent records,   especially when different internal layer names are involved.

My suspicion is that this may be a limitation or bug in how FlatGeobuf is handled as a TILEINDEX source, particularly for GetFeatureInfo requests.

Has anyone encountered similar behaviour when using FlatGeobuf tile indexes with GetFeatureInfo, or can confirm whether this is a known limitation in MapServer or GDAL/OGR?

Thanks, Marcin

MathewNWSH avatar Dec 12 '25 11:12 MathewNWSH

@MathewNWSH are you able to confirm if this is particular to FlatGeobuf or if it also occurs using other CONNECTIONTYPE OGR tpyes e.g. a Shapefile or GeoPackage?

geographika avatar Dec 12 '25 17:12 geographika

Hi @geographika I'll test it today

MathewNWSH avatar Dec 15 '25 08:12 MathewNWSH

I confirm that the same problem occurs while using paths to gpkg within tile index @geographika

MathewNWSH avatar Dec 15 '25 13:12 MathewNWSH

@geographika @rouault FastCGI worker segfaults (signal 11) during WMS GetFeatureInfo on UA_2021 when the tile index is FlatGeobuf.

Environment: MapServer 8.6.0-beta2 (built via pdok/mapserver-docker), EPSG:3035 data; tileindex index_2021gpkg.fgb pointing to UA 2021 tiles (FGB/GPKG).

Repro request: http://localhost/ogc?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&BBOX=2797598.45374493347480893,4796236.73384895455092192,2841832.62160093011334538,4827427.94153871666640043&CRS=EPSG:3035&WIDTH=892&HEIGHT=1265&LAYERS=UA_2021&QUERY_LAYERS=UA_2021&INFO_FORMAT=text/html&I=227&J=548&FEATURE_COUNT=10 (Point falls on code_2021=13100 in the Wien layer.)

Log evidence (/home/mniemyjski/mapserver.log):

  • unexpected end-of-file (perhaps the fastcgi process died): pid: 14 socket: unix:/tmp/mapserver-fastcgi.socket-7
  • child signalled: 11
  • Just before crash: GDALOpen(...CLMS_UA_LCU_S2021_V025ha_BA001L1_SARAJEVO_03035_V01_R01_20250523.fgb) succeeds as FlatGeobuf and msOGRFileWhichShapes: Setting spatial filter ....

Workaround: Switch the tile index to GPKG: TILEINDEX "index_2021gpkg.gpkg". After this change the same GetFeatureInfo returns HTML correctly.

Hypothesis: Segfault is triggered by using FlatGeobuf as a tileindex (FGB pointing to FGB/GPKG) in GetFeatureInfo in 8.6.0-beta2.

MathewNWSH avatar Dec 15 '25 14:12 MathewNWSH

everything works after switching to gpkg as a vector index: https://mapserver.dataspace.copernicus.eu/ogc

MathewNWSH avatar Dec 16 '25 14:12 MathewNWSH