I&J Coordinaten WMS response RIVM

Goedemiddag,

Zou iemand mij kunnen uitleggen hoe de J-coördinaat tot stand komt in de volgende response?

Voorbeeld: Binnenhof 17 2513 AA 's-Gravenhage

https://data.rivm.nl/geo/nl/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&LAYERS=rvo_20220701_energielabels&QUERY_LAYERS=rvo_20220701_energielabels&BBOX=0,300000,300000,650000&WIDTH=300000&HEIGHT=350000&BUFFER=1&FEATURE_COUNT=1&INFO_FORMAT=application/json&CRS=EPSG:28992&I=81431&J=194782

Als ik op https://www.atlasleefomgeving.nl/check-je-plek het adres opzoek en het netwerkverkeer bekijk via de inspector in mijn browser dan krijg ik bovenstaande WMS-response terug.

Verder krijg ik ook deze response terug
https://geodata.nationaalgeoregister.nl/locatieserver/v3/lookup?id=adr-efc07caeaaba4a15d7f38a6ea159cb7b

Daarin staat:
“centroide_rd”: “POINT(81431.756 455218.921)”

Waarvan alleen de 81431 overeenkomt met de I parameter.

Maar komt J tot stand?

Alvast dank en groet Georgio

Hallo Georgio,

Dat moet toeval zijn, en je gebruikt waarschijnlijk een groot beeldscherm. De I en de J parameters zijn namelijk de coordinaten van het te bevragen punt in Pixels.
Zie WMS reference — GeoServer 2.22.x User Manual
Dit is weliswaar niet de officiele specificatie (die kan ik alleen in PDF vinden), maar ik kopieer even het relevante stukje:

The GetFeatureInfo operation is designed to provide clients of a WMS with more information about features in the pictures of maps that were returned by previous Map requests. The canonical use case for GetFeatureInfo is that a user sees the response of a Map request and chooses a point (I,J) on that map for which to obtain more information. The basic operation provides the ability for a client to specify which pixel is being asked about, which layer(s) should be investigated, and what format the information should be returned in. Because the WMS protocol is stateless, the GetFeatureInfo request indicates to the WMS what map the user is viewing by including most of the original GetMap request parameters (all but VERSION and REQUEST). From the spatial context information (BBOX, CRS, WIDTH, HEIGHT) in that GetMap request, along with the I,J position the user chose, the WMS can (possibly) return additional information about that position.

Is je vraag pure nieuwsgierigheid, of wil je op basis van een punt het BAG pand ophalen? In het laatste geval is het denk ik makkelijker om de WFS te gebruiken, zie Gebouw omtrek maken op basis van latitude en longitude - #14 door sbjager voor een voorbeeld.

Edit: Linkje naar Specs PDF

1 like

Hartelijk dank voor je informatie en de achterliggende documentatie. Ik begrijp nu dus dat dit de coördinaten zijn als je een locatie aanklikt op de kaart.

Omdat ik voor een buurt meerdere woningen wil bevragen om de leefomgevingskwaliteitscores te verzamelen, was mijn idee om op basis van de BAG-coördinaat de i en de j van de endpoint aan te passen in een scriptje.

Ik zie dat de i-coördinaat steeds exact overeenkomt met de eerste RD-New coördinaat maar de j-coördinaat wijkt af.

Is er daarom een manier om de j-coördinaat ergens aan af te leiden of te berekenen op basis van de bounding-box?

De coördinaten van de aangeklikte pixel van het plaatje dat opgevraagd is bij de WMS, ja. NIET de RD-coördinaten van het aangeklikte punt.

Als je je hele proces en informatievraag eens kort omschrijft, kan ik je misschien wat beter helpen. Een WFS is in dit geval een stuk makkelijker omdat je daaraan direct de vraag kan stellen op basis van je RD-punt (dus met bijvoorbeeld dat punt van de locatieserver), zonder dat je dat eerst moet omrekenen naar scherm-coordinaten.

Ik heb er naar gezocht en ben uiteindelijk overgeschakeld naar de WFS-services en downloadbare rasterbestanden om tot een oplossing te komen.

Dank voor het meedenken SBJAGER!

1 like