Ik weet dat de vraag al vaker gesteld is. Maar ik kom bepaald niet goede bruikbare antwoorden tegen. Voor het bepalen van een gebied wil ik graag in Excel op een of andere manier de RD naar WGS84 kunnen omzetten. Ik gebruik nu ‘knippen plakken’ rechter scherm. Is er iets aan te doen?
Hoi je kan dit doen met de api van pdok. Voor dit antwoord heb ik even chat GPT gebruikt. Zonder pc kan ik geen voorbeeld bijvoegen. Maar ik kan je zeggen dat het werkt.
Succes…
https://api.pdok.nl/bzk/locatieserver/search/v3_1/reverse?lat=52.4359&lon=4.834&fl=*&rows=1
Om de genoemde URL in Excel met Power Query te gebruiken en de lat/lon-coördinaten om te zetten naar RD-coördinaten (XY), kun je de volgende stappen volgen:
- Open Excel:
- Ga naar het tabblad Gegevens.
- Klik op Van andere bronnen > Van web.
- Voer de URL in:
- Plak de URL:
https://api.pdok.nl/bzk/locatieserver/search/v3_1/reverse?lat=52.4359&lon=4.834&fl=*&rows=1. - Klik op OK.
- Transformeer de gegevens:
- De gegevens van de URL worden ingeladen in Power Query.
- Zorg ervoor dat je de gegevens als JSON laat weergeven of in een gestructureerde tabel. Indien nodig kun je de kolommen openen en uitvouwen om relevante velden te zien (bijvoorbeeld de
rdXenrdYcoördinaten als die beschikbaar zijn).
- Parameteriseren van de coördinaten:
- Je kunt het proces dynamisch maken door parameters voor de
lat- enlon-waarden te maken in Power Query. - Klik in Power Query op Beheren > Parameters > Nieuw en voeg parameters toe voor
LatitudeenLongitude. - Pas de URL in de query aan, zodat deze de parameterwaarden gebruikt (bijvoorbeeld:
https://api.pdok.nl/bzk/locatieserver/search/v3_1/reverse?lat=" & Latitude & "&lon=" & Longitude & "&fl=*&rows=1).
- RD-coördinaten ophalen:
- Zodra de gegevens worden opgehaald, controleer of er een veld met RD-coördinaten (
rdX,rdY) aanwezig is. - Transformeer of filter de gegevens zoals nodig in Power Query.
Door dit proces kun je lat/lon-coördinaten naar RD-coördinaten (XY) omzetten en dynamisch aansturen via Power Query in Excel.
Netjes, zover kom ik niet met Excel 
Maar voor coördinaten transformaties zou ik niet zo snel naar de locatieserver kijken, die dient een heel ander doel. Een API die wel geheel gericht is op coördinaten transformaties is de Transformatie API van het NSGI. De API spec hiervan staat open en biedt ook nog een API key om de API uit te proberen.
5 likes
Pas op: deze post kan rode vlekken veroorzaken bij echte geodeten …
Wat ik ook wel eens gedaan heb is een flink aantal punten converteren en dan mbv multiple regressie een eenvoudige functie bepalen die oibv x en y de lat en lon berekent (of andersom natuurlijk). Die functie kun je eenvoudig in Excel gebruiken.
Voor een klein gebied werkte dit prima.
1 like
5 likes
Ik kreeg van een bekende een formule die best wel bevredigende resultaten gaf. Het is inderdaad voor kleine opppervlakte. Bijvoorbeeld Bouwprojecten die zich binnen de enkele kadastrale grenzen zich begeven. Die wil je op de kaart laten laden. Uiteraard is het voor de bouw niet acceptabel als de afwijking groter is dan 1 mm. Voor andere doeleinden hoeft dit weer geen probleem te zijn.
Als er serieuze behoefte is aan RDNAPTRANS™ in MS Excel, dan kunnen we vanuit de NSGI wel een voorbeeld maken hoe je vanuit MS Excel met onze coördinatentransformatie-API nauwkeurig kunt omrekenen. Like dit bericht als je dat zou gebruiken. Hoe meer likes, hoe hoger we het op onze backlog zetten…
6 likes
Dat is een goeie suggestie Jochem. Een andere site die ik wel eens gebruik is epsg.io.
Maar die is ook niet nauwkeuriger dan 1 m. Voor ‘bim toepassing’ is dit niet voldoende.
Ik raad het gebruik van egpg.io af! Deze website gebruikt een slechte implementatie van een verouderde kopie van de officiële database van epsg.org
1 like
QGIS gebruikt voor coördinatentransformaties een redelijk recente versie van de PROJ-softwarebibliotheek en EPSG-database en dat voldoet inderdaad voor de meeste gebruikers.
Wat in QGIS ontbreekt is de mogelijkheid om de nauwkeurige tijdsafhankelijke transformaties tussen internationale coördinatenstelsels en onze nationale/Europese (aan de aan de tektonische plaat gebonden) coördinatenstelsels te doen. De Transformatie-API van de NSGI gebruikt ook PROJ, maar kan wel die tijdsafhankelijke transformaties. Daarnaast gebruikt de API van de NSGI een aangepaste versie van de database waardoor de voor Nederland aanbevolen realisaties gebruikt worden bij de tijdsafhankelijke transformaties voor de datum ensembles ETRS89 en WGS 84.
1 like
Hoelang bestaat deze site al?? Dit is precies wat ik zocht 
Stom dat ik deze niet eerder had gevonden. En jammer dat google search of chatgpt dit niet weten door te geven. Anyway… problem solved,
Maar het is niet in Excel… 
Dat is niet zo heel erg Leuk als het kan met Excel, API ofzo. Maar in eerste instantie is een vrij toegankelijke gedegen methode wel voorhanden voor iedere nitwit (Bim ontwerper) die in aanraking komt met dergelijke translaties. Althans, uitgaande dat de uitkomst klopt.
Nog een vraag… Houdt deze NSGI site/ interface daarmee rekening met correcties? Gesuggereerd wordt een precisie van zelfs 0.1 mm . Hoe moet ik dat interpreteren?
De online coördinatentransformatietool op de NSGI-website gebruikt de Transformatie-API van de NSGI. Die API gebruikt uiteraard de officiële en aanbevolen transformaties van de NSGI, waaronder RDNAPTRANS™2018.
De tool doet nu nog alleen RDNAPTRANS™2018, maar gaat nog uitgebreid worden met de andere transformaties van de Transformatie-API.
De resultaten van de tool zijn ongeveer zo nauwkeurig als het aantal cijfers achter de komma (0,1 mm), zodat we transformaties van anderen op een nauwkeurigheid van 1 mm kunnen controleren.
De tool staat sinds dit voorjaar online, maar vlak daarna is de indeling van de NSGI-website verbeterd, waardoor deze helaas tijdelijk wat slechter gevonden wordt door Google.
1 like
Dank voor de toelichting Jochem! Duidelijk.
1 like
Bedenk wel dat WGS84 niet gelijk is aan ETRS89. Dus coordinaten van Google Maps in WGS84 kopieren naar een tool die ETRS89 → RD transformeert, geeft niet die 1 mm nauwkeurigheid
1 like
IFC2x3 zou in WGS84 moeten in miljoenste seconden moeten.
Maar van de andere kant,… dit is al een beetje achterhaald met de komst van IFC4.
Ik wil het wel graag weten hoe je dit bepaald.
Nauwkeurig van of naar WGS 84 transformeren is sowieso niet mogelijk zonder specificatie van de gebruikte realisatie van WGS 84 en het gewenste epoche. Zonder die specificaties (en ook in de meeste andere gevallen) is WGS 84 gelijkstellen aan ETRS89 met een nultransformatie het advies (Handreiking CRS). Dat advies kan wel weer op de millimeter uitgevoerd worden.
Als je wel de tijdsafhankelijke transformatie nodig hebt dan kun je de tool op de NSGI-website pas gebruiken als deze meer CRSen ondersteund. Met de API van de NSGI kan je wel al van en naar WGS 84 transformeren. Als je geen epoche opgeeft doet de API een nultransformatie, als je wel een epoche opgeeft dan doet de API de tijdsafhankelijke transformatie met een recente realisatie van ITRS en wordt dat gelijkgesteld aan WGS 84. Daarmee volgt de API met submillimeter nauwkeurigheid de officiële transformaties. Al zijn die transformaties zelf maar op ongeveer 1 cm nauwkeurig berekend.
2 likes
Jochem, Ik word wel blij van deze tool van NGSI. Kan ook prima standaard in AutoCAD dienen om luchtfoto’s als onderlegger te gebruiken. Nauwkeurig genoeg.
