NLDEPSG28992Scale vs EPSG:28992 in WMTS

Uit onderstaande linkje komt voort dat het advies is om NLDEPSG28992Scale te gebruiken. Waarom wordt in de WMTS van PDOK dan EPSG:28992 als identificatie gebruikt?

Als ik het goed begrijp gaat het alleen om het label dat er aan hangt dat strikt genomen misschien niet goed is, maar in praktijk geen verwarring geeft omdat het geen invloed heeft op de tegels of de ligging van de tegels?

Klopt dit?

  • EPSG:28992 is de CRS-code van RD
  • NLDEPSG28992Scale is de tile-scheme-code van het officiĆ«le tile-scheme voor RD

Of kan er toch verwarring optreden, bijvoorbeeld omdat er soms ook andere tile-schemes dan de officiƫle gebruikt worden voor RD? Ik weet dat Topotijdreis zich niet aan de tiling-richtlijn houdt.

Laat ik het zo zeggen. Er zijn overheden met interne tile caches die zich aan de standaarden houden, maar PDOK dan weer niet. Ik vroeg me dus af waarom PDOK zich niet aan de strikte definities houdt. En ja het is wel een probleem omdat als je een applicatie ontwikkelt waarbij je test op de publieke voorziening van PDOK maar binnen de overheid wordt gebruik gemaakt van een andere definitie, krijg je daar onherroepelijk problemen mee.

Ik weet nu nog steeds niet zeker of ik begrijp wat je bedoelt. Verwijst het label EPSG:28992 volgens jou naar een andere tile-scheme-definitie dan NLDEPSG28992Scale, Ć²f is EPSG:28992 nooit een correct label voor een tile-scheme-definitie?

Ik heb geen mening over wat correct is. Ik vind een definitie die de projectie aangeeft al snel leesbaar. Maar als ons nationale instituut aangaande geostandaarden aangeeft dat het anders zou moeten, waarom is het beheer van PDOK daar dan niet trouw aan?

Ik weet nog altijd niet zeker of ik begrijp wat je bedoelt. Verwijst het label EPSG:28992 volgens jou naar een andere tile-scheme-definitie dan NLDEPSG28992Scale, Ć²f zijn het twee verschillende labels voor dezelfde tile-scheme-definitie?

Ik denk dat het twee identieke schemaā€™s zijn met een ander label.

1 like

Ik hoop dat PDOK meeleest, en hier inhoudelijk op kan reageren. Vanuit mijn rol bij de NSGI/Rijksdriehoeksmeting ben ik gerustgesteld dat er (afgezien van voor Topotijdreis) geen afwijkende tile-schemes voor RD in gebruik zijn. Verwarring over labels komt helaas meer voor o.a. omdat voor veel gebruikers de verschillen tussen alle termen en codes niet zo helder is:

  • RD tile scheme: NLDEPSG28992Scale
  • RD coordinate system (EPSG CRS): 28992
  • RDNAP compound coordinate system (EPSG CRS): 7415
  • RD projection (EPSG conversion): 19914
  • RD geographic coordinate system (EPSG CRS): 4289
  • RD datum (EPSG datum): 6289
  • RD transformation 2018 (EPSG transformation): 9282
1 like

Voor zover ik begrijp waar je op doelt, voldoet PDOK prima aan wat jij als standaarden aangeeft. Het documentje waar je naar verwijst, heeft het over een Well Known Scale Set, die bij de EPSG:28992 Tile Matrix Set hoort. De WMTS geeft keurig netjes aan dat deze Tile Matrix Set ondersteund word, maar dat is iets anders dan de Well Known Scale Set.

Lees de definities maar eens goed door: Open Geospatial Consortium paragraaf 6.2 gaat over de Tile Matrix Set (Die gerapporteerd word door de Capabilities van de WMTS!), paragraaf 6.3 behandeld de WKSS (wat dus iets anders is dan de TMS!).

For the record: ik ben niet van PDOK :wink: dus wellicht kan iemand van PDOK of liever nog Geonovum, maar vogens mij is dit waar je verwarring vandaan komt (of ik begrijp je vragen niet goed).

De Well Known Scale Set en de Tile Matrix Set zijn inderdaad twee verschillende concepten. Ik had me niet eerder verdiept in de krochten van de tiling standaard, bedankt voor dit inzicht!

Wat me verbaast is dat de NL Praktijkrichtlijn Tiling niet expliciet maakt wat de Tile Matrix Set identifier moet zijn voor de Nederlandse Tile Matrix Set (TMS). De gebrek aan explicitering in de Praktijkrichtlijn werkt deze verwarring in de hand. Misschien was destijds het gebruik van EPSG:28992 als identifier zo vanzelfsprekend dat het onbenoemd gelaten is. En in de praktijk zorgt het ook niet voor problemen (voor zover ik weet).

Op dit moment wordt er ook gewerkt aan een praktijkrichtlijn voor vector tiling. Hierin wordt weer een nieuwe identifier gebruikt voor dezelfde Tile Matrix Set NetherlandsRDNewQuad. Ik heb een issue aangemaakt om de oude identifier conventie te handhaven EPSG:28992.

1 like

Ik vermoed dat daar de oorspronkelijke verwarring vandaan komt: dat het CRS de naam EPSG:28992 heeft, de TileMatrixSet exact dezelfde naam heeft, maar dat de WKSS ineens een adere naam heeft. Uit het feit dat het om een ander object (of XML Element) gaat, kun je afleiden dat het een ander ding is, dat wel betrekking heeft op die goeie ouwe RD. Maar het wekt wat verwarring op.

Bovendien is dat documentje van Geonovum al van een behoorlijke tijd geleden, van voor de definitie van het OGC van de Tile Matrix Set. Maar het zou goed zijn als dat rechtgetrokken word inderdaad. Wat wel vervelend is, is dat de OGC documentatie zegt dat de identifier uniek moet zijn voor de server. Kan ik me vanuit de praktijk iets bij voorstellen, maar als je iets landelijks of zelfs Europees op wil zetten is het niet handig. Het zou wellicht een goede zaak zijn als epsg.org uitgebreid zou worden met TMS en WKSS info, als dat door de authoriteit van een CRS gedefinieerd is.

1 like

Ik denk dat het misschien goed zou zijn om de definities van CRSen en tile-services beter af te stemmen. Maar ik zie niet snel gebeuren dat EPSG info over TMS en WKSS gaat opnemen. De EPSG registry is een dienst van de vereniging van International Oil & Gas Producers, zij zullen hier niet veel behoefte aan hebben. Daarnaast is de definitie van een CRS en definitie van een TMS of WKSS toch wel echt een andere expertise: verschil tussen landmeetkunde en GIS. Wat ik weet van WMS, WMTS en dergelijke komt vooral doordat ik graag een goede topografische kaart op mijn telefoon wil kunnen gebruiken als ik in mijn vrije tijd in binnen- of buitenland ga wandelen. Vanuit mijn werk bij de Rijksdriehoeksmeting kom ik hier nauwelijks mee in aanraking.

Inderdaad aardig diep de ā€œkrochtenā€ van de specs in. Goed punt. En dank @antonbakker voor het issue aanmaken.

1 like