geonovum / praktijkrichtlijn-vector-tiling Goto Github PK

Voorstel in tekst aan het uitwerken welke CRSen, liefst zo specifiek mogelijk codes openemen. Per CRS een origin definieren. Naar een volwaardig tile schema toe per CRS.

Input van CRS specialisten is nog gewenst

We gaan nu uit van 256 pixels. Of willen we juist 512 of 1024 voor Retina schermen als default? Mapbox heeft 512 als default, fallback 256.

Wat vindt de groep?

Het zou handig zijn als er een linkje naar https://geonovum.github.io/praktijkrichtlijn-vector-tiling/ wordt opgenomen in de about van het repository. Zie bijv:

Doel: cartografie. Kunnen er aanbevelingen komen over welke attributen mee te leveren? Of wordt dit (later) iets voor best practices?

1. Aanbieden van vector tiles (H 5)
   1. API
   2. Download
2. Documentatie
3. Styling

Stukje over platte index kan weg, want wordt al bepaald door de TileMatrixSet. Kan nog wel nuttig zijn als achtergrond, past daarom beter bij best practices document. Tekst verplaatsen.

In H4 wordt de OGC API Tiles benoemd die pas in H5 wordt benoemd als eis. Deze dus eerder als eis opnemen om het gehele verhaal in het doc beter te laten lopen.

Na goedkeuring via mail, werkgroepleden noemen in Hst 1

Bijlage over CRS onnauwkeurigheid: veel tekst / onderbouwing, doen we nergens anders in doc. Zou beter in bijlage kunnen.

Volgorde:

1. WGS84 en waarom standaard
2. commentaar onnauwkeurigheid -> bijlage
3. Noot OGC API Tiles 8 tilemtarixsets ids + voor RD niet
4. dan de eis met 3 CRSen
5. dan de tilematrixsetid publicatie als eis

Delen die over scope gaan eruit.

Aansluiten bij bestaande specificaties en OGC standaarden.

Praktijkrichtlijn, geen verplichting. Best practices staan verderop genoemd

Welke term gebruiken? vector tiles, tegels of allebei door elkaar

Dat sectie 3.3 Vector tiles aanbieden over aanbieden en publiceren dmv webservices gaat is nu impliciet.

Voor het aanbieden en publiceren van vector tiles is nog geen open standaard gereed.

Voorstel om dat expliciet te maken door bijvoorbeeld toevoeging van door middel van webservices:

Voor het aanbieden en publiceren van vector tiles door middel van web services is nog geen open standaard gereed.

Statement in 4.2 Eis: te gebruiken TileMatrixSets is niet correct:

Let op, de resolutie in de TileMatrixSet is niet van toepassing op vector tiles.

In het document OGC Two Dimensional Tile Matrix Set wordt de afmetingen van een tegel in "echte" wereld als volgt berekend:

pixelSpan = scaleDenominator×0.28 10-3 / metersPerUnit(crs);
tileSpanX = tileWidth×pixelSpan;
tileSpanY = tileHeight×pixelSpan;

Zie hier bijvoorbeeld het verschil tussen grootte van tegels op Z1 van het rd tile grid bij een tileWidth,tileHeight=256 vs tileWidth,tileHeight=512.

Dit geldt voorzowel raster als vector tiles. Dus de resolutie/scaleDenominator is wel degelijke van toepassing op de afmetingen van de vector tiles.

Het is wel zo dat deze resolutie niet direct de resolutie vertegenwoordigt van de geometrieen die in de vector tiles geencodeerd zijn (maar er is wel een relatie, aangezien tileSize van 256x256 weer opgedeeld is in een 4096 discrete eenheden).

N.a.v. eerste werksessie scope (hoofdstuk 2) iets anders geformuleerd. Graag reviewen.

Ter overweging, uit sessie 30 juni 2021: maak een checklist, q/a doc met daarin een overzicht van de eisen, wat makkelijk te gebruiken is bij testen.

Encoding van data is nu een aparte eis bij het maken van Tiles, maar is dat wel nodig als Mapbox VT wordt voorgeschreven?

Waarom is de extensie en mimetype vrijgelaten, zie 3.2.1 Eis: Vrije Bestands Extensie? Ik kan me de discussie hierover niet meer herinneren.

Zou het niet beter zijn voor de interoperabiliteit dit wel voor te schrijven?

Overigens lijkt me dit geen EIS, aangezien het vrij in te vullen is. Is eerder een absentie van een EIS

In 6.2 Eis: Handmatige TileJSON wordt voorgeschreven hoe te implementeren. Moet de praktijkrichtlijn niet alleen voorschrijven wat te implementeren? Zo ja dan voorstel om volgende alinea te schrappen.

