Vector tiles en het Rijksdriehoeksstelsel

Standaarden
#1

Geïnspireerd door een gesprek dat ik een tijdje geleden met Jeroen had leek dit mij wel een interessant onderwerp. Vector tiles zie ik als de toekomst van webmapping, maar ik merk zelf dat ik er niet veel gebruik van maak. Onder andere omdat ik bijna alleen met data uit Nederland werk, waarvan de geometrie bijna altijd bestaat uit rd-coördinaten. In viewers als Leaflet is het makkelijk om rd-data te tonen, al dan niet met behulp van een enkele hulpmiddelen. Van de een workflow met rd-coördinaten en vector tiles heb ik echter nog niet echt een beeld.

Ik ben wel benieuwd hoe de rest hier tegen aankijkt. Zijn vector tiles een bedreiging voor het rd-ecosysteem? Zijn er al mensen die rd-data in laten stromen in een webgl/vector tile viewer? Denkt het PDOK eraan om in de toekomst naast wms/wmts endpoints ook vector tiles aan te bieden voor de PDOK webservices? Bestaat er een kip en ei-situatie als het gaat om rd vector tile databronnen en rd vector tile viewers?

Het lijkt mij interessant of en hoe er een transitie plaats zal vinden richting het (exclusieve) gebruik van vector data/tiles, en hoe je dat als community zou kunnen ondersteunen.

1 like
#2

Ik heb ooit gehoord/gelezen dat het Kadaster aan het overwegen was om WGS84 als standaard stelsel te gaan gebruiken. Daarna heb ik er nooit meer iets over gehoord. Ik zou het zelf wel interessant vinden als we een bolvormig stelsel gaan hanteren die beter bij de werkelijkheid past.

RD blijft toch altijd een beetje rekken en strekken totdat het kleine stukje wereld op een plat vlak past :slight_smile:

#3

Zou ETRS89 dan niet passender zijn? Ben niet super op de hoogte, maar ik had de indruk dat er binnen EU een push was om te standaardiseren op dat coördinatensysteem. Dan blijft het probleem van softwareondersteuning nog steeds bestaan natuurlijk.

Dat het rd opgevolgd zou worden door een ander systeem was wel één van de denkrichtingen die ik had bij dit onderwerp.

#4

Interessant topic. Vanuit ons content-team bij Esri Nederland zijn we ook al een tijd bezig met vector tiles en hebben daar nu een tijdje een vector basiskaart draaien die onze eindgebruikers benutten: http://www.arcgis.com/home/webmap/viewer.html?webmap=c8cb478cd4da4206a56e2a2fba545ccf. Deze gebruikt de diverse bronnen zoals BRT en BGT, gevisualiseerd op een eigen manier en met wat processing op de data om deze zo geschikt mogelijk te maken voor vector tiles. Overigens is deze basiskaart wél in RD (EPSG 28992). Om dit mogelijk te maken is de Mapbox specificatie door Esri uitgebreid, waarbij het daardoor nu mogelijk is om vanuit de ArcGIS-software vector tiles te maken in elke EPSG naar keuze. Voor de fun wie zich wil laten inspireren: https://www.esri.com/arcgis-blog/products/arcgis-online/data-management/back-2-school-vector-tiles-in-azimuthal-check-it/?

Eén van de aardige eigenschappen van vector tiles is dat deze nog aangepast kunnen worden qua symbologie. Om daar wat inspiratie voor op te doen: http://www.arcgis.com/home/group.html?id=20dd19496c504cbf999c408014f88353&sortField=numviews&sortOrder=desc. Deze voorbeelden zijn op basis van de wereldwijde basiskaart (web mercator projectie). Zelf vind ik de Christmas, Nova, Pencil en Newspaper fraai qua wat er mogelijk is qua aanpassen van style (allemaal dezelfde bron, ander design).

