Hoi Anouk,
We zijn er erg blij mee. Het downloaden gaat snel, de systematiek met slippy tiles werkt fijn. Toevoeging van materiaal attribuut zou handig zijn ivm visualiseren van de vlakken. We hopen dat de data set voor heel Nederland snel beschikbaar komt.
De onlangs gereleasde BGT Vectortiles
https://api.pdok.nl/lv/bgt/ogc/v0_1 dekt qua inhoud heel Nederland. Als je kunt aangeven waar je iets mist (voorbeeld?) dan kunnen we even voor je gaan kijken.
Misschien nog een aanvulling: destijds in de oude demo is inderdaad alleen een subset beschikbaar gesteld met oa ook BRT informatie. Is dat de verwarring?
Ik heb inderdaad de beta versie nog als download link. Dat s de verwarring.
Waar kan ik bijv onderstaande tile nu downloaden?
http://geodata.nationaalgeoregister.nl/beta/topotiles/16/33750/21599.pbf
Hallo @ebeere, De nieuwe url is https://api.pdok.nl/lv/bgt/ogc/v0_1/tiles/NetherlandsRDNewQuad/{z}/{x}/{y}.pbf
succes ermee.
BGT zit op zoomlevel 12 b.v.
https://api.pdok.nl/lv/bgt/ogc/v0_1/tiles/NetherlandsRDNewQuad/12/2046/2047.pbf
Verder zijn deze BGT tiles in RD. Dus de x en y coördinaten uit de oude demo (in WGS 84 Web Mercator) zijn niet te gebruiken. De vectortile-client moet de RD projectie aankunnen. Een werkend voorbeeld met Openlayers en Angular is te vinden op GitHub - PDOK/vectortile-demo-viewer: Demo Viewer for PDOK vector tiles
Hoi @ebeere , wat @John_Schaap zegt.
M.a.w. er zijn geen VT voor de zoomniveauâs 13,14,15,16. Omdat de kwaliteit van objecten/features voor zoomniveau 12 âgoed genoegâ is om ook te gebruiken in de lagere zoomieauâs voor visualisatie. Je zal dus voor zoomniveau 16 de tegels van 12 moeten âopblazenâ zoals dat ook in het voorbeeld van gedaan is.
Hoi @John_Schaap en @wouter.visscher,
Wat jammer! In de beta versie werkte die uitstekend en de data was voor ons van voldoende kwaliteit en nauwkeurigheid om ze in een cad omgeving te gebruiken. Ook de aansluiting op het slippy tile raster was erg handig. Ik begrijp dat ik nu ergens anders de informatie over welke tiles ik nodig heb vandaan moet halen. Ze lijken niet meer overeen te komen met het slippy tile raster.
Welk pakket gebruiken jullie? (AutoCad, Microstation,âŠ) Misschien dat iemand anders op het forum een oplossing heeft die ook met jullie software werkt.
rhino grasshopper i.c.m. met Heron.
Met de Beta versie van de BGT ging dat erg goed. Luchtfoto, ahn3 dtm en BGT beta gecombineerd.
De informate uit de BGT over waar stoepen, bestrating etc. zich bevind is bijzonder bruikbaar.
Het issue lijkt dus eigenlijk te zitten in het feit dat de beta vectortiles in WGS84 en de BGT vectortiles in RD zijn wat volgens mij niet ondersteund lijkt te worden door de BlueHeronGIS plugin voor Rhino3D.
De plugin is opensourced, je kan een issue open om te vragen hoe de ontwikkelaars erover denken om support voor andere PROJ in te bouwen. Het lijkt te layeren op GDAL/OGR, (heel kort door de bocht) dus de functionaliteit is al beschikbaarâŠ
Goede morgen @wouter.visscher,
Ik heb dan twee vragen:
Waar kan ik op basis van een boundingbox en zoomlevel de juiste tile nummers opvragen.
Bij de WGS84 versie was zoomlevel 16 nauwkeurig genoeg, maar zoomlevel 15 niet. Is zoom level 12 in het RD stelsel vergelijkbaar wat betreft nauwkeurigheid met zoomlevel 16 in WGS?
Hoi @ebeere
Dit zal je moeten berekenen, normaal zal dit door de software die je gebruikt worden gedaan.
Maar kort door de bocht is het als volgt
Punt 194188.6, 465876.4 is voor zoomniveau 12 te herleiden naar tegel 12/2230/2061 door
linksboven: -285401.920, 903401.920
rechtsonder 595401.920, 22598.080
lengte van iedere zijde is 880803.840
zoomniveau 12 is een grid van 4096x4096 tegels
dus 880803.840/4096=215.04
(194188.6 - -285401.92)/215.04 = 2230.23
(903401.92 - 465876.40)/215.04 = 2034.62
bijvoorbeeld voor de brtachtergrondkaart is dat dan tegel https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0/standaard/EPSG:28992/12/2230/2034.png
Dus als je de tegels wilt hebben binnen een BBOX zal je deze berekening moeten doen tussen 2 punten (bottomleft-topright of topleft-bottonright) en dan weet je de X en Y range van tegels die nodig zijn.
Ja, deze is zelfs iets wat nauwkeuriger (los van het feit dat het in RD is)
zoomlevel 16 in WGS84 is 1:8000 en zoomlevel 12 in RD is 1:3000.
Zie ook https://www.geonovum.nl/uploads/documents/nederlandse_richtlijn_tiling_-_versie_1.1.pdf
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:
- 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.
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.
Dus ik vermoed dat het probleem structureel is.
Mee eens, ik heb een ticket aangemaakt.
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â.
