Skip to content

Reduce GpfDescribeType output - #189

Open
LionelZoubritzky-IGN wants to merge 5 commits into
mainfrom
split-describe-tool
Open

LionelZoubritzky-IGN wants to merge 5 commits into
mainfrom
split-describe-tool

Conversation

@LionelZoubritzky-IGN

@LionelZoubritzky-IGN LionelZoubritzky-IGN commented Aug 14, 2026 •

Copy link
Copy Markdown
Contributor

Since #142, the output of GpfDescribeType is very lengthy. In practice, the LLM reads the output of GpfDescribeType into a file, then greps it for the terms it is looking for... so, the full schema seems to be a bit too much for it to handle.

This PR is a compromise: we provide a summarized schema, with only:

  • the typename (currently missing because of the OGC API Features specifications).
  • the full description of the type.
  • the list of non-geometric properties, themselves summarized to only keep:
    • their name,
    • their description,
    • their list of values (oneOf) when it exists. Only the const field is kept.
  • the unique geometry kind (polygon, point-or-multipoint, any, ... extracted from the format field of the store schema, removed the "geometry-" prefix). When no geometry or multiple geometries without a "primary-geometry", this field is undefined.
  • the list of required non-geometric properties.
  • the "x-ign-selectionCriteria" field when present in the upstream schema.

Note that this is rather close to what we had pre-#142, but the URL is a nice bonus because now the LLM can fetch more info if need be. In the end, what's missing from the returned output and only present in the schema is:

  • the "x-ign-representedFeatures" fields, which are usually redundant with the name and descriptions of the fields;
  • the title of the properties and of their const, which is vastly redundant with the name of the property / const and with its description.
  • the description of the const fields. Those may be relevant in some contexts, but I haven't seen it used in my tests so far.

I initially intended to provide a second tool (GpfDescribeTypeDetails added in 902d478 and removed in 8609708) but I observed during testing that this tool was never called, even when querying something as niche as "Fonds de taille" or "Darce", which never appears in the output of GpfDescribeTool. GpfSearchTypes is actually enough to orient the LLM towards the right type, and GpfDescribeType is basically only here to provide the name of the properties and to give precisions on what is described by what, to prevent the LLM from hallucinating answers. So, the LLM never really needs the additional data provided by GpfDescribeTypeDetails; and if it ever does, it can still fetch the full schema by URL.

@LionelZoubritzky-IGN LionelZoubritzky-IGN changed the title Reduce GpfDescribeTool output Reduce GpfDescribeType output Aug 21, 2026
Base automatically changed from 142-gpfschemastore0.2.0 to main September 21, 2026 12:19
@esgn
esgn requested a review from mborne September 28, 2026 08:20
@LionelZoubritzky-IGN
LionelZoubritzky-IGN changed the base branch from main to 136/more-spatial_extras September 30, 2026 10:34
@LionelZoubritzky-IGN
LionelZoubritzky-IGN changed the base branch from 136/more-spatial_extras to closedWorldAnnotation September 30, 2026 10:52

@mborne mborne left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

Comment thread test/integration/level1-protocol/describe.test.ts
@esgn
esgn force-pushed the closedWorldAnnotation branch from 95b2670 to 5378e59 Compare October 1, 2026 13:26
Base automatically changed from closedWorldAnnotation to main October 1, 2026 14:10
@LionelZoubritzky-IGN
LionelZoubritzky-IGN force-pushed the split-describe-tool branch 2 times, most recently from ece1d1b to 3523b4a Compare October 1, 2026 15:01
@esgn

esgn commented Oct 2, 2026 •

Copy link
Copy Markdown
Member

Ok so you're removed :

At type level :

  • $schema : It tells the LLM the document is a JSON schema. Without it how to understand format: date for example ?
  • "type":"object" : Ok. Same value in all responses. Unless it's a blocker in JSON schema.
  • title : unsure about this one
  • x-ign-theme : IGN thematic groups. Not useful for the moment.
  • x-ign-representedFeatures : unsure about this one. It gives additional information about the type meaning and lineage. Would be inclined to keep it. This way the LLM can provide further knowledge about the type.

For non geometric properties:

  • type: integer, ...: I would keep it. Isn't it useful for the LLM to write where and order_by params ? For example : { "property": "construction_legere", "operator": "eq", "value": "true" } or { "property": "nombre_de_logements", "operator": "gt", "value": "10" }
  • format (date or date-time) : Probably a good idea to keep it ? { "property": "date_d_apparition", "operator": "gte", "value": "2000-01-01" } => a json schema date.
  • title : Ok why not. Don't know if if really helps the LLM. Probably not.
  • x-ogc-role : In our case primary-geometry is everywhere and not useful. However id could help identify the object unique identifier.

For non geometric properties enums (oneOf):

  • title: almost always equals to const. Would it be better to remove const and keep title ?
  • description : would definitely keep it. Remember the whole game is about data discovery first. Enum values descriptions may contain precious information.
  • x-ign-representedFeatures : For indifférenciée knowing what kind of objects are grouped under this nature is quite useful don't you think ?

@mborne => I'd like your opinion here based on the tests you've conducted on your part.

@esgn esgn added help wanted Extra attention is needed more tests needed more-tests-needed labels Oct 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

help wanted Extra attention is needed more tests needed more-tests-needed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants