Het is ervaringen met, niet over.
done
Ziet er goed uit! De bounding box moest ik even voor puzzelen, misschien is dat een idee om nog wat uitgebreider te documenteren (met een voorbeeldquery). Anyway, uiteindelijk werkt dit:
Waarom is er trouwens gekozen voor WGS84? Is dat OGC?
De default waarde voor de CRSen, waaronder bbox-crs
is inderdaad WGS84 volgens de OGC standaard. Het is mogelijk om (bijvoorbeeld) een RD bbox-crs
op te geven. In HTML format is dat dan (zodat je kan zien dat/hoe de BBOXes overeenkomen):
jouw bbox (met default crs
en bbox-crs
): https://api.pdok.nl/brt/top10nl/ogc/v1-demo/collections/hoogte_punt/items?bbox=5.96,51.90,6.19,52.12&limit=1000&f=html
Helder, bedankt!
Onderstaande afbeelding toont wat ik te zien krijg wanneer ik de BRT vector tiles laad in QGIS. Alleen de ‘eiland’-vlakken worden getoond. Verder ook alle lijn- en puntgeometrie.
Zou dit hetzelfde probleem zijn met de ‘winding order’ van de polygonen, zoals eerder met de BGT en BAG-vectortiles?
Zie: https://geoforum.nl/t/bgt-vectortiles-in-qgis-zijn-niet-meer-compleet/9731/12
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.
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).
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?
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.
Ik zie de symbolen ook terug in het bijbehorende spritebestand.
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?
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.
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.
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.
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. .
Hieronder is nog eens de spriteafbeelding waarop de transparante delen zichtbaat zijn.
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.
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:
@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.