Hoi allen,
Mij viel op dat de PDOK BGT-vectortiles (OGC API Tiles, WebMercatorQuad, f=mvt) niet op de tegelgrens geclipt zijn: een feature die een tegel raakt wordt volledig meegestuurd, met coördinaten tot ~8× de extent (4096) — soms zelfs voorbij het 16-bits bereik (> 32.767).
Voorbeeld — z17-tegel, OGC tileMatrix/tileRow/tileCol = 17/42917/67258 (= slippy/XYZ z/x/y = 17/67258/42917; ≈ 4,73° O, 52,63° N):
https://api.pdok.nl/lv/bgt/ogc/v1/tiles/WebMercatorQuad/17/42917/67258?f=mvt
De spoor-feature L0004.b3241e8d31064191b2b5f72bfcdb9dfa heeft 10 punten, maar slechts 1 ligt binnen [0,4096] — de rest is een echte ~1,4 km spoorlijn die de tegel uit loopt. In diezelfde tegel zit een functioneelgebied-polygon met 75 vertices > 32.767. Geldt ook voor BRT.
Links zoals geleverd (geometrie ver buiten de rode tegelkader), rechts ná clipping op extent + buffer.
Je ziet zelfs dat de spoorlijn niet het enige is, maar die andere “slierten” misschien nog wel “overbodiger” zijn.
Tolerante renderers (MapLibre) vangen dit op, maar clippen op extent + buffer is de gangbare praktijk (Tippecanoe, pg_tileserv, GeoServer, GDAL, PostGIS ST_AsMVTGeom), scheelt data en is breder compatibel.
Is dit bekend, en kan de tileservice bij de bron clippen?
Reproduceren:
curl -s "https://api.pdok.nl/lv/bgt/ogc/v1/tiles/WebMercatorQuad/17/42917/67258?f=mvt" -o bgt.pbf
1 like
Heb nog een tool online gezet waar de hele inhoud van deze ene tegel als voorbeeld te zien valt.
Hier
Beste Frank,
Dankjewel voor je vraag, heldere analyse en het delen van je tool. Dit gedrag is bij ons bekend. Tijdens het opzetten van de verwerkingsstraat die de tegels maakt, bleek dat het clippen van elke geometrie op elke tegel te veel rekenkracht vereist. We hebben daarom gekozen voor een oplossing die de geometrieën op een aantal zoomniveaus hoger clipt. Momenteel onderzoeken we of het mogelijk is om het proces efficiënter in te richten om ook per tegel te kunnen clippen.
Thanks! Ik wil ook even melden dat het in veel visualisaties mis gaat.
Wij gebruiken Mapbox, en daar gaat het in de visualisatie compleet mis.
Maar hier een voorbeeld van de NDW site (ook overheid).
Dit is hetzelfde spoordeel wat niet aansluit door het ontbreken van de clipping.
Dat lijkt mij dan eerder een probleem van Mapbox dan van het al of niet clippen. Openlayers heeft hier geen enkel probleem mee:
en ik kan heen en weer zoomen zonder dat ik hier onderbrekingen zie.
Zowel MapLibre (Dat gebruikt NDW in het voorbeeld) als Mapbox hebben het probleem.
En wellicht wordt het probleem uitvergroot door dat wij WebMercator gebruiken. Weet niet welke projectie jij nu gebruikt.
Wij kunnen niet (eenvoudig) switchen van component.
Maar goed, het blijft niet netjes dat er zoveel unused geometrie in een tegel zit.
Zou je een linkje naar de precieze locatie / implementatie kunnen geven (evt via PM)? Ik zie dit hier ook niet voor komen. Dat is overigens wel RD (en geen webmercator), in de API zelf met Webmercator zie ik het ook niet voorkomen.
Misschien heb je een stukje voorbeeld code? Want ik sluit me aan bij het beeld dat dit clientside niet helemaal goed lijkt te gaan. Zo niet dan hoor ik dat graag, dit geeft ons een beeld hoe clients met onze tiles omgaan.
Overigens hebben vectortiles in verband met styling sowieso altijd een buffer nodig met data eromheen (anders krijg je “afgesneden” (vlak-, lijn- of punt)symbolen die langs een tegelgrens lopen). Dus dat zou het probleem niet mogen veroorzaken. Los van het onderzoek om onze tegels nog beter te maken.
EPSG:28992, oftewel RD. Zoals bij alles wat niet (verder dan een kilometertje of zo) de grens over gaat.
Vectortiles hebben een buffer nodig ja. Maar “normaal” zijn deze clipped op een buffer, en wordt niet de hele geometrie bewaard zoals wat hier gebeurt.
Clientside gaat het mis, de tegelinhoud is in principe correct, alleen er zit veel te veel in.
Ik ga even kijken of ik voorbeelden kan maken zodat het zichtbaar is/wordt.
De eerste link die je stuurt zijn raster tiles. Dat is echt wat anders en doorlopen een geheel andere generatie pipeline.
Ik raad je ook aan om deze link nog even te bekijken, die laat de inhoud van 1 tegel zien.
Ik heb het gereproduceerd. Dit gaan we onderzoeken, ik ben dit nog niet eerder zo tegengekomen. Zoals een collega hierboven aangeeft, we zijn sowieso bezig naar een onderzoek voor die buffers. Dank voor het melden! Als we meer weten koppelen we het hier terug. Dit kan best een tijdje duren aangezien dit niet triviaal is.
Dit geeft al een beeld, mocht je (zonder al te veel moeite) meer locaties hebt waar dit voorkomt (en waar dit niet het spoor betreft) helpt dat ons (extra). Waar je overigens mee zou kunnen helpen als je meer locaties kan aangeven en of dit bij meer stijl elementen voorkomt.
Overigens zullen we ook kijken naar andere oorzaken. De spec staat namelijk overlap volledig toe:
A layer MUST contain an extent that describes the width and height of the tile in integer coordinates. The geometries within the Vector Tile MAY extend past the bounds of the tile’s area as defined by the extent. Geometries that extend past the tile’s area as defined by extent are often used as a buffer for rendering features that overlap multiple adjacent tiles.
Het komt op veel plekken voor, maar ze zijn best lastig te isoleren. Ik ga even opzoek voor je.
Ik heb overigens een lokale test gedaan, waarbij ik deze tegel zelf heb geclipped en daarmee is de visualisatie goed.
Het mag via de spec, maar het is niet optimaal/performant/(veel) groter dan nodig.
Het is een bug in de client, dat onderken ik. Maar ja, als die clients de main consumers zijn… Dan kunnen we het beter in de bron data oplossen.
Prima, het gaat me er vooral om dat we bij PDOK er ook even goed in duiken, dit zijn lastige problemen waarbij kleine veranderingen soms een heel ander beeld geven. Ik zal de samenvatting van analyse die we hebben gedaan tzt ook even delen. Sowieso dus dank voor het melden dit helpt ons onze services beter maken.
1 like
Die heeft ook allerlei rendering glitches door non clipping.
Ik zal deze tegel wat verder analyseren. Ik reply met wat details.
Links Maplibre (NDW) Vector Tile PDOK NDW ontwikkel omgeving
Rechts Mapbox (NDW) NDW Maps
Locatie is Weenixhof, Alkmaar
Andere plek, ook probleempjes.
Ook op de ontwikkel omgeving
Het is zeer afhankelijk van het zoom level. @Product_Owner_NWB
