Hoi @rli, nee daar waren we (ik) niet zo van op de hoogte. Wij zien namelijk met “simpele” FES filters requesten dat mapserver een aanzienlijk stuk sneller is, in bepaalde gevallen een factor 10x. Ik geef toe dat onze testen zich richten op 80% van wat ons verkeer is en dat we met “complexere” FES filters testen geen 100% dekking kunnen creëren op wat allemaal op ons kan worden afgevuurd.
bijvoorbeeld een POST request met FES filter als:
<wfs:GetFeature service="WFS" version="2.0.0"
outputFormat="application/gml+xml; version=3.2" count="1000" startindex="0" xmlns:bag="http://bag.geonovum.nl"
xmlns:wfs="http://www.opengis.net/wfs/2.0"
xmlns:fes="http://www.opengis.net/fes/2.0"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:gml="http://www.opengis.net/gml/3.2"
xsi:schemaLocation="http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/2.0/wfs.xsd">
<wfs:Query typeNames="bag:pand" srsName="EPSG:28992"><fes:Filter>
<fes:PropertyIsEqualTo matchCase="true"><fes:ValueReference>identificatie</fes:ValueReference><fes:Literal>0200100000713326</fes:Literal></fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
</wfs:GetFeature>
Komt vanuit de mapserver stack terug binnen <50ms en vanuit de geoserver stack boven de 400>ms.
Graag zou ik voorbeelden zien van requesten met een FES filters waarin de performance te wensen overlaat? Mogelijk dat we naar de onderliggende queries kunnen kijken. Mogelijk iets met de tijd van de dag? @rli zou jij die kunnen posten?
M.b.t. onze redenen hoop ik dat jij die kan begrijpen waarom wij (PDOK) deze weg hebben (moeten) nemen. Het klopt Mapserver heeft issues net zoals Geoserver en vrijwel ieder stukje software. Hoewel we CQL_FILTER zien als iets “vendor specific” en het creeeren (wat nu de situatie is) van een “vendor lock-in” verre van wenselijk is voor een open data platform.
Hier zit ook de “uitdaging”, een platform bouwen wat werkt voor zoveel mogelijk mensen/use-cases. Hierin kunnen we helaas nooit iedereen 100% facilitieren maar hopen we mensen wel zo veel en goed mogelijk op weg te kunnen helpen met hoe we de data in PDOK “presenteren”. Dat hier dan soms iets buitenboord valt is dan soms een gegeven. Dat gezegd hebben zijn wij altijd bereid om mee te denken over mogelijk alternatieve of andere oplossingen.
Feit blijft dat voor het bouwen van oplossingen tegen PDOK (of iedere NSDI of ander data platform) dit niet een “one-way street” is. Platformen zijn dynamisch (WFS → OGC OAF, TMS → WMTS), dat mag dan ook verwacht worden voor de applicaties die daar mee interface.
Dat is iets waar wij natuurlijk geen garanties op kunnen geven.