In de praktijk betekent dit het handmatig aanleveren van een TileJSON bestand. Ook zijn er software tools die een TileJSON of Capabilities bestand genereren. Controleer hierbij of alle van de volgende minimale aanbevelingen juist zijn opgenomen.

En titel van sectie aan te passen naar 6.2 Eis: TileJSON

Sommige van de hieronder opgesomde redenen om vector tiles te gebruiken zijn ook van toepassing op andere vector data zoals bijvoorbeeld vectordata uit WFS of geojson. WFS en geojson hebben echter als belangrijk nadeel dat ze ofwel langzaam ofwel omvangrijk kunnen zijn waardoor problemen met datatransport en geheugen kunnen ontstaan. Het toepassen van tiles voor vector data lost de problemen van trage services of omvangrijke bestanden grotendeels op.

Een aantal redenen om vector tiles te gebruiken:

• werken met omvangrijke vectordatasets
  • alleen downloaden wat je nodig hebt
  • minder geheugengebruik
  • snellere weergave met minder rekentijd
• met vector (-tiles) wordt de weergave bepaald door de weergavetoepassing
  • selecteren en filteren van weer te geven data
  • instellen van render parameters (kleur, lijndikte, transparantie, symbolen etc.) bij de data
  • selecteren van weer te geven attributen, instellen klassificaties
  • instellen tekenvolgorde
  • on-the-fly koppelen met externe attribuut-data
• met vector (-tiles) is de data aan de client-zijde beschikbaar voor meer interactieve toepassingen
  • instantaan opvragen van data bij kaart-elementen
  • interactief oplichten van elementen
  • editen of verwijderen van elementen (=wegfilteren bronelement + toevoegen editable element)
  • interactief filteren of selecteren van elementen
• met vector (-tiles) kun je traploos zoomen
• vector tiles zijn meestal compacter dan raster
  • minder data versturen tussen client en server
  • minder opslagruimte op server
• vector tiles zijn zeer geschikt voor grootschalige toepassingen (hoge zoomlevels)
  • mogelijkheid van overzooming (viewer verder ingezoomd dan zoomlevel van bron-tile)
  • gedetailleerde tiles hoeven vanwege mogelijkheid overzoomen niet gegenereerd te worden
    • bespaart rekentijd bij het voorbereiden van de data
    • bespaart datatransport via het netwerk
    • bespaart opslagruimte op de server
    • door minder data meer efficiënt gebruik van caches
• meer?

Redenen om geen vector tiles te gebruiken

