Nauwkeurigheid BAG coordinaten

Meer een stelling dan een vraag: in BAG (2.0) hebben coordinaten bijv van VBOs een mm nauwkeurigheid: bijv in EPSG:28992 123456.789. Wanneer we bijvoorbeeld voor een LIG of STA een “centroïd” berekenen in PostGIS bijv t.b.v. adrespunten lijkt mij deze nauwkeurigheid, 3-decimale significantie aan te houden.
Zie ook: Gebruik passende afronding en numeric typen voor x,y,lon,lat in adres tabellen · Issue #321 · nlextract/NLExtract · GitHub

Nu wordt het interessant voor omzetting naar WGS84/EPSG:4326, dus lat, lon coordinaten. Wat moet nauwkeurigheid worden?
Uit ver studie-verleden herinner ik iets als dat het gaat om totaal aantal cijfers om nauwkeurigheid te behouden.
Achter de comma zegt niet zoveel. Alles is terug te brengen naar machten van 10:
123456.786 is ook 0.123456789 x 10**6
Dus hier 9 cijfers. Interessant is dat lat van -90 naar 90 loopt en lon van -180…180. Dan zou lat “7 cijfers achter comma” en lon 6 cijfers. Iets als lat: 45.1234567 en lon: 123.123456 bijv.
Nu zijn lon/lat in EPSG:28992 gebied weer andere range: lat zeg 52.1234567 en lon 4.123456678 als je 9 cijfers wilt behouden…Moet dan lat 7 cijfers en lon 8 cijfers achter comma voor RD-gebied? Mis ik iets?

Interessant onderwerp. Ik heb hier al eens een blog aan gewaagd:

Je zou het kunnen testen door RD coördinaten te exporteren naar graden met 5, 6, 7 of 8 decimalen, en dan weer terug te converteren. De punten die te ver af gaan wijken van het oorspronkelijke punt, geven een indicatie welke decimalen niet geschikt zijn. Ik denk dat je op 7 of 8 uitkomt.

@Anton interessante, heldere blog! Ja 7 of 8 decimalen kwam ik ook op uit. Interessante vraag was of dat nog voor lat of lon moet verschillen enerzijds gezien verschillend numeriek bereik, anderzijds specifiek bereik voor RD-gebied. Maar zal ook weer afhankelijk zijn van nauwkeurigheid parameters in Proj transformaties.

Om verwarring te voorkomen zou ik het aantal hetzelfde houden, maar dat is een persoonlijke keuze :slight_smile: Theoretisch heb je wel gelijk vanwege het verschillende bereik.

Geodetisch gezien moet er onderscheid gemaakt worden tussen precisie (standaardafwijking), juistheid (systematische afwijking), nauwkeurigheid (standaardafwijking^2 + systematische_afwijking^2 = RMSE^2) en resolutie (cijfers achter de komma).

Vanuit de Rijksdriehoeksmeting adviseren we als equivalent van 3 cijfers achter de komma voor RD (1 mm) om 8 cijfers achter de komma te gebruiken voor decimale graden (1,1 mm NB en 0,7 mm OL) en 4 cijfers achter de komma voor boogseconden (3,1 mm NB en 1,9 mm OL).

RD-referentiepunten (GNSS-stations en kernnetpunten) zouden een nauwkeurigheid van ca. 1 cm moeten hebben, aangezien meest precieze landmeetkundige RTK-metingen een standaardafwijking van ca. 1 cm hebben. Met het hierboven genoemde aantal cijfers achter de komma heeft afronding geen significante invloed op de geometrische kwaliteit.

Ik weet niet wat de huidige doelstelling voor de precisie van de BAG is. Voor de GBKN was het 0,2 en 0,4 m voor stedelijk/landelijk gebied.

6 likes

Ik zou zeggen sin(0.0000001) * 6371000 = 0.63 meter. Dat is niet 1mm. Maar misschien doe ik nu dom.
Of je nu lon of lat doet maakt niet uit voor significantie. +180 - 180 is voor de hele omtrek. +/- 90 is maar voor de helft omdat je de andere helft van de overkant meet. 1 graad, hoogte of breedte, blijft 1 graad (hoewel de straal natuurlijk niet constant is).

