Home > FAQ

Frequently Asked Questions

Overview

Why the wrapper?

The INSPIRE geoservices are really cool. As geospatial data and services are special and complicated, they are quite difficult to discover and use. The wrapper sits between your browser and the upstream national services, handling several things:

Simplified bbox format
You supply bounding boxes as W,S,E,N (longitude/latitude), and the wrapper translates them to the axis order the upstream service expects (see FAQ: Bounding-box axis order).
Automatic CRS handling and reprojection
Upstream services use a range of coordinate systems: geographic (EPSG:4326, EPSG:4258) and projected (e.g. EPSG:28992 for NL, EPSG:25832 for DE regions, EPSG:3301 for EE, EPSG:3059 for LV). The wrapper always returns GeoJSON in WGS 84 (EPSG:4326), reprojecting from the upstream CRS server-side (see FAQ: CRS and projections, FAQ: EPSG:4258).
Image size calculation
For WMS requests the wrapper computes width and height from the bbox aspect ratio, respecting each upstream service's maximum pixel limit (see FAQ: Maximum image size).
CORS proxy
Upstream government WMS/WFS servers generally don't send Access-Control-Allow-Origin headers, so browsers would block direct cross-origin JavaScript requests. The wrapper proxies responses so the “Show on map” buttons and form submissions work.
Header injection
Some upstream services require specific HTTP headers such as Referer that browsers don't allow JavaScript to override; the wrapper adds them server-side.

What data do you provide?

Data is organised by NUTS region (country level and major/sub-region level where available).

WMS 1.3.0
Map images (PNG) for a bounding box. Append ?legend for the legend graphic.
WFS 2.0.0
Vector features in GeoJSON (WGS 84 by default), GML, RDF/XML, or Turtle. OGC Filter Encoding 2.0 supported (see FAQ: WFS filtering).
OGC API Features
Paginated access to curated collections (e.g. GISCO/Eurostat NUTS, LAU, Natura 2000).

What regions do you support?

The INSPIRE in your country page lists INSPIRE services for all EU member states.

See the regions list for current coverage. Not all EU member states are included: some require API key registration, some only offer download services or ATOM feeds rather than WMS/WFS, and some national geoportals are offline. Some services are HTTP-only and cannot be proxied from an HTTPS page.

Coordinates and projections

What are CRS, SRS, and projections?

A Coordinate Reference System (CRS) defines how coordinates map to locations on Earth. The OGC standards use the older term Spatial Reference System (SRS) for the same concept. The most common CRS is EPSG:4326 (WGS 84), which uses latitude/longitude in degrees — this is what GPS devices and most web maps use.

A projection converts the curved surface of the Earth to a flat map. Web maps typically use Web Mercator (EPSG:3857) for display, but the underlying data is often served in geographic coordinates (EPSG:4326 or EPSG:4258).

All GeoJSON returned by the wrapper is in WGS 84 (EPSG:4326, lon/lat), regardless of what CRS the upstream service uses. Leaflet receives standard GeoJSON and needs no special CRS configuration on the client side.

Why do some WFS services use EPSG:4258 instead of EPSG:4326?

Some German states (NRW, Sachsen) only support ETRS89 (EPSG:4258) on their WFS endpoints, not WGS 84 (EPSG:4326). ETRS89 and WGS 84 are practically identical (less than 1 m difference in Europe), so the bounding box coordinates work the same way. The wrapper automatically uses the appropriate SRS for each region.

What is the bbox format?

Bounding boxes use the format W,S,E,N in decimal degrees (EPSG:4326, WGS 84). W and E are longitude, S and N are latitude.

Note: WMS 1.3.0 and WFS 2.0.0 require lat/lon axis order (S,W,N,E) when using EPSG:4326. The wrapper translates from the more intuitive lon/lat (W,S,E,N) to the standard axis order automatically before forwarding requests upstream.

