Het is inmiddels 2025 Jochem. Ik ben een nieuwe QGis gebruiker en wilde heelgraag deze ellisoïde in QGis en QField gebruiken om goede NAP hoogten te krijgen. Maar of ik zoek niet goed og het zit er (nog) niet in.
Wat doe ik fout? Of wat is er nodig om het wel in bijde programma’s te gebruiken?
Moderator edit: dit bericht is van een oud topic afgesplitst
Het lijkt me beter als je voor je vraag een nieuw topic start. Je vraag over NAP in QGIS lijkt ook niet zo veel met RD in PROJ4 te maken te hebben.
Zou je ook wat meer informatie kunnen geven wat je wil doen in QGIS? Als je een enigszins recente versie van QGIS gebruikt zou de transformatie van/naar NAP-hoogte goed moeten gaan. Van/naar/met welk (hoogte)coördinatensysteem wil je NAP-hoogte omrekenen/combineren? Wat gaat er fout? Of waarom denk je dat RDNAPTRANS™2018 niet gebruikt wordt door QGIS? Welke ellipsoïde bedoel je met “deze ellipsoïde”? enz.
ZOals Jochem ook al aangeeft: Waar ben je precies naar op zoek? Wat is de achterliggende informatie vraag?
Want
voor deze vrij eenvoudige vraag is het voldoende om de AHN als kaartlaag op te nemen. Als je dan op een bepaald punt de informatie van die laag opvraagt met het i-symbooltje, krijg je de NAP-hoogte ter plaatse. Daar heb je verder niks voor nodig. Mocht je vector-informatie z-waardes willen geven op basis van de AHN, dan zijn daar tools voor in QGis, maar daar heb je wederom geen extra info over EPSG:28992 nodig. Pas als je je gegevens daarna wilt transformeren naar een ander coordinatenstelsel, heb je die info nodig, maar 99 van de 100 keer is dat binnen NL helemaal niet nodig.
Dus: kun je wat meer uitleg geven over wat je wil bereiken? Dan kunnen we daarna helpen met hoe dat te doen.
Tsja die van de ahn ken ik voor bestaande situaties. Heb zelf aan de wieg van deze ontwikkeling gestaan😊
Wat ik wil is ook in het veld direct de juiste hoogte kunnen meten tov NAP, voor bijvoorbeeld een peilbuis, het uitzetten van een omwerp (na inmeten) ik gebruik daarvoor QField. Dat had ik idd beter even kunnen vermelden. Nu krijg ik x,y prima ook in rd. Maar z geeft echt hele rare waarden terwijl de verticale nauwkeurigheid als 0,010m wordt weergegeven. Ben zelf ook aan het zoeken… vlgs mij vergis ik me en heb ik daar nlgeo2018 voor nodig. Klopt dat?
Als RD goed gaat maar NAP niet, dan zou dat inderdaad kunnen komen door het ontbreken van NLGEO2018.
Zijn je hoogtes dan misschien 40 tot 46 meter te hoog? Met wat voor (GNSS-)apparatuur meet je de positie eigenlijk? En wat voor correctieservice gebruik je daarbij? Doet die apparatuur de omrekening naar RD en NAP of laat je QGIS/Qfield de omrekening doen?
Dag Jochem en Stefan,
Dank je wel voor je snelle reacties. Ik gebruik de ardusimple rtk2B budget met een ardusimple meet hun budget Simple multiband antenna.
O ja, ik laat Qfield de omrekening doen. De apparatuur geeft de ‘kale waarden’ door. Daar zie je idd de 40-46m te hoog; WGS84?).
Nu heb ik inmiddels NLGEO2018.tiff (die heb ik gekopieerd uit het nl_nsgi dirctory dat standaard bij QGIS wordt geïnstalleerd) in het /Proj directory van Qfield gezet. En natuurlijk corrigeer ik ook voor de lengte van de meetpaal in Qfield. Daarmee krijg ik waarden die met NAP zouden kunnen kloppen. Maar… ik heb gisteren het ding eens gezet op een paar in 2021 gemeten NAP bouten in de omgeving. Op de ene krijg ik een afwijking van precies 20 cm te laag en op de andere 10cm te laag.
Ik gebruik de base bij Astron in Westerbork (afstand ca 15km) als referentie station.
Dan is de base die je gebruikt station WSRA00NL of WSRT00NL van de NSGI?
In dat geval zijn de ‘kale’ coördinaten die uit je RTK-ontvanger komen in de Nederlandse realisatie van ETRS89 (al noemt je ontvanger dat misschien WGS 84).
Een vaste waarde van een aantal centimeter te laag zou dan kunnen komen door het verschil tussen het ARP (het antennereferentiepunt aan de onderkant van de antenne) en het PC (fasecentrum middenin de antenne) van de base station. De stations van de NSGI geven volgens internationale standaarden de coördinaten van het ARP. Als jou RTK-ontvanger het antennetype van de base niet kent dan krijg je een hoogtefout. (Bij RTK-netwerken wordt een zogenaamde null antenna gebruikt en speelt dit probleem niet.) Meestal kan dit opgelost worden door een antennekalibratiebestand in je RTK-ontvanger te zetten.
Maar als de hoogtefout bij jou niet op iedere NAP-bout hetzelfde is, dan is er wat anders aan de hand. Tenzij je heel toevallig een NAP-bout met een fout in de gepubliceerde hoogte hebt gebruikt. Voor het testen is het misschien handiger om een paar Kernnetpunten te gebruiken. Die zijn beter geschikt voor het opstellen van een RTK-ontvanger, wat de nauwkeurigheid van de testmeting ten goede komt.
Voor persoonlijke hulp bij het analyseren van je hoogtefout kun je de NSGI mailen: nsgi.nl/over-de-nsgi/contact
Ik gebruik idd WSRA00NL. Ik ga eens even zoeken. Ik heb nu ook de nieuwste versie van NLGEO2018 gevonden. En ik zal hem eens op zo’n kernpunt zetten. Er zitten er een paar in de buurt zie ik.
Dankjewel voor je snelle reactie
De versies van NLGEO2018 verschillen alleen in de metadata en/of bestandsformaat, maar geven exact dezelfde hoogte-omrekening (tenzij je per ongeluk 2008 gebruikt). De originele bron is de RDNAPTRANS™2018-download.
In RDinfo staan foto’s en schetsen die helpen om een Kernnetpunt te vinden. Maar let daar bij het selecteren van een Kernnetpunt op de datum waarop de coördinaten bepaald zijn. Als een Kernnetpunt in een smalle berm van een weg ligt of in een gebied met bodemdaling kan het dat de coördinaten na meer dan 5 jaar niet meer kloppen.