Ik zie zelf vector tiles niet als bedreiging voor het gebruik van RD. Afhankelijk van de gekozen techniek / software zijn er op dit moment nog beperkingen in de te kiezen projecties voor vector tiles, maar ik vraag me sterk af of dat zo blijft. Daarnaast zijn er meer en meer mogelijkheden om ook slim client side datumtransformaties toe te passen, en eigen RD data (je WMS, WFS, Esri REST-service etc) bijv. op een web mercator ondergrond te plaatsen (zie dit niet als vrijbrief om niet meer na te denken in hoe je een oplossing het beste in elkaar zet t.b.v. performance). Daarnaast is denk ik niet zozeer RD of Web Mercator de vraag, maar eerder de verkenning naar ETRS als te hanteren stelsel voor Nederland.

Daarnaast vind ik een ander punt dat vector tiles niet het antwoord op alles is (ik zie het niet als de toekomst van webmapping, maar als aanvulling op de mogelijkheden). Dus los van projectie, ervaren wij in de praktijk dat adoptie van bijvoorbeeld vector tiles met veel aanvullende zaken te maken heeft. Oudere clients / browser ondersteunen deze nieuwe techniek vaak nog niet. Maak je oplossingen voor bepaalde domeinen, heb je rekening te houden met feit dat die organisaties niet zomaar over de allerlaatste browsers en hardware beschikken. Om die reden zullen wij de komende jaren zeker nog twee sporen hanteren (raster én vector tiles naast elkaar). Wel met de push naar vector tiles overigens, ivm de diverse voordelen die het biedt (niet alleen voor eindgebruiker, ook voor de partij die het host en moet schalen / kosten etc). Verder kan je met vector tiles mooie kaartproducten maken, maar zijn we ook soms gewend geraakt aan de prachtige symbologie die mogelijk is via raster tiles. Ook op gebied van labeling. Vector tiles hebben nog wat aandachtspunten als het gaat om kwaliteit en de invloed die je kan uitoefenen op hoe labels geplaatst worden. Wij hebben in ieder ervaren dat dit ook veel van je vraagt qua kennis, omdat de wijze hoe je de kaart opzet t.b.v. vector tiles (met wat uitgebreidere symbologie, zoals in een basiskaart) echt anders is dan hoe je dit zou opzetten voor raster tiles.

Daarnaast zijn er heel veel ontwikkelingen op het gebied van snelle en slimmere rendering van geodata in de client, via bijv. WebGL (wat ook gebruikt wordt voor vector tiles). Ik heb het volgende dev sample online gezet om dit te illustreren: https://bouwjarenkaart.nl/ (beste weergave op tablet of desktop, en icm WebGL). Dit voorbeeld laat een Esri REST feature service waarbij er meer dan 200.000 panden naar de client gaan en daar weergegeven worden. Dit had ook gekund met vector tiles, maar die maak je dan vooraf. Dit voorbeeld laat zien hoe je ook al heel veel data snel kunt weergeven zonder de tussenkomst van vector tiles. Voordeel van deze opzet is dat we hier direct de bron REST feature service bevragen, de volledige JSON terugkrijgen en er client side van alles mee kunnen doen (opmaak aanpassen, queries, filters, editing etc). Wel is het zo dat initieel data laden wat trager is (je haalt immers nogal wat data op), maar eenmaal in de client is het razendsnel. Wat dat betreft denk ik dat we in een tijd zijn aangekomen dat er veel veranderingen gaande zijn en het één het ander niet vervangt (ivm kunnen garanderen dat toepassingen blijven werken), maar wel andere en nieuwe toepassingen mogelijk maakt voor specifieke doelgroepen. Het lijkt mij erg waardevol als kennis rond vector tiles breder gedeeld worden.

3 likes
#5

Wat een vet antwoord, bedankt voor je inzichten! Met je nuance dat vector tiles niet een antwoord op alles zijn ben ik het vooralsnog wel eens. Er zijn nu al toepassingen waar ze duidelijk voordelen bieden, en als na verloop van tijd bezwaren als labeling weg worden genomen zal dat aantal toepassingen steeds breder worden.

