Geonovum wil een praktijkrichtlijn opstellen voor Vector tiles in Nederland. Werk jij met Vector tiles? En heb je technische kennis en ervaring die je wilt delen? Help en denk dan mee in deze interactieve sessie!
Vector tiling is steeds meer in opkomst. Daarnaast zijn ook de OGC APIs volop in ontwikkeling, op het gebied van gestandaardiseerde Tiling APIs, zoals OGC API Tiles (werkversie specificatie)
We merken dat er rond vector tiles behoefte is aan een Nederlandse praktijkrichtlijn.
Op 28 oktober (planning: tussen 10:00 uur en 12:30 uur, met lunch) organiseert Geonovum een werksessie om uit het werkveld input te krijgen voor de praktijkrichtlijn. Dit is een vervolg op de sessie die vorig jaar heeft plaats gevonden tijdens de OpenGeoDag. De input van deze sessie gaan we gebruiken om de praktijkrichtlijn op te stellen.
Vanwege de huidige situatie wordt het een online meeting. Je kan je aanmelden via https://fd10.formdesk.com/geonovum/VectorTiling. Als je je hier hebt aangemeld, ontvang je op 28 oktober een uur van tevoren (rond 9:00) de link voor de meeting.
Het programma is als volgt: 10:00 - 10:45
Welkom en procesafspraken
Presentatie doel Praktijkrichtlijn
Vector tiles - Waar staan we nu?
Afbakening onderwerpen - wat moet er in de praktijkrichtlijn?
Voorstel door Geonovum (op basis van sessie oktober 2019)
Mogelijkheid tot aanvulling onderwerpen
Vaststellen lijst
10:45 - 11:00 Pauze
11:00 - 12:30
Vaststellen en discussiƫren onderwerpen. Waaronder en in willekeurige volgorde:
Winding order (polygonen)
Technische specs: Mapbox VT spec 2.1
File extensie
Tile extent
Tiling schema
* CRS
* Gzipped aanbieden
* OGC API tiles
* Styling specification
* Documentatie met kleine pauze tussendoor
Is het gebruik van CRSen nog een van de bespreekpunten? Is hier vorig jaar al concensus over bereikt of kan ik dat nog ter discussie stellen? WGS84 lijkt me bijvoorbeeld totaal ongeschikt (zeker voor vectordata) omdat daarvoor geen nauwkeurige coƶrdinaattransformatie beschikbaar is. ITRS of ETRS89 zou wel kunnen. Daarnaast zitten er wat keuzes in het raster tile scheme voor RD die ik niet begrijp en waarvan ik me afvraag of het verstandig is die ook voor vector tiles te gebruiken.
Dat is wel heel kort door de bocht, en lijkt mij meer af te hangen met welk doel de vector tiles gebruikt dienen te worden. Voor iets als de bijvoorbeeld de brtachtergrondkaart is dit (ook) een prima projectie op te ontsluiten. Zeker gezien het gebruik van WGS84 (en ETRS89) groeit ten opzichte van RD.
VT (in WGS84) gebruiken voor inmeten enz, is natuurlijk een ander verhaal.
Maar als ik in mijn perspectief m.b.t. VT + WGS84 + achtergrondkaarten iets over het hoofd zie dan hoor ik dat graag.
Ik heb het expres wat stellig uitgedrukt om discussie uit te lokken. Maar ik meen het eigenlijk wel. Ik zal uitleggen waarom.
De enige bron voor WGS84-data is navigatie-GPS zoals een smartphone. Alle nauwkeurigere plaatsbepalingstechnieken (PPP, RTK, total station enz.) geven coƶrdinaten in ITRS, ETRS89 of RD-NAP.
Voor data met lage nauwkeurigheid (nauwkeurigheid in de orde van een meter) is het ontbreken van een nauwkeurige coƶrdinaattransformatie voor WGS84 inderdaad niet zoān bezwaar. Echter, in dat geval kan de data ook gewoon in ITRS of ETRS89 geleverd worden, ook als iemand het wil combineren met een smartphone-positie in WGS84. Het verschil tussen die CRSen is voor die nauwkeurigheid immers verwaarloosbaar. Om gebruikers de mogelijkheid te geven data makkelijk te combineren met hun navigatie-GPS-positie lijkt het handig de data in WGS84 te leveren. Het transformeren van data in ITRS, ETRS89 of RD-NAP naar WGS84 is echter lastig en voor de nauwkeurigheid niet nodig. Dus dat wordt vaak achterwege gelaten en wordt het label WGS84 aan data gehangen die eigenlijk in ITRS of ETRS89 is.
Data het label WGS84 geven, terwijl het in werkelijkheid eigenlijk ETRS89 of ITRS is, zodat gebruikers dat kunnen combineren met data die echt in WGS84 is (of waarvan ze denken dat die in WGS84, maar eigenlijk ook in ITRS of ETRS89 is), is niet handig. Het verschil tussen ITRS en ETRS89 is momenteel namelijk 0,8 meter. Het verschil tussen ITRS en ETRS89 wordt ieder jaar 2,5 cm groter en nauwkeurige meettechnieken in ITRS en ETRS89 steeds goedkoper en dus toegankelijker. De verwarring over wat voor CRS data met het label WGS84 in werkelijkheid heeft geeft dus fouten en dat gaat (zeker op termijn) problemen geven, terwijl dat helemaal niet nodig is.
In plaats van de onpraktische en onnauwkeurige transformatie naar WGS84 toe te passen, stel ik voor om het label WGS84 gewoon helemaal niet meer te gebruiken, maar data niet te transformeren er er gewoon het label aan te hangen van het CRS dat de data daadwerkelijk heeft.
De EPSG-code 4326 kan om nog meer redenen beter vermeden worden. Het specificeert namelijk niet welke realisatie van WGS84 bedoeld wordt, waardoor transformatie in veel software helemaal niet meer gaat. Bovendien lijkt het me voor vectordata handig om ook de hoogte op te slaan en daar dan ook EPSG-code voor 3D coƶrdinaten voor te gebruiken. Dus EPSG:7665 voor 3D WGS84-G1762. Of liever nog EPSG:7931 voor 3D ETRF2000 of EPSG:7912 voor 3D ITRF2014.
Voor WGS84 pseudo-Mercator zijn ook betere alternatieven zoals ETRS89-LCC (EPSG:3034) zoals INSPIRE adviseert als conforme transformatie, of echte mercator met hoogte (EPSG:6893). Maar dat is weer een heel ander probleemā¦
Ben graag aanwezig bij dit geheel. Volgens mij zouden we twee dingen moeten onderscheiden. Het uitwisselen van vector data in partities die toevallig tiles zijn, en vector tiles en hun projectie die nu (goed) worden ondersteund in webbased viewers.
Goede discussie al en mooi dat er interesse is. Te gebruiken CRS(en?) staat zeker op de agenda. De context / typisch gebruik voor Vector Tiles in het algemeen en de scope van de praktijkrichtlijn, gaan we ook behandelen lijkt me. @skinkie bedoel je dat ook met het onderscheid?
Correct micro versus macro uitwisseling. Je zou dan ook nog onderscheid kunnen maken tussen āfull tilesā met alle attributen en āslim tilesā die afgestemd is op de cartografie die erbovenop ligt. Als je dat onderscheid ook nog eens kunt vastleggen bij resource discovery zou dat helemaal mooi zijn. Ik zou zelfs nog een stapje verder gaan naar topologie uitwisseling zodat je het ook kunt gebruiken om reisplanners te voeden, beetje hoe valhalla het aanvliegt.
Ik wil ook wel weer deelnemen. Wel ben ik nieuwsgierig wat jullie zelf verwachten van deze virtuele bijeenkomst, mede in relatie tot wat vorig jaar besproken is. De uitwerking daarvan is meen ik blijven liggen, of in ieder geval qua terugkoppeling bij mij niet meer op het netvlies gekomen. Zijn er dusdanige ontwikkelingen dat er andere inzichten komen dan vorig jaar? Zijn de acties van vorig jaar al opgepakt? Verder sluit ik mij aan bij @skinkie dat het goed is om stil te staan bij enerzijds Vector Tiles (als specificatie), en anderzijds de techniek om tile-gedreven ook (volledige) vectordata via een API op te vragen.
Goed dat er nog meer interesse is, het wordt al een mooie groep zo.
@JBak het is een voortzetting van vorig jaar. Aan de ene kant is de uitwerking blijven liggen bij ons en is het nodig om dat af te maken, aan de andere kant is het ook tijd om naar nieuwe ontwikkelingen te kijken (zoals OGC APIs). Verder willen we toetsen wat de vorige keer besproken is.
Ik ben het met Jochem eens dat ITRS of ETRS89 meer geschikt zjn dan WGS84. Al heb ik altijd het gevoel dat ik niet goed snap waarom WGS84 toch telkens oppopt als de default. Hiervoor heb ik dit topic aangemaakt:
Ik wil nog wel een nuance maken over de nauwkerigheid van de transformatie van/naar WGS84.
De Dienst der Hydrografie geeft voor deze transformaties een mooi overzicht op hun website. In het bestand dat daar is te downloaden staat met bronvermedeling.
Transformaties tussen ITRF-s en WGS84-realisaties hebben de volgende precisie:
nabewerking: Omdat ik een vraag kreeg over de actuele WGS84 realisatie, hier ook de link naar het document waar WGS84-G1762 wordt beschreven en de relatie met ITRF2008.
Dank voor de reactie @lhuisman, goede input voor het CRS onderwerp in de werksessie. Ik vermoed dat WGS84 elke keer weer opkomt omdat we met wereldwijde standaarden werken. Dat is de basis voor andere standaarden en vaak het uitgangspunt voor tooling.
Maar ik meen het eigenlijk wel. Ik zal uitleggen waarom.