1 like

Jan, Er zitten twee fouten in je berekening:

  • Je hebt een nul te weinig getikt;
  • Je rekenmachine staat op radialen i.p.v. graden.

sin(0,00000001°) * 6371000 m = 0,0011 m voor de geografische breedte.

Voor de geografische lengte moet je ook nog rekening houden met het feit dat de meridianen naar de pool steeds dichter bij elkaar komen:

sin(0,00000001°) * 6371000 m * cos(52°) = 0,0007 m voor de geografische lengte.

NB: Het bereik van de geografische lengte en breedte (-180 – +180 / -90 – +90), oftewel het aantal cijfers voor de komma, heeft in dit geval geen invloed op het bepalen van het aantal significante cijfers.

1 like

HAHA, dat is wel erg grappig. Doet me beetje denken aan hoe ik vroeger dit soort rekensommen aanpakte.

Ik had de sinus beter thuis kunnen laten:
precisie / 360 = 0.0001 / 40.000.000
precisie ~ 0.000000001

2 likes

@Jochem e.a. bedankt voor inzicht en meedenken: samenvattend is het m.i…
Nauwkeurigheid (afgeleide) BAG Coordinaten:

  • RD/EPSG:28992: 3 cijfers achter comma (mm)
  • WGS84: decimale graden 8 cijfers achter comma (4 cijfers bij boogseconden)

Die goeie ouwe GBKN. 't mooie was dat alle gegevens met een PIB-attribuut werden gelkeverd, waaruit je de Precisie, Interpretatie en Betrouwbaarheid kon afleiden (als ik me de afkorting goed herinner, tenminste, 't is al weer even geleden :wink: ). 't is misschien geen slecht idee als iets dergelijks terug zou komen in de basisregistraties, maar dan zonder die ellendige Plaatsbepalingspunten uit de BGT. Want je kunt niet eens uit de beoogde schaal afleiden wat je kunt verwachten (wat bijvoorbeeld bij een Top10NL wel het geval is, die is duidelijk voor 1:10.000 bedoeld - en dus geeft dat een goede indicatie). Ik mis bij veel basisregistraie-gegevens toch wel een geodetische verantwoording wat dat betreft.

Nauwkeurigheid is strikt genomen niet de juiste term hiervoor. Dat is namelijk de term die gebruikt wordt voor de precisie en juistheid van de coördinaten als gevolg van de meetmethode. Het aantal cijfers achter de komma gaat over de resolutie waarmee de coördinaten opgeslagen worden.

De kwaliteitseis voor de precisie van de BAG schijnt niet wezenlijk anders te zijn dan van de BGT en diens voorganger GBKN en heeft dus een relatieve precisie van enkele decimeters. Nu verdient het aanbeveling om voor de resolutie één cijfer achter de komma meer te kiezen, maar millimeters lijken me dan niet strikt noodzakelijk, wellicht voldoet een cijfertje minder achter de komma ook.

Tenslotte is het beter om geen WGS84 te gebruiken, maar ITRF2014 of als je de coördinaten niet continu wil hoeven bijstellen vanwege de tektonische verschuiving van Europa met 2,5 cm/jaar dan kun je beter ETRF2000 gebruiken.

Idealisatie volgens mij. En ik kan me herinneren dat ze altijd de default waarden bevatten waardoor je er dus niets aan had :wink:

Oh ja, idealisatie, dat was het. En de delen van de GBKN die ik heb bijgewerkt/bijgehouden/ingemeten kregen wel degelijk de actuele waarden, daar hadden we in ons handboek een heel schema voor: of het gemeten was, of dat het een geschat dakoverstek was, enz enz enz. Op basis daarvan vulden we die PIB in, dus dat had m.i. best wel toegevoegde waarde. Maar ja, dat was natuurlijk niet heel NL (stukken NH en O…).

Ik vermoed dat PIB voor Puntprecisie, Idealisatieprecisie en Betrouwbaarheid stond (of had moeten staan), want idealisatie is onderdeel van de precisie (HTW96 blz. 44).