Op dit moment zie ik vooral kansen voor vector tiles als middenweg tussen wms en wfs. Voor bijvoorbeeld de BAG zie ik een oplossing zoals voor die bouwjarenkaart nog niet snel werken. Val je terug op rasterdata heb je weer geen mogelijkheid om de styling aan te passen. Als je de data zelf in beheer hebt kan je inderdaad hele mooie raster tiles opmaken. Gebruik je externe diensten als pdok of agol dan heb je het vaak maar te doen met de standaard symbologie. En kan het ‘misgaan’ als je verschillende van die bronnen wilt combineren. Om alleen de panden in de bag een andere kleur te geven ga echter ook weer niet een hele eigen poot opzetten.

Mooi trouwens om jullie rd-basiskaart in actie te zien.

#6

@Ynte de optie om ook voor andere services Vector Tiles beschikbaar te gaan stellen staat wel op de menukaart dus mogelijk dat het niet allen bij de BRT/BGT blijft. De discussie omtrent RD volgen we met grote aandacht voor eventuele vervolgtrajecten :slight_smile:

cc @RichardWitmer @John_Schaap @daniel.tewinkel @wouter.visscher

#7

@Anton: Ook in Mapbox GL wordt WGS84 data gerekt en gestrekt tot het weer op een plat vlak past. De data wordt geherprojecteerd naar world mercator / web mercator. En dit is een projectie waar old school geodeten van gruwelen :wink:

Voor nu zou het ook mogelijk zijn om ETRS89 data aan de een of andere tool stack te geven en te doen alsof het WGS84 is. :wink: Maar een structurele oplossing zou veel beter zijn. Voor het tonen van een paar kaartlagen kom je er wel mee weg, maar als je data uit verschillende bronnen wil combineren, loop je gauw tegen problemen aan.

@JBak: hebben jullie de uitbreiding van de Mapbox spec ook aan Mapbox doorgegeven? Het zou een zeer welkome aanvulling zijn. Ik ben benieuwd hoe zij daarop gaan reageren.

#8

@fsteggink Ja naar mijn weten wel, al weet ik niet of alles is opgenomen daarna. We hanteren overigens nog steeds de mapbox spec, en ook de mapbox gl style spec. Echter waar initieel ook de mapbox-gl-js werd gebruikt, is dat nu de eigen ArcGIS API for JavaScript met een eigen implementatie, mogelijk zit daar de crux rond projecties.

#9

De mapbox vector tile specificatie geeft al ruimte voor gebruik van welke projectie dan ook lees ik inderdaad: 3. Projection and Bounds. Het is mapbox-gl-js dat de keuze uiteindelijk beperkt tot web mercator. (En als ik het goed begrijp moet ook WGS/ETRS89-data eerst serverside geherprojecteerd worden worden voordat het naar de client kan(?)).

#10

Hierbij een update vanuit onze kant over de bevindingen rond het maken van vector tiles t.b.v. basiskaarten en het kunnen stylen van deze vector tiles.

Belangrijkste update is dat we onze vector tile basiskaart (Topo RD) uit beta hebben gehaald en nu definitief hebben uitgebracht. Deze wordt dus actief onderhouden. En zoals in deze thread al besproken is deze in de RD projectie.

Twee ontwikkelingen van de afgelopen weken:

Er is een nieuwe webapp gelanceerd waarmee je vector tiles met een eenvoudige UI kunt aanpassen. Hiermee wordt het voor eindgebruikers eenvoudig(er) om een eigen visualisatie variant te maken die past bij het gebruik. Als bijv. water meer nadruk nodig heeft, kan de gebruiker dit zelf configureren en hoeven er geen nieuwe tiles gemaakt te worden en opgeslagen te worden. Zie: https://developers.arcgis.com/vector-tile-style-editor. Voor het gebruik van een kaart in het Rijksdriehoekstelsel, zoals de Topo RD (vector tiled), hebben we ook een aparte How-to geschreven: http://www.esri.nl/~/media/esri-nl/tools-tips-tricks/How-to-bij-content-artikel

