PDOK lanceert de BRT TOP10NL in OGC API’s als demo

Dit lijkt inderdaad een verkeerde winding-order. De BGT en BAG vector tiles worden dagelijks gegenereerd, dus het probleem is daar meteen hersteld. De TOP10NL wordt niet dagelijks bijgewerkt, het is ons ontschoten hiervoor ook opnieuw tiles te genereren. Dit gaan we nu direct alsnog doen. We posten een update zodra dit proces is afgerond.

Dank voor de melding en excuses voor het ongemak.

NB: op de tiles pagina https://api.pdok.nl/brt/top10nl/ogc/v1-demo/tiles (voor BGT https://api.pdok.nl/lv/bgt/ogc/v1/tiles) is de exacte datum van bijwerken te vinden.

6 likes

De TOP10NL vector tiles zijn opnieuw gegenereerd, de winding-order zou nu goed moeten zijn.

NB: in mijn vorige post wees ik naar de datum vermeld op de tiles pagina. Deze is - in dit specifieke geval - niet gewijzigd omdat de brondata niet veranderd is, de tegels zijn alleen opnieuw gegenereerd obv dezelfde data. Binnenkort worden er overigens weer nieuwe tiles gegenereerd obv nieuwe/verse TOP10NL data (automatisch proces).

2 likes

Het ziet er nu stukken beter uit. Fijn dat het is opgelost.

6 likes

We zien bij dit topic vrij weinig opmerkingen of verbeterpunten uit de community. Als er nog meer feedback is dan hopen we die snel te ontvangen om een en ander nog voor de lancering van de definitieve versie aan te kunnen passen.

Zijn jullie echt allemaal heel tevreden?

1 like

Ik zie in de styling nog wel iets vreemds bij ‘Basaltblokken, steenglooiing terrein_vlak’ en ‘droogvallend waterdeel_vlak’. In QGIS zie ik daar vreemde rasterarceringen staan. Dezelfde symbolen zijn ook te zien in de legenda, die via de landingspagina is te vinden.

afbeelding

afbeelding

afbeelding

Ik zie de symbolen ook terug in het bijbehorende spritebestand.

afbeelding

Als dit vergelijk met de visualisatie van de TOP10NL-WMTS, dan komen de basaltblokken redelijk overeen, maar de lichtgrijze achtergrond ontbreekt. En er zit wat ruimte tussen de symbolen.
Het patroon voor het droogvallend waterdeel mist de blauwe achtergrond. Misschien kan dit nog worden aangepast?

2 likes

Bij het NDW (Nationaal Dataportaal Wegverkeer) hebben we de wens meer gebruik te gaan maken van BRT-gebaseerde achtergrondkaarten op het moment dat deze als vectortiles in productie gaan. Nu gebruiken we in veel applicaties OSM-vectortiles. Zijn er plannen om de verschillende stijlen van de BRT-A rastertiles ook beschikbaar te maken voor deze vectortiles? We hebben nu een enkele applicatie die de BRT-A Grijs rastertiles gebruikt en zouden deze weergave ook voor de vectortiles willen gebruiken.

2 likes

komen we op terug!

Hallo @basduineveld_ndw,
Het ontsluiten van de BRT Achtergrondkaart met Vector Tiles staat ook op het programma.
We verwachten hier samen met PDOK vanaf begin 2025 aan te gaan werken.

2 likes

Beste Bas,
Ja dat is de bedoeling. Vooralsnog zijn er vanuit PDOK alleen nog vectoren in tiles geserveerd en nog geen rasterdata. PDOK heeft de opdracht gekregen om de BRTA ook beschikbaar te gaan stellen maar qua planning is deze doorgeschoven naar volgend jaar. Er zal voorafgaand nog wat onderzoek moeten plaatsvinden alvorens deze te kunnen aanbieden.

1 like

