BGT visualisatie, over elkaar heen, verschillen

[Allroads]

De BGT data kan je via verschillende manieren tot je laten komen en visualiseren met verschillende programmatuur.

BGT omtrekgericht via wmts als ondergrond, met coordinaat stelsel

BGT via API binnenhalen voor verder gebruik.
Je doet dat zelf of je maakt gebruik van derden, die het omgezet hebben in een voor jouw bruikbare vorm. Een postgres database.

En dan vergelijk je die twee.

Waarom ligt die node niet op de hoek van de onderlaag BGT omtrekgericht?

Een belangrijker vraag is.

Hoe kan het, dat ogenschijnlijk de node in verticale richting wel op de lijn ligt en in horizontale richting verschoven is?

Wat is daar de oorzaak van?

Hoe corrigeer je zo’n afwijking?

Hier is de BGT data omgezet naar WGS84 met een afronding van 7 cijfers achter de komma.
Gevisualiseerd met een EPSG:3857 projection en met een BGT omtrekgericht tile projection EPSG:3857

Wat is de verklaring tussen het verticale en horizontale verschil?

Een verschil waar je later opmerking over krijgt van, het ligt hier niet goed.
In Qgis.

[rwal]

Welke laag heb je gebruikt va de API?

• BGT Vector Tiles
• BGT Features
• BGT download

Bijv de vector-tiles zijn niet de originele BGT geometrieën. Deze zijn versimpeld oid.

Indien je exacte data wilt gebruiken, is het toch aan te bevelen om download of OGC features te gebruiken. BGT visualisaties zijn voor een ander doel.

Zie ook Keuzehulp BGT producten - Kadaster.nl zakelijk

[Allroads]

@rwal

Welke laag heb je gebruikt va de API?

Wat precies gebruikt is weet ik niet. Via NL extract. Data komt bij derden vandaan. En is door een ander omgezet naar WGS84 EPSG:4326.

Ondertussen wel een stapje verder.

Het probleem als hierboven beschreven.
Welke ik kon reproduceren in Qgis, omdat in een ander programma de basis instelling projectie EPSG:3857 heb, had ik deze ook gebruikt in Qgis. En kreeg het verschil in ligging.
Nadat ik een opmerking kreeg, zet die QGIS basisinstelling projectie op Rijksdriehoek EPSG:28992. En in Qgis de laag BGT omtrekgericht EPSG:28992 had gekozen. Kreeg ik wel, dat BGT omtrekgericht en de file met data wgs84 gelijk lagen.

Daarna heb ik in dat andere programma naar die mogelijkheid gekeken en kon daar ook RD 28992 kiezen en als default ingesteld en omdat dat programma naar de basis projectie kijkt en dan uit de WMTS capabilities, de passende tilematrix projectie er bij zoekt, krijg ik ook de Rijksdriehoek tiles uitgeleverd met tilematrix 28992 en dan ligt de data wel gelijk met de lijn. Of moet ik zeggen dan ligt BGT omtrekgericht wel gelijk met de data. Het is maar net vanaf welk kant je het bekijkt, en tot de conclusie komt daar ligt het probleem.

Omdat het programma, dat wereldwijd wordt gebruikt vaak door mensen zonder projectie kennis, die het ook wereldwijd gebruiken, stelt men het in als EPSG:3857, veelal bij installatie zo ingesteld, de default. Gebruikt men dan een Nederlandse laag, als beste ondergrond, dan heeft men die kleine verligging over de horizontale as. Voegt men dan BGT data toe (EPSG:4326), ligt het altijd net even verkeerd. Ik vindt het irritant, andere zullen dat ook denken, of denken het is niet correct.
Iedereen bereiken om te zeggen je moet dan RD 28992 gebruilken is niet te doen, men gebruikt ook nog andere programma’s.

In QGIS is het zo je kan de basisprojectie instellen en zelf de layermatrix projectie kiezen
Nu heb ik de basislaag ingesteld op. 28992 en niet gezoomd

En de twee lagen geactiveerd.

Dan lijkt de BGT omtrekgerichtlaag 3857 niet goed te liggen.

Stel ik de projectie in als 3857 ik heb niet gezoomd.

Ook hier de BGT omtrekgerichtlaag 3857 wijkt af.

Trek ik de goede conclusie?

Is hier wat aan te doen, wat de bruikbaarheid ten goede komt.

[Just_OSGeo]

Denk dat op moment dat EPSG:3857 gemengd wordt met andere projecties, met “WGS84” bedoel je denk ik EPSG:4326, houdt cm-nauwkeurigheid op. Zeker als originele data EPSG:28992 (en zelfs die projectie is niet precies “RD”). Dit probleem is al heel oud, ook uit de tijd van Google Maps, EPSG:900913 (Web Mercator in feite EPSG:3857 ) met daarop GPS (EPSG:4326) -coordinaten. Het volledig in EPSG:28992 werken zou mijn suggestie zijn.

[sbjager]

Ben het volledig met Just eens. Daarnaast moet je ook niet vergeten dat de verschillen die je ziet, in dit geval rapporteer je over een verschil van 6 centimeter, volledig binnen de nauwkeurigheids- en precisie eisen van de BGT valt. Dus zelfs als je niet twee keer dezelfde gegevens met elkaar zou vergelijken in verschillende projecties, is 6cm verschil te verwaarlozen. Dat je tot op een micrometer kunt inzoomen in de meeste software doet er niets aan af dat de meeste data is ingewonnen met een standaardafwijking van 15 centimeter als je geluk hebt (meestal zal dat hoger zijn). Dat is ook een ding dat de meeste mensen zich niet realiseren. In dit geval speelt het niet, maar ik zie het nog steeds gebeuren.