The wrapper always returns GeoJSON in WGS 84 lon/lat, regardless of the upstream axis order or projection. For GML-based services the conversion is done server-side; for services that provide native GeoJSON output the wrapper requests SRSNAME=EPSG:4326 so the upstream reprojection happens there. If you need the raw upstream GML (in its original CRS and axis order), use the /wfs.gml?type=…&bbox=…&s=… suffix — axis order and projection then depend on the individual upstream service.

Web Map Service (WMS)

Why are WMS images limited in size?

Some upstream WMS services impose a maximum image dimension (width or height in pixels). The wrapper respects these limits and returns whatever the upstream server provides. Known limits: Netherlands PDOK 2500 px, Poland GUGiK 2048 px, Denmark Dataforsyningen 3000 px. If you need a larger area, split your bounding box into smaller tiles.

How do I get full-resolution WMS images?

The wrapper requests an image whose longer side is max_size pixels (default 4000, lower for some services — see FAQ: Maximum image size). The shorter side is computed from the bbox aspect ratio. 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, a DOP (orthophoto) layer at 20 cm ground resolution and 4000 pixels wide requires a bbox no wider than 4000 × 0.2 m = 800 m to render every source pixel. A wider bbox still works but returns a downsampled image.

Why do some WMS layers return blank images?

Some upstream WMS services only render at certain zoom levels. For example, Bavaria DTK50 and DTK25 require zoom ≥ 14, and NRW nDOM requires zoom ≥ 14. The interactive maps show a warning when the active layer needs a higher zoom level. If you use the API directly and get a blank image, try increasing the zoom level (i.e. requesting a smaller bounding box).

Web Feature Service (WFS)

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

The wrapper supports OGC Filter Encoding 2.0 (FES 2.0). Pass the filter as URL-encoded XML in the filter query parameter; the wrapper forwards it as the FILTER KVP parameter to the upstream WFS server.

Keyword search with PropertyIsLike
GET /wfs?type=/inspire/hy-p/4.0#Watercourse&bbox=9.9,53.5,10.1,53.6&s={wfs-uri}
    &filter=<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0">
               <fes:PropertyIsLike wildCard="*" singleChar="." escapeChar="\">
                 <fes:ValueReference>hy-p:geographicalName</fes:ValueReference>
                 <fes:Literal>*Rhein*</fes:Literal>
               </fes:PropertyIsLike>
             </fes:Filter>
Property names for a feature type are available via /wfs/describe?type={type}&s={wfs-uri}. BBOX and FILTER are applied together (AND semantics) by the upstream server.
Exact match with PropertyIsEqualTo
GET /wfs?type=/inspire/hy-p/4.0#Watercourse&bbox=...&s={wfs-uri}
    &filter=<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0">
               <fes:PropertyIsEqualTo>
                 <fes:ValueReference>hy-p:origin</fes:ValueReference>
                 <fes:Literal>natural</fes:Literal>
               </fes:PropertyIsEqualTo>
             </fes:Filter>

Does the wrapper support temporal queries?

WMS
Yes. Append &time=2023-01-01 to a WMS request; the wrapper passes it through to the upstream service. If the layer supports a time dimension it returns the map for that date; otherwise the parameter is ignored or the server returns an error.
WFS
Yes, via OGC Filter Encoding 2.0. Temporal predicates can be expressed using the filter parameter (see FAQ: WFS filtering). For example, to select features modified after a date, use a PropertyIsGreaterThan filter on beginLifespanVersion.

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=FI_AU_ADMINISTRATIVEUNIT_COUNTRY_FI

All other services receive the standard RESOURCEID parameter instead. Several upstream services cannot handle either request, each for a different reason:

RESOURCEID requires TYPENAMES
Some servers reject a bare RESOURCEID request and require a TYPENAMES parameter alongside it. Known cases: Lower Saxony ATKIS WFS (inspire.niedersachsen.de), GeoDanmark FKG (geofa.geodanmark.dk), and ArcGIS Server WFS endpoints (e.g. geoserveis.icgc.cat/servei/…). The feature ID often encodes the type name but the wrapper does not currently extract it automatically.
GetFeatureById stored query advertised but broken
Some GeoServer instances list the stored query in their capabilities but return “Could not find feature” when it is actually called. In that case the discovery tool should be re-run so the wrapper switches to RESOURCEID. Known case: Greek environment portal (geoportal.ypen.gr).
GetFeatureById returns 403 Forbidden
Some services allow GetFeature bbox requests but block the stored query endpoint. Known case: Brandenburg transport network WFS (inspire.brandenburg.de/services/tn_bdlm_wfs).
No GetFeatureById support at all
The Polish PRG WFS (mapy.geoportal.gov.pl) explicitly warns “No featureid defined for typename” for every feature type.
Session-based feature IDs
GeoServer instances that generate transient fid-* hashes as gml:id values cannot be queried by ID across sessions. Known case: Catalonia ICGC GeoServer (geoserveis.icgc.cat/geoserver/ows).
Empty responses
The Norwegian place name service (wfs.geonorge.no/skwms1/wfs.stedsnavn) accepts the request but returns an empty FeatureCollection regardless of ID.

Feature panel

What do the properties in the feature panel mean?

Property labels
Property keys are URIs from the source vocabulary — INSPIRE schemas (e.g. http://inspire.ec.europa.eu/schemas/hy-p/4.0#length), ADV/ALKIS, GeoNovum, 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 (e.g. /wfs/vocab/hy-p/4.0#Watercourse for INSPIRE, /wfs/vocab/adv/… for ADV/ALKIS). For SPARQL DESCRIBE results the type URI from the upstream RDF graph is shown directly.
identifier
Comes from <gml:identifier> in the GML response. Its value is the canonical persistent URI for the feature (e.g. https://registry.gdi-de.org/id/de.hh/…). In RDF output this URI appears as owl:sameAs on the feature's fragment-URI subject.
Two rows labelled inspireId
INSPIRE feature types that inherit from multiple base schemas may have an inspireId element from each schema namespace (e.g. hy:inspireId from the HydroBase schema and hy-p:inspireId from the PhysicalWaters schema). Because the panel label is the local name fragment, both appear as inspireId. The full property URI (visible on hover) distinguishes them. Their values are usually identical — both encode the same localId + namespace pair. Together with the identifier row (the URI form of the same identifier), a single INSPIRE feature can show the same persistent identifier three times in different encodings.
_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:25832). 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.

Why do some ADV properties appear as plain numbers, not links?

The ADV/ALKIS schema defines concept schemes (code lists) per property and per feature type, encoded as OWL property restrictions (owl:allValuesFrom) on each class. For example, AX_Fliessgewaesser carries a restriction that its funktion property takes values from AX_Funktion_Fliessgewaesser, while AX_Weg restricts the same property to AX_Funktion_Weg — an entirely different set of numeric codes. These restrictions also capture cases where a subtype reuses a parent's scheme: for instance, AX_Fahrwegachse restricts funktion to AX_Funktion_Wegachse, not a hypothetical AX_Funktion_Fahrwegachse.

The service builds a lookup table from these restrictions at build time and uses it to resolve numeric values to SKOS concept URIs under /adv/taxo/…. If no restriction exists for a given property / feature-type combination — for example art, which is inherited by every feature type from AA_Objekt with no single authoritative scheme — the value is emitted as a plain string literal instead.

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, the lobid GND search URI, or the PDOK Locatieserver query. This lets you inspect or replay the raw upstream response independently of the wrapper.

When the feature type selector is set to * all feature types, the request fans out to one GetFeature call per type, so there is no single upstream URI to link to. In that case the label Upstream appears without a hyperlink; hover over it to see the explanation.

Access

Why do I see 429 Too Many Requests errors?

To protect upstream INSPIRE services from excessive load, rate limiting is in place. If an IP address exceeds 50 requests per 10 minutes, it is blocked for an hour with HTTP status 429.


OntologyCentral, 2026.