GetFeatureInfo request op de BAG verblijfsobject laag geeft een fout melding

Datasets BAG
#1

Hallo,

Als ik een featureinfo request uitvoer op de ‘bag:verblijfsobject’ laag, dan krijg ik:

  • (bij versie 1.0.0) een '500 internal server error melding (bij versie 1.0.0)
  • een ’
    msWMSLoadGetMapParams(): WMS server error. Invalid layer(s) given in the LAYERS parameter. A layer might be disabled for this request. Check wms/ows_enable_request settings.
    ’

Het request:
http://service.pdok.nl/lv/bag/wms/v2_0?&request=GetFeatureInfo&service=WMS&version=1.3.0&width=2&height=2&i=1&j=1&info_format=text/xml&styles=&srs=EPSG:28992&LAYERS=bag:verblijfsobject&QUERY_LAYERS=bag:verblijfsobject&BBOX=197521,356610,197522,356611

Deze bevraging voer ik vanuit Excel met een @FilterXMLWebservice eromheen.
Heb ik de request niet goed opgesteld of is deze optie niet geactiveerd op deze laag?

#2

In het voorbeeld zie ik dat 1.3.0 aangeroepen wordt, in dat geval is dit een voorbeeld van een geldig request:

https://service.pdok.nl/lv/bag/wms/v2_0?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&FORMAT=image%2Fpng&TRANSPARENT=true&QUERY_LAYERS=verblijfsobject&layers=verblijfsobject&INFO_FORMAT=application%2Fjson&FEATURE_COUNT=8&I=50&J=50&CRS=EPSG%3A28992&STYLES=&WIDTH=101&HEIGHT=101&BBOX=217065.01484379382%2C476704.8054938955%2C217135.99980751646%2C476775.79045761813

#3

Hoi @RobertD, als je de foutmeldingen volgt kom je uiteindelijk tot een werkend request:

  1. Zoals de WMS service aangeeft is request niet valide, de LAYERS parameter klopt niet. Als je in het capabilities document van de service kijkt zie je dat juiste laagnaam verblijfsobject is (dus zonder bag: prefix). Dit geldt voor zowel de LAYERS als QUERY_LAYERS parameter. Kortom je nieuwe url wordt nu: http://service.pdok.nl/lv/bag/wms/v2_0?&request=GetFeatureInfo&service=WMS&version=1.3.0&width=2&height=2&i=1&j=1&info_format=text/xml&styles=&srs=EPSG:28992&LAYERS=verblijfsobject&QUERY_LAYERS=verblijfsobject&BBOX=197521,356610,197522,356611.
  2. Nu geeft de WMS service de foutmelding Missing required parameter CRS. In je request url gebruiks je de request param srs=EPSG:28992, maar dat moet dus worden CRS=28992 (SRS is voor WMS 1.0.0): http://service.pdok.nl/lv/bag/wms/v2_0?&request=GetFeatureInfo&service=WMS&version=1.3.0&width=2&height=2&i=1&j=1&info_format=text/xml&styles=&CRS=EPSG:28992&LAYERS=verblijfsobject&QUERY_LAYERS=verblijfsobject&BBOX=197521,356610,197522,356611.

Deze url levert een werkend GetFeatureInfo request op (wat echter geen features oplevert).

#4

Dank voor de ‘werkende’ voorbeelden en de duidelijke toelichting op de kleine veranderingen in de request. De capabilities had ik ook opgevraagd. Maar dat ‘bag;’ prefix kon vervallen had ik niet ontdekt. CRS, I en J heb ik wel aangepast gehad, maar als er meerdere fouten in zitten, werkt het alsnog niet. Dat is mss ook wel het lastige eraan, om een bestaande request om te bouwen naar een nieuwe versie.
Groet. Robert.

#5

Anton,

Ad 1. Deze request geeft idd een foutmelding over CRS.
Ad 2. Deze request is wellicht wat te veel uitgekleed, want die geeft toch nog een foutmelding.

<gml:boundedBy>
    <gml:null>missing</gml:null>
</gml:boundedBy>

Groet,
Robert.

#6

Nu we het hier toch over hebben:
Kan iemand me uitleggen wat de layers=verblijfsobject-parameter in een GetFeatureInfo-request doet?
De te query-en layer(s) wordt immer opgegevn met de parameter query_layers.