style_editor

Daarnaast hebben we het datamodel aanzienlijk eenvoudiger gemaakt. Qua bronnen maken we gebruik van o.a. BRT (TOP10NL, TOP50NL) en BGT. We hebben de structuur aangepast, zodat dit naar verwachting beter te begrijpen is voor de eindgebruiker die de stijl wil aanpassen. Zo zijn gebouwen uit de diverse bronnen samengevoegd, zodat een eindgebruiker maar in één laag de kleur hoeft aan te passen voor gebouwen ipv per databron. In totaal zijn er 6 hoofdklassen gekozen waarin alle lagen te vinden zijn: Bodemgebruik, Kunstwerk, Pand, Infrastructuur, Inrichtingselement en Administratief.

Tevens zijn enkele technische verbeteringen doorgevoerd in de kaart, vooral omtrent labels. Zo werden in de beta-versie de straatnaamlabels nog getoond op basis van lijnen, maar dit zorgde voor een storende hoeveelheid aan herhaling van deze labels. We hebben er daarom nu voor gekozen om op diepere schaalniveaus de openbareruimte labels uit de BGT te gebruiken, gewoon als punten met een rotatiehoek.

topo

Het volgende waar we nu aan werken is een vector tile hillshade van het AHN, zodat ook reliefvisualisatie gecombineerd kan worden met de vector basiskaart. Alles dus op basis van vector tiles, geen rastervisualisatie. Als er interesse is bij anderen over hoe we die maken, laat het dan gerust weten. We kunnen een sample delen zodra we net iets verder in het proces zijn. Als er andere vragen zijn, of feedback op de kaart is en keuzes die zijn gemaakt, horen we het graag. Het blijft een interessante puzzel om de diverse open bronnen te combineren…

Hebben anderen nog nieuwe bevindingen van recent rond het werken met of maken van vector tiles?

3 likes
#11

Met veel plezier gelezen! Wat een waardevolle aanpassingen hebben jullie doorgevoerd. Dankjewel voor het delen op het forum.

2 likes
#12

Eén van de interessante eigenschappen van vector tiles is het kunnen stylen van de kaart. Nina heeft tijdens haar projectstage bij ons de topografische vector tile basiskaart beetgepakt en omgetoverd tot een interactieve kerstkaart.

Ze heeft beschreven hoe ze dit heeft aangepakt:

De kaart zelf is hier te bekijken:
https://www.arcgis.com/apps/webappviewer/index.html?id=4aee0a8d9ba940a6bcf49017863a7017&extent=-33433.4161%2C363295.2398%2C356711.3642%2C542111.5974%2C28992

3 likes
#13

Superleuk, ik mis alleen nog een muziekje op de achtergrond! Mooi stageresultaat en verslag van Nina om trots op te zijn.

#14

Muziek gaan we maar niet aan beginnen :wink:
Beetje fout… maar ach, misschien gewoon omdat het kan met vector tiles:

De BRT/BGT gevisualiseerd als een valentijnskaart…
https://www.arcgis.com/apps/webappviewer/index.html?id=9df5f833cca843f59ffe8e11e6bb646f&extent=-8403.6182%2C390547.5421%2C303712.2061%2C519376.5998%2C28992

4 likes
#15

Ik veronderstel dat je de door PDOK inmiddels gelanceerde Tiles en Styles hebt gevonden? Wij zijn benieuwd naar jullie ervaringen met deze nieuwe OGC API’s.
Gisteren hebben we de bestuurlijke gebieden naast de BGT, BAG en 3D gezet: Bestuurlijke gebieden (BRK) nu ook als Vector Tiles via PDOK (OGC API’s)

#16

Ik ben er al een tijdje op verschillende manieren mee aan het spelen:

afbeelding
afbeelding818×813 144 KB

Nu er veel data beschikbaar begint te komen verwacht ik een versnelling in de migratie naar vector tiles. Dat is zeker mijn doel in ieder geval.

1 like