Nog iets wat opvalt is dat er bij knooppunten en wegen met veel kruisingen nogal een overvloed aan wegnummers aanwezig is. Ik weet overigens niet of dat eenvoudig is op te lossen.

Hallo @SchagenRuud,
Bedankt voor de feedback. Dit is inderdaad een lastig probleem. In de top10 data zijn label-posities niet vast gedefinieerd. Op basis van de onderliggende geometrie-en worden de label lokaties bepaald door de client applicatie.

Verder lijkt het erop dat de het droog vallend watervlak in QGIS anders gerenderd wordt, dan in de viewer, omdat de achtergrond zwart wordt. De grote en de uitlijning van de raster kunnen we denk ik wel veranderen.

Voor nu verzamelen we de feedback en beslissen daarna in overleg met de productmanager wat we gaan verbeteren. .

1 like

Hieronder is nog eens de spriteafbeelding waarop de transparante delen zichtbaat zijn.

afbeelding

Hierop is te zien dat de arceringafbeeldingen voor de basaltblokken en voor het droogvallend waterdeel_vlak transparant zijn. In QGIS zou je normaal gesproken de ingestelde achtergrondkleur voor het project moeten zien, tenzij er onderliggende objecten zijn.
Bij basaltblokken en droogvallend waterdeel_vlak liggen er geografische gebieden onder. Deze zorgen voor een witte achtergrond bij de basaltblokken. Maar bij droogvallend waterdeel_vlak zit er stijlelement voor een ‘waterdeel contour’ onder.

De ‘waterdeel contour’ heeft een zwarte vulling en dat blijkt de zwarte achtergrond onder de ‘droogvallend waterdeel_vlak’-arcering te veroorzaken.

afbeelding

Wanneer ik dit stijlelement uitschakel is de witte kleur te zien van de onderliggende geografische gebieden te zien.

Is het wellicht een idee om de arceringafbeeldingen voor basaltblokken en droogvallend_waterdeel_vlak te voorzien van bijpassende achtergrondkleuren?
Of is het mogelijk om bij de betreffende stijlelementen naast het fill-pattern ook een fill-color toe te passen?
Wanneer ik die laatste optie toepas in QGIS ziet het resultaat er al een stukje beter uit:

1 like

@SchagenRuud Goed punt, ik ga een achtergrondkleur toevoegen zoals in je voorbeeld, transparant is voor deze elementen niet handig. Verder heb we ook gekeken naar de snelweg labels, waar we ook het een en ander kunnen verbeteren.

1 like

Ik krijg de settings niet werkend met Qgis :shushing_face:
Wat doe ik fout?

1 like

Beste Bas,

Je hebt nu minzoom op 0 en maxzoom op 18 staan. De tiles zijn - in webmercator - alleen beschikbaar op zoom niveaus 14 t/m 17.

Dus als volgt zou moeten werken, de rest van je settings staan goed:

1 like

Bedankt, het werkt nu!
++++
tiles https://api.pdok.nl/brt/top10nl/ogc/v1-demo/tiles/WebMercatorQuad/{z}/{y}/{x}?f=mvt
style https://api.pdok.nl/brt/top10nl/ogc/v1-demo/styles/brt_top10nl__webmercatorquad

2 likes

Wat nog opvalt is dat op veel plekken plaatsnamen dubbel staan vermeld. Dit lijkt te ontstaan wanneer plaatsgebieden over meerdere tiles heen lopen. Ook dit is misschien een uitdaging om aan te passen, maar het zou het kaartbeeld flink verbeteren.

Hallo @SchagenRuud,
Dit is hetzelfde gedrag als de vele wegnummerblokjes waar eerder over gechat is.
Het is besproken met @John_Schaap, en is inderdaad lastig om op te lossen.
We zullen het op de lijst met mogelijke verbeteringen plaatsen.

1 like

Ziet er goed uit, ik zie er naar uit om de OGC API’s eens in actie te zien! Ik zal het binnenkort eens testen!

4 likes