Volgens de OGC documentatie (https://portal.ogc.org/files/?artifact_id=1058) is dit helemaal geen parameter bij een GetFeatureInfo, maar weglaten = foutmelding.

#7

We hebben het hier over een WMS 1.3.0 GetFeatureInfo request, daar is dan LAYERS (via <map_request_copy>) een mandatory parameter
zie: https://portal.ogc.org/files/?artifact_id=14416

Dit gaat ook op voor 1.1.0

image

En LAYERS is dan weer required in de GetMap (vandaar dat die dan niet ‘geskipped’ kan worden)

image
image701×302 65.3 KB

Waarom het een aparte PARAMETER is, tja… goede vraag

#8

Het request “werkt” want de service antwoordt met een FeatureCollection, die echter leeg is.

Als je in de viewer de BAG verblijfobjecten teovoegt en in het locatieserver zoekveld naar de coordinaat 197521.5,356610.5 (dit is de coordinaat waarvoor je de getfeatureinfo opvraagt, het middelpunt van de BBOX) gaat dan zie je dat op die locatie geen verblijfobject ligt.

image
image727×704 231 KB

p.s. als je XML of code in je post wil zetten dit graag met “Vooraf opgemaakte tekst” knop toevoegen. Met XML wordt dit dan niet als HTML geinterpreteerd waardoor de XML tags wegvallen (ik heb in je post al aangepast).
image

#9

Twee hoofdredenen:

  1. Internet is stateless
  2. WMS is een raster-service

Wat uitgebreider: De server heeft, om een GetFeatureInfo-request goed te kunnen beantwoorden, informatie nodig over het oorspronkelijke GetMap-request waarop die GetFeatureInfo gebaseerd is. Maar de server onthoud niet wie wat allemaal heeft opgevraagd (en er kan wel 10 minuten zitten tussen het oorsponkelijke GetMap-request en het GetFeatureInfo-request), dus voor een GetFeatureInfo-request moet het oorspronkelijke GetMap-request gereproduceerd kunnen worden, anders weet de server niet wat er nou precies waar bevraagd is. Vandaar ook wat je in de documentatie ziet:’<map_request_copy>’ = Required.
Maar: Het GetFeatureInfo-request hoeft niet noodzakelijkerwijs om exact dezelfde layers te gaan als het GetMap-request. Het kan best zijn dat ik drie of vier lagen in mijn GetMap-request heb opgehaald om een mooi kaartje te produceren, en alleen in de featureinfo van 1 van die lagen geinteresseerd ben. Voor het eerste deel, het reproduceren van het oorsponkelijke GetMap-request, is de LAYERS= parameter noodzakelijk. Om te weten welke attributen opgehaald moeten worden, is QUERY_LAYERS= noodzakelijk. En die twee hoeven niet noodzakelijkerwijs gelijk aan elkaar te zijn, dus moeten het apart benoemde parameters zijn.

Hieruit kun je ook afleiden dat GetFeatureInfo nooit bedoeld is als standalone-request (maar als request om meer informatie over een GetMap-request). Dus waarom je dat zou gebruiken vanuit een Excel, weet ik niet, ik zou daar zelf de WFS voor gebruiken. Kun je gewoon in RD-coordinaten blijven werken, en hoef je niet pixel-waardes te gaan berekenen.

1 like
#10

@wouter.visscher en @sbjager dank voor de heldere uitleg!

Wat me dan toch nog verbaast (ja sorry hoor…) is dat ik een GetFeatureInfo kan opstellen waarin de layers-parameter en de query_layers-parameter naar verschillende layers verwijzen.
(ik zou verwachten dat query_layers een subset van layers zou moeten zijn, zo interpreteer ik het OGC-document):

https://service.pdok.nl/lv/bag/wms/v2_0?&request=GetFeatureInfo&service=WMS&version=1.3.0&width=2&height=2&i=1&j=1&info_format=text/xml&styles=&CRS=EPSG:28992&LAYERS=verblijfsobject&QUERY_LAYERS=pand&BBOX=197521,356610,197522,356611

#11

Heb dat document niet (in detail) gelezen, maar ik zou ook direct zeggen: waarom? Juist het voorbeeld dat je zelf geeft, maakt duidelijk dat het erg prettig is dat ze niet gelijk aan elkaar hoeven te zijn. Vooral net andersom: de meest voorkomende functionele vraag bij bouwwerken (panden) is welk adres het heeft. De Pand-info is voor de meeste mensen niet erg interessant. Dus een kaartje van panden, met daarop een GetFeatureInfo die de VBO (=adres) informatie ophaalt, zou een (zeker in mijn organisatie) heel veel gebruikte tool worden.

Vergeet ook niet dat er nogal wat historie achter (de definitie van) WMS-services zit… Maar ik zal dat docje wel eens doorspitten, kijken wat dat zegt.

#12

Anton, Jeroen,

Naast eerder vermelde spec’s in de OGC-documentatie, heb ik via de NGR website nog gekeken naar de documentatie. Daar zit enkele fouten in de parameters van het gegeven voorbeeld!.

zie: CBS Gebiedsindelingen 2022 WMS. >> Tabblad: ‘Downloads, views en links’: >> Lees meer over het WMS protocol.>> klik of scroll naar ‘GetFeatureInfo’.

De requestparameters die bij een versie 1.3.0. horen zijn: srs → crs, x → I , y → J