Vector Tiles in Rhino3d + BlueHeronGIS

Bedankt @wouter.visscher,

Ik had inmiddels praktijkrichtlijn-vector-tiling/NetherlandsRDNewQuad.json at master · Geonovum/praktijkrichtlijn-vector-tiling · GitHub informatie gevonden en hiermee is het me gelukt de tiles te berekenen.

De tiles zijn inderdaad kleiner en hopelijk nauwkeuriger. Dat lijkt goed te gaan. Nu alleen het volgende waar ik tegenaan loop. Wanneer ik in de Beta versie de tile opvraag: http://geodata.nationaalgeoregister.nl/beta/topotiles/16/33750/21599.pbf kan ik het bestand wel inlezen en laten vertalen naar naar geometry, maar bij de nieuwe service https://api.pdok.nl/lv/bgt/ogc/v0_1/tiles/NetherlandsRDNewQuad/12/2051/2051.pbf krijg ik de volgende fout melding:

  1. Solution exception:TopologyException: Input geom 0 is invalid: Self-intersection at or near point 29627.033705196984 -31033.433483781024 at 29627.033705196984 -31033.433483781024

Dit zal waarschijnlijk dan ook met het RD stelsel te maken hebben. Ik zal deze vraag ook bij Heron neerleggen.

Die beta versie had wel zijn voordelen.

1 like

Hoi @wouter.visscher

Hierbij de oorzaak verklaard. Kennelijk is in de beta vesrie een andere methode gebruikt om de vectortiles te genereren dan in de uiteindelijke versie. Daar ben ik dit probleem niet tegen gekomen. Wel jammer.

@ebeere, goed dat je het aangeeft.
Ik neem aan dat dit tegel 12/2051/2051 betreft, we gaan d’r naar kijken

Ik heb slechts 4 tegels getest en die hadden allemaal het zelfde probleem.

  • 12/2050/2051
  • 12/2051/2051
  • 12/2050/2050
  • 12/2051/2050

Dus ik vermoed dat het probleem structureel is.

Mee eens, ik heb een ticket aangemaakt.

1 like

Waarom gebruiken jullie eigenlijk niet de citygml database om de vector tiles te genereren?

(zover ik weet) is er geen “citygml database”, maar wat je waarschijnlijk bedoelt is: Ja, daar maken wij wel gebruik van. Wij krijgen vanuit de LV-BGT de “originele” GML voor de verwerking naar de verschillende producten (downloads, wmts, vectortiles)

Als je vraag is na aanleiding van wat Brain zegt, is dat een verkeerde interpretatie. Dit gedrag is namelijk inherent aan vectortiles. Kort door de bocht worden geometrien ‘gesnapt’ op een grid van 256x256/512x512 (afhankelijk van settings) binnen een betreffende vectortile wat dit gedrag van rastering heeft (en dus het risico op intersections). Als we de geometrien niet van te voren ‘voldoende’ versimpelen komt dit dus naar voren.

De oplossing ligt bij ons in de voorverwerking van de geometrieen voordat deze de vectortile in gaan, door punten die ‘te dicht’ bij elkaar liggen te ‘mergen’.

1 like

Ik snap hem. Bedankt voor de informatie. En fijn dat jullie het gaan oplossen.

1 like

Hoi @wouter.visscher en @Anouk

Hebben jullie enig idee wanneer de bgt vector tiles zonder zelfsnijdende polygonen gereed zijn?
En kan het zijn dat de link niet meer werkt?
https://api.pdok.nl/lv/bgt/ogc/v0_1/tiles/NetherlandsRDNewQuad/12/2312/2494.pbf

1 like

De betreffende story staat boven aan de backlog, ik neem aan dat hij de komende sprint opgepakt gaat worden. (de volgende sprint start de 14de)

De service lijkt het mij gewoon te doen. Volgens mij probeer je data op te halen van een gebied waar geen data is (namelijk over de grens bij Limburg in Duitsland).
Als je dezelfde ZXY op geeft in de BRTA dan zie je ook dat je een leeg plaatje terug krijgt
https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0/standaard/EPSG:28992/12/2312/2494.png

Dus het klopt dat die “link” het niet doet, maar de service zelf doet het wel.

(hoewel de 404 + error message nog wel wat te wensen overlaat, zal daar ook een ticket voor aanmaken)

2 likes

@wouter.visscher

Dank voor de informatie.

Ik had de vector tiles van onder naar boven georganiseerd i.p.v. boven naar onder.

In het kader van verwachtingen: het ticket voor het oplossen van de ‘zelfsnijdende polygonen’ heeft deze sprint niet gehaald en is doorgeschoven naar de eerste twee weken van augustus.

1 like

dank voor de informatie.

Helaas heeft de verwachte oplossing niet tot het gewenste resultaat geleid. We hebben een aantal andere mogelijke oplossingsrichtingen die we verder gaan onderzoeken.

1 like

Ha @Jeroen_PDOK

Is er al enig zicht op een oplossing?

Ha Erik, we zien een aantal stappen om te komen tot een oplossing maar niet allen geheel triviaal. Het probleem is, zoals Wouter eerder aangaf, dat (soms) lijnen elkaar gaan snijden als diens punten verschuiven doordat er een snap-to-grid wordt toegepast (wat impliciet gebeurt bij het maken van een vector tile). We zijn aan de slag gegaan met het te versimpelen (meer of minder) maar dat is nog niet voldoende. De volgende stap die we gaan beproeven is het “repareren” van de geometrieën, nadat het snap-to-grid is gebeurd. Qua uitwerking hiervan zijn we het één en ander aan het uitzoeken v.w.b. de beste aanpak die past binnen de architectuur en niet ten nadele van de performance zal zijn. We zijn er dus nog niet maar we nemen stappen, als we verder zijn laten we van ons horen. Bedankt voor het geduld tot dusver!

2 likes

@ebeere . We hebben een aanpassing gemaakt (~vandaag uitgerold) aan het genereren van de vector tiles waardoor er minder self-intersections komen in de uiteindelijke tiles. (Bij een steekproef gaat het van ~15% voor naar ~0,5% na.) Mogelijk komt er nog een iteratie overheen voor 0%. Kun jij al verschil bemerken?

1 like

O en trouwens, de tiles template url is (nu) https://api.pdok.nl/lv/bgt/ogc/v0_1/tiles/NetherlandsRDNewQuad/{z}/{y}/{x}.pbf (y/x ipv x/y), zie PDOK Vector tiles viewer is broken - #2 door roela

@roela

Dank voor de informatie. Wie weet in de toekomst.
Ik gebruik inmiddels de full custom download methode om de BGT te downloaden.
Deze werkt gelukkig bijna altijd goed.

Check inmiddels de lancering van de meest recente API’s op: PDOK lanceert de BGT Vector Tiles (OGC API) 1.0 versie en op: BAG nu ook beschikbaar als Vector Tiles via PDOK (OGC API’s).

Voor de early adopters (afnemers van de 0.1 versie) graag zo snel mogelijk overstappen naar deze api’s. Zoals vermeld voldoen deze volledig aan de specificaties en ontvang je meer functionaliteit!