Het gaat dus vooral mis bij features die heeeeel ver buiten de tegel doorlopen.
Dit voorbeeld laat zien dat het ook in MapLibre niet goed gaat, niet alleen in Mapbox.
Klein beetje tegengas, ik ben het er totaal niet mee eens dat BGT extracten op de bounding box geclipt zouden moeten worden. De BGT is naast een kaart ook een database. Als je geclipte geometrieën uitgeeft dan krijgt de ontvanger andere vlakken dan er in de LV staan, maar wel met hetzelfde ID. Dat lijkt mij zeer onwenselijk. Ik vind het correct dat het extract alle onderdelen bevat die overlappen met de opgegeven bounding box. Het staat ook vermeld in de API documentatie. Al zou daar een korte uitleg van het 2x2km rooster best nuttig zijn, en een link naar geopackage waar je dit kan inzien.
Als je het wil hebben over dataverbruik dan vind ik wat extra slierten eerlijk gezegd klein bier. Veel groter probleem is voor mij dat je nog altijd standaard de gehele BGT historie meekrijgt bij elke extract aanvraag. Ik zou zeer graag een simpel endpoint hebben waar je alléén actuele gegevens krijgt en geen vervallen objecten. Dat zou veel meer schelen, maakt het ook een stuk gebruiksvriendelijker.
Ook krijg je altijd een bak interne BGT admistratieve gegevens mee waar de meeste gebruikers niets mee kunnen. Een simpel endpoint zou eigenlijk alleen het lokaalID en de IMGEO gegevens moeten bevatten, de gml_id creationDate LV-publicatiedatum tijdstipRegistratie enz. enz. interesseren me niks. Dit zijn zo honderdduizenden waardes die je wel moet binnenhalen en doorspitten.
@sriemens het gaat hier over de vectortiles, dat is een visualisatieservice, niet over de extracten van de BGT download API (die niet geclipt worden) of de BGT OGC API Features (ook niet geclipt). De vectortiles worden (nu al grof) geclipt op (buffers om) tegel grenzen.
Het gaat echt over heel iets anders dan BGT Extracten. Jammer dat deze thread nu vervuild is met tegengas over een heel ander onderwerp 
Ik denk dat hier twee discussies door elkaar gaan lopen: die over de vector tiles en die over de toegankelijkheid van de BGT als dataset.
Als gebruiker zie ik de BGT in de eerste plaats als een dataset. Die moet je volledig kunnen downloaden of gericht kunnen bevragen voor analyse- en databewerkingsdoeleinden. Gebruikers die de complete BGT willen analyseren of verwerken hebben uiteindelijk weinig aan vector tiles; die zijn vooral bedoeld als visualisatieservice.
De opmerkingen van @sriemens lees ik daarom vooral als een verwijzing naar een bredere gebruikersbehoefte: het is niet altijd eenvoudig om de BGT efficiënt via API’s te bevragen en weg te schrijven. Die uitdaging wordt ook beschreven in deze discussie: De BGT opvragen via API en wegschrijven met ogr2ogr - 4 van korpem
Dat maakt het voor gebruikers soms lastig om optimaal gebruik te maken van deze mooie dataset. In die context snap ik de wens voor eenvoudiger en doelgerichter ontsloten data, bijvoorbeeld actuele objecten zonder historische of administratieve ballast.
Tegelijkertijd denk ik dat dit een ander onderwerp is dan de clipping van vector tiles. De tile-service heeft een ander doel en kent andere technische afwegingen dan de BGT download API of OGC API Features.
Misschien is het goed om de discussie over de gebruiksvriendelijkheid en inrichting van de Features API verder te voeren in het topic waar die vraag al centraal staat: De BGT opvragen via API en wegschrijven met ogr2ogr - 4 van korpem
Dan kunnen we de discussie over vector tiles hier gericht houden op de visualisatieservice zelf.
Naar aanleiding van de discussie heb ik de Mapbox Vector Tile Specification erbij gepakt. Daarin staat dat geometry clipping geen onderdeel van de specificatie is en dat geometrieën buiten de tilegrenzen mogen uitsteken. Tegelijkertijd wordt aangegeven dat clipping in de praktijk wel verstandig is, onder meer om de hoeveelheid data te beperken en symbolisatie over tegelgrenzen te ondersteunen.
Volgens mij volgt hieruit dat clipping gebruikelijk is, maar doorgaans met een buffer rond de tile. De specificatie schrijft echter niet voor hoe die clipping precies moet worden uitgevoerd of hoe groot zo’n buffer moet zijn.
De praktijk van clipping met een buffer zien we ook terug in PostGIS. De functie ST_AsMVTGeom, die veel wordt gebruikt voor het genereren van Mapbox Vector Tiles, ondersteunt expliciet zowel clipping (clip_geom=true) als een aparte buffer-parameter. De documentatie vermeldt daarbij een standaardbuffer van 256 tile-eenheden bij een extent van 4096. Dat laat zien dat clipping in de praktijk niet noodzakelijk op de exacte tegelgrens plaatsvindt, maar vaak op een vergroot gebied rond de tile. De grootte van die buffer is daarbij een implementatiekeuze en geen eis uit de MVT-specificatie.
@RoelvandenBerg, worden de tiles opgebouwd vanuit de volledige geometrie en daarna geclipt, of worden eerst objecten geselecteerd op basis van vormpunten binnen de tile(+buffer)?
Mogelijke consequentie van dat laatste:
- Een lang lijnsegment kan meerdere tiles kruisen zonder dat er vormpunten in de tussenliggende tile liggen.
- Als de selectie vóór het clippen plaatsvindt, kan zo’n segment ten onrechte niet in die tile terechtkomen.
- Daardoor lijken delen van een weg of lijn te ontbreken, terwijl de onderliggende geometrie wel doorloopt.
Excuus. Ik dacht inderdaad dat het om de OGC API Features ging wat dus totaal wat anders is dan de OGC API Vector Tiles. De vector tiles kende ik niet, dit is eigenlijk wel een hele mooie, ik ga 'm gebruiken.
Ik heb het niet eerder gezien dat er onterecht iets niet geselecteerd wordt.
Maar belangrijker, bij grote ongeclipte geometrieen (waarbij de geometrie heel ver buiten de tegelgrens door loopt) renderen populaire libraries als MapLibre en Mapbox het niet lekker. Vooral bij WebMercator projectie.
Dus ja, de issues zijn:
- Tegels zijn veel groter dan nodig, dit kost onnodig bandbreedte en performance. Ook worden er veel geometrieen in zijn geheel herhaald over tegels heen.
- Bekende libraries visualiseren grote ongeclipte geometrieen niet altijd goed.
De ST_AsMVTGeom met de default opties heeft een rand van 6% (256/4096=0.0625) extra om de tegel heen en daarbuiten wordt alles geclipt. Dit zou ik graag ook zien voor de PDOK tiles. Want deze renderen wel lekker…
Nog even een tussentijdse reactie. Er zijn meerdere manieren om tot vectortiles te komen en meerdere manieren om de vectortiles te renderen. Het genereren van vectortiles kan erg kostbaar zijn (/ de haalbaarheid om dit op tijd af te krijgen hangt af van de gekozen oplossing), vooral voor een dataset als de BGT die dagelijks geupdated wordt en heel groot is. Daarbij is de extra vereiste bij PDOK dat de vectortiles ook in RD gegenereerd worden. Hierdoor is het aantal mogelijke oplossingen beperkt. Binnen de gekozen oplossing hebben we een aantal kwaliteitsmaatregelen opgenomen (voor we de tegelcache genereren). De artefacten die we hier nu zien moeten we onderzoeken waarom die ondanks die maatregelen te zien zijn. Mijn ervaring is dat je hierbij er echt even in moet duiken om de oplossing te vinden. Op basis van die eerdere ervaring ben ik voorzichtig om direct de conclusie over te nemen dat het aan vectoren ver buiten de tegel ligt. Deels ook omdat ik (nog) niet helemaal snap hoe dat tot de artefacten zou leiden. Het gevaar van een clipping maatregel zonder te snappen wat er gebeurd is dat we daarmee mogelijk een bug verbloemen die elders tot artefacten leidt. Bijvoorbeeld het feit dat vectoren die buiten de tegel liggen relatief groot zijn, is de kans op artefacten is dan ook groter. Tegelijkertijd is het wel degelijk iets om mee te nemen in het onderzoek.
Een van de zaken die mij nu opvalt is dat dit in lijngeometriën en de wegvlakken voorkomt, ik zie het na door de BGT heen scrollen. We gaan er naar kijken.
Bedankt voor de toelichting @RoelvandenBerg, begrijpelijk dat jullie hierbij een afweging moeten maken tussen actualiteit, complexiteit en de benodigde rekencapaciteit.
Uit nieuwsgierigheid: genereren jullie de BGT-vector tiles dagelijks volledig opnieuw, of worden alleen de tiles ververst waarin mutaties hebben plaatsgevonden? Ik kwam deze discussie tegen waarin incrementeel verversen van vector tiles wordt besproken.
Mogelijk levert dat, als jullie dit nog niet toepassen, winst op qua verwerkingstijd en belasting.
Daarnaast vroeg ik me af of bij het bepalen welke objecten in een tile terechtkomen een aanpak op basis van ST_DWithin iets kan betekenen. In mijn ervaring werkt dat bij ruimtelijke selecties vaak sneller dan uitsluitend een ST_Intersects. Wellicht hebben jullie daar al naar gekeken, maar ik dacht ik noem het toch even.
Hoe dan ook, interessant om te lezen welke uitdagingen er achter zo’n landelijke tile-service zitten.
We genereren de tilecache dagelijks opnieuw. We hebben cacheinvalidatie inderdaad eens onderzocht, maar dat leverde voor de BGT onvoldoende op (tov de complexiteit die zo’n maatregel toevoegd). De BGT kent veel updates op veel plekken, waardoor binnen korte duur veel tegels geïnvalideerd zouden moeten worden. Daarnaast is de BGT niet de enige vectortile dataset. Een oplossing bij PDOK is in principe generiek. Bij cache invalidatie is het nodig dat er bekend is welke tegels geraakt worden. Dat weten we over het algemeen niet (we werken met bijna alle datasets met full leveringen). Kortom, cache invalidatie zou een puntoplossing zijn voor de BGT en uiteindelijk werken we bij PDOK aan een generieke oplossing die overal altijd tot correcte tegels leidt. Vandaar ook dat we blij zijn deze melding, zodat onze oplossing generiek kunnen fixen.