Skip to content

Hide the geometric property in GpfDescribeType - #176

Draft
LionelZoubritzky-IGN wants to merge 1 commit into
mainfrom
82a/hide_geometry_from_describe
Draft

Hide the geometric property in GpfDescribeType#176
LionelZoubritzky-IGN wants to merge 1 commit into
mainfrom
82a/hide_geometry_from_describe

Conversation

@LionelZoubritzky-IGN

Copy link
Copy Markdown
Contributor

Mitigation to #82: this PR proposes hiding the geometric property from the output of GpfDescribeType. This way, the LLM should not believe it can query the geometry as part of the select.

The error messages dedicated to the case where the LLM does ask for the geometry in the select are still kept, just in case the LLM somewhat guesses the underlying provider is WFS and that it should be able to obtain the geometry by asking for it.

@LionelZoubritzky-IGN LionelZoubritzky-IGN added the enhancement New feature or request label Jul 23, 2026
@LionelZoubritzky-IGN LionelZoubritzky-IGN linked an issue Jul 23, 2026 that may be closed by this pull request
Base automatically changed from 160/stateless-proxy to main July 24, 2026 12:37
@LionelZoubritzky-IGN
LionelZoubritzky-IGN force-pushed the 82a/hide_geometry_from_describe branch from 9374f49 to e702431 Compare July 24, 2026 13:05
@esgn

esgn commented Jul 27, 2026

Copy link
Copy Markdown
Member

The change itself is correct and well-targeted: the LLM never actually needs the geometry column name or its CRS (spatial filters are compiled internally from getGeometryProperty, and derived geometry goes through spatial_extras), and hard validation of select already exists in properties.ts. Three remarks:

  1. Information loss to consider: the geometry type disappears entirely. The output previously let the LLM know whether a type carries points, lines or polygons : useful to answer user questions or to judge whether centroid/bbox spatial extras make sense. I also worry about non geometric table like wfs_scot:doc_urba : how will the LLM make a difference between geometric table and non geometric table.

  2. defaultCrs is still in the published output schema. gpfPropertySchema (GpfDescribeTypeTool.ts:33) still advertises a field described as "the default CRS if the property is geometric", but geometric properties can no longer appear in the output. The published contract now contradicts the behavior and wastes tokens on every tool listing. defaultCrs should be removed from the schema and docs/mcp-tools.md regenerated (npm run docs:mcp).

  3. (minor) The "non-geometric" predicate now lives in three places. The filter(p => ! p.defaultCrs) in the tool duplicates buildSelectList (properties.ts:153-155), whose inverse is getGeometryProperties. Since properties.ts is meant to centralize geometry lookup, exporting a small getNonGeometryProperties(featureType) helper and using it in both places would keep the definition of "geometric = has defaultCrs" in a single module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

gpf_wfs_get_features - why rejecting geometry in select?

2 participants