• weinig vector data (alles past in 1 bestand of in 1 download)
• de brongegevens zijn rasterdata (foto's, dtms, andere data-rasters)
• geen kennis, behoefte of tijd om eigen kaart-weergaves te maken
  • (nog) geen standaardmethoden beschikbaar styles voor het renderen van vector uit te wisselen
• er worden primitieve clients gebruikt die geen vector data kunnen renderen
• het kost meer werk om gedetailleerde data te aggregeren voor kleinschalig (=lage zoomlevels) gebruik
• meer?

Nalopen waar deze in gebruik zijn en de goede linkt gebruiken

@thijsbrentjens loopt de links na als ze opgenomen zijn of het de technische spec (github) is of de docs. De technische spec als referentie opnemen.

Zie #20

Persoonlijk ben ik niet bekend met het begrip "vector tile schema". Wordt hier met Vector tile schema eigenlijk niet TileMatrixSets bedoeld? Misschien beter om dan de kop 4. TileMatrixSet te gebruiken?

Een snelle Google search leert dat het begrip vooral gebruikt wordt het schema van de data in de vector tiles aan te duiden (lagen en attributen in een vector tile)

En nog een klein detail in de tweede alinea van 4.1 Coördinaat Referentie Systemen:

Afhankelijk van de toepassing kan dit zeer ongewenste effecten hebben.

Voorstel om kwaliticatie zeer te verwijderen, zeer ongewenst is ook ongewenst (maar andersom niet noodzakelijkerwijs).

Er zijn twee onderdelen met het onderwerp Vector tiles aanbieden .Voorstel om sectie 3.3 Vector tiles aanbieden onder te brengen in 5. Vector tiles aanbieden.

Alinea over interne indeling vector tile valt onder sectie A.3 Impact onnauwkeurigheid WGS84 gering voor beoogde vector tiling toepassingen, maar de onnauwkeurigheid van een vector tile als het gevolg van het interne coordinatenstelsel van 4096x4096 heeft niets te maken met de onnauwkeurigheid van WGS84. M.i. vertroebelt dit de discussie over nauwkeurigheid van vt's.

Daarom voorstel deze alinea elders in het document onder te brengen.

Gaat specifiek om deze alinea:

Voor het maken van vector tiles zullen geometriëen omgerekend worden naar het lokale stelsel van een vector tile, in integers (vaak in een bereik van 0-4096 bij 0-4096). Dit betekent dat de originele geometrie nauwkeurigheid verliest in een vector tile.

Wellicht kan deze alinea ergen in 3. Basis specificaties.

Uitwerken hoe je publiceert welk CRS de tiles hebben. Check ook OGC API Tiles.

willen we aansluiten bij OGC API Styles?

Zie ook

https://ogc-vtp.gospatial.org/ogc-api-tiles/collections

https://www.youtube.com/watch?v=uGo5hYUwFP0

Maak een aparte aanbeveling: gebruik MIME-TYPE van Mapbox

Een van beide formaten voorschrijven of allebei?

Eerst rest doc verder uitwerken.

Tekst:
"Voor het maken van vector tiles zullen geometriëen omgerekend worden naar het lokale stelsel van een vector tile, in integers (vaak in een bereik van 0-4096 bij 0-4096). Dit betekent dat de originele geometrie nauwkeurigheid verliest in een vector tile."

Vector tiles kunnen zeer nauwkeurig zijn, namelijk door verder in te zoomen en tiles op te vragen met een grotere zoom coördinaat. Bij het inzoomen beschrijven de tiles van 4096x4096 integers een steeds kleiner stukje wereld. Wanneer bijvoorbeeld een tile wordt opgevraagd die een stukje wereld van 1000x1000 meter bevat, dan zijn er per meter 4096/1000=4 integers beschikbaar. 1 integer heeft dan een nauwkeurigheid van 0.25 meter en dat is al een grotere nauwkeurigheid dan de beschreven tektonische verschuiving van 0.8 meter. Als je verder inzoomt, wordt de nauwkeurigheid nog groter.

Bij weergave-toepassingen is het vooral belangrijk dat elementen uit verschillende kaartlagen en bronnen goed op elkaar aansluiten. Het is dus van belang dat voor alle bronnen ofwel dezelfde CRS wordt gebruikt ofwel dat er CRSsen worden gebruikt waartussen openbaar toegankelijke transformaties beschikbaar zijn.

Tekst:
"Het verschil tussen WGS84 en ETRS89 is daardoor opgelopen tot ruim 0,8 m in 2020."
is niet zo duidelijk. Dat zou bij het combineren dus kaarten opleveren waarop je duidelijk dubbele lijnen zou zien? Als dat gebeurt, dan betekent dat toch dat de toegepaste transformatieparameters tussen de beide CRS-sen verkeerd zijn? Er zijn toch transformaties beschikbaar waarbij je het jaar kunt opgeven waarvoor de WGS84 data is vastgelegd? Dat levert dan resultaten met een nauwkeurigheid van minimaal de gemiddelde jaarlijkse tektonische verschuiving (2.5 cm)?

In hoofdstuk 1 naar verwijzen en waar relevant in andere paragrafen ook

Meer toelichting / uitwerking bij best practices. Voor nu vooral verzamelen van onderwerpen die in Best practices doc kunnen komen

TileJson gebruiken of niet? Wat doet OGC API Tiles?

Details als iets over TileJson wordt beschreven: hoe omgaan met Tile json overzooming?

De 4.3 Eis: Publicatie van gebruikte CRS lijkt me overbodig, omdat dit al wordt voorgeschreven door de OGC API Tiles. Voorstel om deze eis laten vallen, of motiveren waarom dit toch belangrijk genoeg is om toch extra voor te schrijven.

In deze discussie op GeoForum werd duidelijk dat in de oude praktijkrichtlijn tiling het verschil tussen de Well Known Scale Set (WKSS)( en Tile Matrix Set (TMS) niet duidelijk wordt gemaakt. Verder wordt er niet voorgeschreven wat de identifier van de TMS moet zijn (die in richtlijn wordt omschreven). In de praktijk wordt gebruik gemaakt van de identifier EPSG:28992.

De identifier van de TMS in deze praktijkrichtlijn komt niet overeen met de huidige conventie; EPSG:28992 vs NetherlandsRDNewQuad. Voorstel is om de huidige conventie te handhaven.

Overigens bevat de XML encoding beide identifiers.

Duplicatie informatie in secties 4.1 Coördinaat Referentie Systemen
en A.3 Impact onnauwkeurigheid WGS84 gering voor beoogde vector tiling toepassingen. In beide secties is de onnauwkeurigheid van WGS84 onderwerp. Voorstel om dit in 1 sectie te behandelen.

Voorstel om van 5.3 Aanbeveling: gebruik HTTP Header Content-Encoding bij gzip compressie op de webserver een eis te maken.

OpenLayers kan er bijvoorbeeld niet mee omgaan als de Content-Encoding: gzip header niet is toegevoegd. Ik verwacht dat er nog meer clients zijn die hier op stuk lopen.