Frequently Asked Questions

The raster WMS (/wms-r/wms) declares a maximum of 5010 pixels per side and rejects anything larger, with an error that misleadingly reads “Layer … unknown”. The vector WMS (/wms-v/ows) declares no limit; images 16384 pixels wide rendered in our tests (2026-11-06). The wrapper passes your width and height on without capping them at these limits. If you need a larger area, split your bounding box into smaller tiles.

The raster WMS also answers the occasional valid request with the same “Layer … unknown” error; retrying usually works.

How do I get full-resolution WMS images?

Each pixel covers:

ground per pixel = bbox width (or height) / pixel width (or height)

If your bbox covers a large area, each pixel spans more ground and the image is effectively downsampled. For example, the orthophotos (HR.ORTHOIMAGERY.ORTHOPHOTOS, about 0.3 m per pixel) render every source pixel in a 5010-pixel image only if the bbox is no wider than about 5010 × 0.3 m ≈ 1.5 km. A wider bbox still works but returns a downsampled image. Asking for more pixels than that gains nothing: where the native resolution is known, the wrapper lowers width and height to match it.

Why do some WMS layers return blank images?

Layers on the raster WMS declare the scale range they render in. The wrapper records the coarsest end as a minimum zoom level: the orthophotos start at zoom 6, some detailed layers only at zoom 14 or higher. The interactive map shows a warning when the active layer needs a higher zoom level.

Layers on the vector WMS declare no range, but some stop rendering when zoomed in very close: the BD TOPO buildings layer is blank finer than about 0.17 m per pixel (roughly zoom 19), while the cadastral layers still render. If you use the API directly and get a blank image, try a bbox that fits the layer's scale: smaller if you are zoomed out too far, larger (or fewer pixels) if you are zoomed in too close.

Which services are here

Why is this not part of the INSPIRE wrapper?

The Géoplateforme WFS is a conformant INSPIRE download service, but its feature types are IGN's national data models (BDTOPO_V3, BDCARTO_V5, ADMINEXPRESS-COG, CADASTRALPARCELS.PARCELLAIRE_EXPRESS, BAN-PLUS, …), not the INSPIRE application schemas. The INSPIRE wrapper admits a WFS only when its data is in the INSPIRE vocabulary, so the national data lives here, with class and property URIs of its own. Other French publishers' national-model services (Shom, BRGM, Sandre, the regional GeoServers) are not here either.

Web Feature Service (WFS)

How do I filter WFS features (keyword search, attribute queries)?

/wfs?s={service}&typenames={type}&eq={property}:{value} selects the features whose property equals the value; like={property}:{pattern} matches a pattern (* any string, ? one character, case-insensitive). The value follows the last colon, so the property may be a path into nested objects with its own prefix colons. A bbox may be added; without one the query runs over the whole service. count/offset and the format suffixes work as usual. The wrapper turns this into one OGC Filter Encoding 2.0 (FES) document — with the bbox folded in as fes:BBOX, because a WFS 2.0 server rejects the KVP BBOX and FILTER parameters side by side.

Keyword search: communes whose name contains "Saint-Malo"

GET /wfs?s=https://data.geopf.fr/wfs/ows&typenames=ADMINEXPRESS-COG.LATEST:commune
    &like=ADMINEXPRESS-COG.LATEST:nom_officiel:*Saint-Malo*

Property names for a type follow from its features (or from /wfs?s={wfs-uri}&typenames={type}, the type's metadata page).

Exact match: the commune with INSEE code 75056 (Paris)

GET /wfs?s=https://data.geopf.fr/wfs/ows&typenames=ADMINEXPRESS-COG.LATEST:commune
    &eq=ADMINEXPRESS-COG.LATEST:code_insee:75056

Namespace prefixes

Each prefix in the property path is declared from the service's own namespace list (the one it advertises for its feature types); the exact xmlns declarations sent upstream are in the document's PROV (prov:hadPrimarySource, the upstream GetFeature URL). An unknown prefix is a 400.

Raw FES: filter=

A hand-written FES 2.0 document, URL-encoded, forwarded as the upstream FILTER parameter unchanged — for anything eq/like cannot express (ranges, fes:And/fes:Or, spatial operators). Declare your namespaces yourself, and do not combine it with bbox: the upstream rejects the pair (put a fes:BBOX inside your filter instead). filter, eq and like are alternatives.

GET /wfs?s=https://data.geopf.fr/wfs/ows&typenames=ADMINEXPRESS-COG.LATEST:commune
    &filter=<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0"
                  xmlns:a="http://ADMINEXPRESS-COG.LATEST">
               <fes:PropertyIsGreaterThan>
                 <fes:ValueReference>a:population</fes:ValueReference>
                 <fes:Literal>200000</fes:Literal>
               </fes:PropertyIsGreaterThan>
             </fes:Filter>

How do I access older data (temporal access)?

Memento (RFC 7089)

A /wms layer with a time dimension supports Memento-style temporal negotiation: its URI is the original resource (latest data) and acts as its own TimeGate. Send an Accept-Datetime: Thu, 25 Jun 2020 12:00:00 GMT header and the wrapper replies 302 to the corresponding memento — the same URI with a time= component identifying a 30-day window ending at the requested date. time= is memento URI syntax minted by the TimeGate, not a query knob. Memento responses carry Memento-Datetime and a Link (rel="original timegate") header.

Why does loading a feature by ID fail for some services?

At discovery time the wrapper probes each WFS service to determine which lookup method it supports. Services that advertise the standard stored query receive:

…?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature
  &STOREDQUERY_ID=urn:ogc:def:query:OGC-WFS::GetFeatureById
  &ID=commune.1

All other services receive the standard RESOURCEID parameter instead. A service may fail either request; the wrapper then answers with the upstream's own error, in the response and in its PROV.

Feature panel

What do the properties in the feature panel mean?

Property labels

Property keys are URIs from the wrapper's vocabulary for the feature type's data model, or standard RDF predicates (rdf:type, owl:sameAs, …) for SPARQL results. Full URI keys are shown as their local name (the part after # or the last /); clicking opens the definition. CURIE-style keys such as rdf:type expand to their full URI and link likewise.

rdf:type

Present on all WFS features. The value is a link to the feature type definition in the local vocabulary. For SPARQL DESCRIBE results the type URI from the upstream RDF graph is shown directly.

_droppedGeometry

A GML geometry element in the response uses a type not yet supported by the viewer. The value is the unsupported element name (e.g. Tin, Grid, LinearGrid). The feature is shown without geometry.

Why are geometries different across RDF/XML, Turtle, and GeoJSON-LD?

The RDF/XML and Turtle outputs carry geometry as a locn:geometry XML literal containing the raw GML in the upstream coordinate reference system (e.g. EPSG:2154). The GeoJSON and JSON-LD outputs project all coordinates to WGS 84 and encode the geometry as a GeoJSON object, so the three representations are not graph-isomorphic.

What is the Upstream link in the link area?

After loading features, the link area shows an Upstream link pointing directly to the source service request that produced the result — for example the WFS GetFeature call. This lets you inspect or replay the raw upstream response independently of the wrapper.

Access

Why do I see 429 Too Many Requests errors?

To protect the upstream services from excessive load, rate limiting is in place: each IP address may make 50 requests per 10 minutes. The allowance refills continuously, so after hitting the limit you regain roughly one request every 12 seconds. Requests over the limit receive HTTP status 429.

Registered heavy users can bypass the limit with an API key, sent as an HTTP header:

Authorization: Bearer <your-api-key>

Contact the operator (see below) to request a key.