Hoi @eesger, het was ff wat uitzoek werk en we dachten dat het eerst gerelateerd was aan een ander issue vandaar de vertraging.
Maar om hier een correct antwoord op te geven:
- Het request wat je doet op de BAG heeft een aantal parameters m.b.t. WGS84 zoals de srsName, en de projectie van de BBOX. (Welk goed om op te merken is de “gedraaide” lat/lon <> lon/lat tussen EPSG:4326 en CRS84)
- Ook belangrijk om te weten is dat de BAG is opgelagen met de geometrien in EPSG:28992 (Rijksdriehoekscoördinaten)
- Dit betekent dat de door jouw opgegeven parameters vertaald moeten worden naar EPSG:28992
- Dit gebeurd ook “netjes” in dit geval:
POLYGON((158046.589744294 315774.249984155,158046.589744294 384027.407047202,192370.471926689 384027.407047202,192370.471926689 315774.249984155,158046.589744294 315774.249984155))
- deze wordt dan ook gebruikt in de query op de backend en hier komt ook dan een resultset uit met 1000 features/objecten
- Maar nu komt het …
- Deze data moet nu van de originele projectie EPSG:28992 geprojecteerd worden naar EPSG:4326
- Wanneer dit is gedaan wordt er gecontroleerd of te teruggegeven features uit de database nog liggen in de opgegeven BBOX (in EPSG:4326)
- en dat is dus niet meer het geval…
- wanneer men gaat (her)projecteren ontstaan d’r afwijkingen, deze zijn afhankelijk of men met een platte (als een kaart) projectie zoals EPSG:28992 werkt of met een bolle (als een voetbal) projectie zoals EPSG:4326
- in dit specifieke geval vallen er dus 156 features weg, omdat deze dus niet meer in de originele/opgeven BBOX vallen.
- En dit gebeurt dus toevallig dat Amstenrade (door de sortby) op de grens ligt van de opgeven BBOX. Mocht Amstenrade in het midden hebben gelegen dan had dit issue niet gespeeld.
De vraag is dus ook of het uberhaupt een fout is… gezien de stappen die plaats vinden allemaal te verklaren zijn.
De vervolg vraag is dan hoe hier dan mee om te gaan. Je zou een aantal dingen kunnen doen:
- De data op te vragen in EPSG:28992 (de bron projectie)
Een belangrijke opmerking die zo ie zo te maken is, is dat de data van de BAG je die nu gebruikt in EPSG:4326 verre van “correct” is. Dit is prima zolang het voornamelijk gebruikt wordt voor globale visualisatie of iets dergelijks.
- In plaats van een BBOX een “echte” polygoon mee te sturen zodat de punten linksboven/rechtsonder “recht getrokken” worden.
- Kleinere BBOX te gebruiken
<?xml version="1.0" encoding="utf-8"?>
<GetFeature xmlns="http://www.opengis.net/wfs/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
service="WFS"
version="2.0.0"
outputformat="application/json"
startindex="0"
count="1000"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.opengis.net/wfs/2.0/wfs.xsd">
<Query typeNames="verblijfsobject"
xmlns:bag="http://bag.geonovum.nl"
srsName="EPSG:4326">
<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>geom</fes:ValueReference>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
srsName="CRS:84">
<gml:exterior>
<gml:LinearRing>
<gml:posList srsDimension="2">5.4310216300389 50.831818001343, 5.91762245052714 50.831818001343,5.91762245052714 51.4441313792053, 5.4310216300389 51.4441313792053, 5.4310216300389 50.831818001343</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</fes:Intersects>
</fes:Filter>
<fes:SortBy xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:SortProperty>
<fes:PropertyName>woonplaats</fes:PropertyName>
<fes:SortOrder>ASC</fes:SortOrder>
</fes:SortProperty>
</fes:SortBy>
</Query>
</GetFeature>
