De BRT-Achtergrondkaart is nu voor iedereen beschikbaar in Vectortiles. In opdracht van de BRT maakt Publieke Dienstverlening Op de Kaart (PDOK) deze informatie beschikbaar via API’s van het Open Geospatial Consortium (OGC).
Voor de Vectortiles ontsluit PDOK:
- OGC API-Tiles
- OGC API-Styles
U vindt de BRT-A in Vectortiles’s op https://api.pdok.nl/kadaster/brt-achtergrondkaart/ogc/v1.
Visualisaties maken en gebruiken met de Tiles en Styles API’s De OGC API-Tiles is een nieuwe standaard waarmee u zelf visualisaties van topografische data maakt. Deze visualisaties kunt u daarna gebruiken in toepassingen zoals kaartviewers en andere topografische applicaties. De data van de BRT-A is nu ook ontsloten als OGC API-Tiles. Om snel te kunnen beginnen is de standaardvisualisatie van de BRT-A beschikbaar in de OGC API-Styles. In deze API kunt u die standaardvisualisatie ook aanpassen.
Nieuwe visualisaties aangeboden
Naast een standaardvisualisatie zijn er drie nieuwe visualisaties van de BRT-A gemaakt:
- De BRT-A zonder kaartteksten
- Alleen de kaartteksten van de BRT-A
- Een voorbeeld van een nachtvisualisatie
Ook deze visualisaties zijn aanpasbaar door de gebruiker en laten daarmee de toegevoegde waarde van Vector Tiles zien.
Meer informatie
Kijk voor een compleet overzicht van de gebruiksmogelijkheden van de BRT achtergrondkaart op de pagina van de BRT-Achtergrond .
Of heeft u een vraag? Neem dan contact op met de klantenservice BRT op telefoonnummer 088 - 183 38 00 of stel uw vraag via het contactformulier. De medewerkers van het Kadaster zijn op werkdagen van 9.00 tot 17.00 uur beschikbaar.
Kijk op https://api.pdok.nl om het totale overzicht te zien van de landingpages die in productie zijn genomen.
Uitleg of meer lezen?
2 likes
Ik probeer de laag te laden in QGIS, maar krijg niet de volledige styling mee.
Ik gebruik de volgende instellingen:
Zie ik wat over het hoofd?
Er is ook een verschil in hoe het stylebestand is opgebouwd ten opzichte van bijvoorbeeld de TOP10NL… Er is nu een “match”-functie bijgekomen, waar eerst alle themalagen apart opgenomen waren. Ik weet niet of QGIS dat goed kan verwerken.
Ik gebruik QGIS versie 3.30.3
1 like
Hallo @SchagenRuud,
Misschien kun je proberen of een recentere versie van QGIS beter werkt. Voor zover ik heb gezien, ondersteunt QGIS momenteel nog niet de volledige Mapbox-specificatie.
Bij mij werkt het met de nieuwste versie van QGIS al een stuk beter, al zitten er soms nog fouten in de visualisatie.
1 like
Het gaat met QGIS 3.44 een stuk beter, maar er zijn inderdaad nog wat foutjes. Helaas verschijnen de verschillende kleuren, van bijvoorbeeld terreinen, niet als aparte stylinglagen, waardoor ze niet zijn aan te passen. Er is ook een probleem met het lettertype: Liberation Sans Regular
Is er een reden geweest om deze opzet aan te houden, in plaats van die is gebruikt bij de TOP10NL?
Update:
Ik heb de kleurinstellingen gevonden. Vulling en omlijning worden bepaald via een expressie. In QGIS 3.30 geven deze foutmeldingen, maar 3.44 verwerkt ze wel goed.
Dit is hoe QGIS 3.30 de expressie heeft opgebouwd:
Door alles overig wit te maken (#ffffff), ziet het er prima uit. Alleen de wegnamen zijn nog een aandachtspunt.
1 like
@SchagenRuud goed dat je dit uitgezocht hebt. Het lijkt erop dat QGIS de ‘kleur’ “transparent” niet aan kan. Bij een update zouden we dat door wit "kunnen vervangen, omdat dit door de witte “onderlegger” laag het zelfde effect heeft. Hoe QGIS met lettertypes voor vectortiles omgaat is mij niet helemaal duidelijk. Ik weet niet of QGIS helemaal naar lettertypen in de styling kijkt of alleen het lettertype formaat. Het maakt volgens mij gebruikt van lettertypes toevallig geïnstalleerd op het lokale systeem.
1 like
Ik ben hier wat mee gaan spelen in Openlayers. Omdat ik zo gauw niet uit kon vinden of Openlayers een json-styling kan lezen, ben ik zelf maar begonnen met stylen op basis van de lagen en attributen (ook omdat ik dat leuk vind 
ja, ik ben af en toe een geogeek 
. En dan kom ik wel wat dingetjes tegen, als ik eerlijk ben:
- voor wegen is er een laag straatnamen. Voor water is er een laag waterdeelvlak_label
- In de laag waterdeelvlak_label zit de weer te geven tekst in het attribuut naam, in de laag straatnamen zit de weer te geven tekst in het attribuut label
- In de laag waterdeelvlak_label zitten de, mijns insziens overbodige, attributen shape_length, shape_area en area (onnodige overblijfselen van ArcGis, denk ik - geen idee waarom ArcGis dat doet, heeft geen toegevoegde waarde).
En nog wat kartografische dingetjes:
-
Voor de straatnamen zijn lijnen beschikbaar, zodat de plaatsing van de straatnaam netjes midden in de straat is. Sommige wateren zoals kanalen (Noord-Hollandsch Kanaal, Kanaal Stolpen-Schagen) zouden daar ook baat bij hebben, maar op die locaties zie ik geen waterdeel-lijn terug komen helaas. En in Openlayers kun je bij een polygon wel aangeven dat het label op 1 van de segmenten geplaatst moet worden in de richting van dat segment, maar dan staat het label op de lijn: niet erg fraai… Screenshot:
-
Terreinvlakken bebouwd gebied bevatten nogal eens gaten (meestal op plekken waar een industriegebiedje zit of zo, maar in sommige gevallen ook flats), wat een beetje een vreemde mix geeft op bepaalde zoomniveaus. Want dan zie je het hele bebouwde gebied, plus een paar vlekken met separate bouwwerken. Als je de WMTS gebruikt, valt dit niet zo op, omdat de straten en zo er overheen liggen, en dan zie je het eigenlijk niet. Maar omdat ik alle lagen 1 voor 1 aan het aflopen ben, viel het me ineens op. Screenshot:
-
A- en N-wegen lijken geen label te hebben, terwijl dat wel handig zou kunnen zijn. Ik heb 'm althans (nog) niet gevonden…
-
Iets dat me ook bij de WMTS-versie al stoorde: wanneer welke woonplaatsnamen zichtbaar worden. Als je op West-Friesland (sorry, ik woon in Hoorn, dus die omgeving gebruik ik erg veel ), dan zie je eerst Alkmaar, Den Helder en Stede Broec… die laatste stoort me enigszins, daar zou ik Hoorn verwachten (niet omdat ik er woon, maar omdat dit de drie grootste plaatsen in de kop van NH zijn). Bij volgende zoomniveaus zou ik als volgende Enkhuizen en Heerhugowaard verwachten, maar het duurt nogal lang voordat die zichtbaar worden. Ik begrijp dat dat veroorzaakt word door het declutter-algorithme, maar het zou voor mij meer aan mijn verwachtingen voldoen, als de grootte van de (woon-)plaats meegenomen zou worden in het declutteren. Dus dat een woonplaatsnaam met meer inwoners een hogere prioriteit zou krijgen. Geen flauw idee of dat zelfs maar mogelijk is, maar ik denk dat het beter aan in ieder geval mijn verwachtingen zou voldoen.
Ben pas een uurtje aan het stoeien geweest, dus misschien zie ik dingen over het hoofd, dat kan best. Maar met betrekking tot de naamgeving van lagen en attributen zou een beetje consistentie wel prettig zijn (ik heb toch even m’n hoofd gebroken over het niet weergeven van water namen bijvoorbeeld, voordat ik doorhad dat ik de waarde uit naam moest halen ipv label 
En de kartografische punten zijn uiteraard een gevolg van de verregaande automatisering, dus of daar wat mee gedaan kan worden weet ik niet, maar als niemand er ooit iets over roept gebeurt er ook niks, nietwaar? Verder prima ondergrond hoor, ik maak er veel gebruik van - da’s ook de reden dat ik zelf met de symbologie wilde gaan spelen 
2 likes
Aha! Gevonden! Die zitten in de annotaties…
Erg mooi dat er zo “gespeeld” wordt met deze nieuwe Vector-Tiles. En dat daar vragen bij naar voren komen, snap ik helemaal. Ik zal proberen enkele vragen te beantwoorden.
Tabel- en attribuutbenamingen
De tabel- en attribuutbenamingen in de Vector-tiles zijn zoals deze voorkwamen in de geopackage voor de WMTS-versie van de BRT Achtergrondkaart. Voor die toepassing maakte het minder uit, omdat deze database alleen zichtbaar was voor PDOK en het Kadaster (database en MAP-file). Ook is de benaming van de TOP10NL-attributen de aanleiding voor deze verschillen, omdat dit de bron is voor de BRT-A. Hierdoor is het bij wegdeel “straatnaam”.
Namen
Bij een straat is in de bron een hartlijn beschikbaar. Deze hartlijn dient inderdaad als basislijn voor de naam.
Bij waterdelen worden de namen op twee manieren weergegeven. Grote watervlakken worden door Mapserver willekeurig in het vlak geplaatst, zonder de gebruikmaking van een lijn (bv. Noordzee, Waddenzee, …). Van smallere wateren (o.a. kanalen, rivieren) worden de namen weergegeven door gebruik te maken van de laag “waterlabellijn_x” waarbij deze lijn gebruikt kan worden voor de tekstplaatsing.
Plaatsnamen
Voor de selectie van plaatsnamen wordt een proces gebruikt dat kijkt naar de plek van de plaats en het aantal inwoners van die plaats.
In grote lijnen werkt deze selectie als volgt: Eerst wordt er per zoomniveau een fish-net over heel Nederland gelegd en vervolgens wordt er per vakje de grootste plaats geselecteerd.
In jouw voorbeeld ligt Hoorn in hetzelfde vlakje als Alkmaar en wordt daarom niet geselecteert, Stede Broec ligt net in het vakje oostelijker.
Ik snap je opmerkingen over de prioriteit van grotere plaatsen wel.
Je opmerkingen zijn terecht en kunnen ook nuttig zijn. In de huidige versie van deze BRT Achtergrondkaart zullen ze alleen niet meer opgepakt worden.
Er wordt gewerkt aan de opvolger: BRT.Next.
1 like
