geonovum / praktijkrichtlijn-vector-tiling Goto Github PK
View Code? Open in Web Editor NEWPraktijkrichtlijn Vector tiling
Home Page: https://geonovum.github.io/praktijkrichtlijn-vector-tiling/
Praktijkrichtlijn Vector tiling
Home Page: https://geonovum.github.io/praktijkrichtlijn-vector-tiling/
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?
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:
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:
Redenen om geen vector tiles te gebruiken
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.