Ik heb gewoon een simpele vraag, dus ik houd het kort:
Gebruiken wij bij de BAG import RDNAPTRANS (RD naar ETRS89 naar WGS84 inclusief RDNAPTRANS correctiegrid) of de benaderingsmethode zonder RDNAPTRANS correctiegrid? Iemand die dit kan beantwoorden heeft ook voldoende kennis om te begrijpen wat ik bedoel 
Stuur even een PB aan Gertjan Idema. Die heeft de plugin gebouwd en onderhoud hem ook.
De BAG plugin gebruikt de benaderingsmethode zonder RDNAPTRANS correctiegrid.
Bij het begin van de plug-in heb ik wel naar RDNAPTRANS gekeken, maar voor zover ik mij kan herinneren heb ik toen geen open-source implementatie van RDNAPTRANS kunnen vinden.
Ook wordt de transformatie van ETRS89 naar WGS84 overgeslagen, omdat die door de continentverschuiving steeds verandert (nu zo’n 73 cm). Bij het toevoegen van de RD-projectie aan JOSM heb ik trouwens dezelfde benadering gebruikt.
Zie ook https://forum.openstreetmap.org/viewtopic.php?pid=561400#p561400 en https://forum.openstreetmap.org/viewtopic.php?pid=561601#p561601
Ik weet erg weinig van landmeetkunde, maar betekent dat dan dat de BAG-gegevens in OSM 73 cm verschoven zijn ten opzichte van de werkelijkheid? Is dat geen probleem voor doeleinden waar precisie van belang is?
Oke, bedankt voor informatie! Nu weet ik welke rekenmethode ik moet gebruiken om mijn eigen dingen van RD naar osm coordinaten om te rekenen 
Het belangrijkste met dit soort dingen is niet dat het feitelijk correct is, maar dat het consistent wordt toegepast, en niet allerlei methoden dwars door elkaar heen.
Inderdaad, alle gebouwen die uit BAG zijn geïmporteerd en alles wat uit BGT wordt overgenomen is gemiddeld 73 cm verschoven ten opzichte van de werkelijkheid. Dit verschil wordt ieder jaar ongeveer 2,5 cm groter. De afwijking met de werkelijkheid wordt ook nog beïnvloed door het niet gebruiken van het correctiegrid (afwijking tot 25 cm).
Voor doeleinden waarbij een precisie van beter dan een meter nodig is, is OSM dus minder geschikt.
Op dit moment is hier weinig aan te doen, tenzij iemand iedere paar jaar alle data in Nederland (en de rest van Europa) op wil schuiven met 10 cm. Om deze situatie te verbeteren zou OSM op termijn over moeten gaan op een ander coördinatenstelsel per continent, zoals in 2015 gesuggereerd door Gertjan Idema.
Ach, iemand die zich bewust is van consistente afwijking in een bron kan dat ook weer zelf compenseren, zoals het Kadaster met de RDNAPTRANS omrekenings-truc (correctiegrid) heeft gedaan. Maar inderdaad de situatie is wel ingewikkeld door tal van coordinatensystemen met elk hun eigen afwijkingen en speciale dingetjes wereldwijd, wat vervolgens weer de omgerekende coördinaten beïnvloed.
Ik weet niet of het al bestaat, maar is het niet een idee om een uitgebreide wiki pagina hier over te maken, specifiek voor NL? Ook in het Engels, dan is het namelijk tenminste goed gedocumenteerd.
Ook een potentieel interessant idee is een programma dat osm coördinaten uit heel Europa omrekend naar absoluut correcte (alle systematische fout er uit, ruis zal je altijd hebben) ETRS89 coördinaten. Zo’n programma zou natuurlijk kennis moeten hebben van de verscheidene landelijke systemen en hun systematische afwijkingen. Het ingewikkelde daar aan is die 2.5cm verschuiving per jaar, je zou eigenlijk naar mutatiedatum per node moeten kijken en daarop gebaseerd rekenen, en natuurlijk dat import data en non-import data door elkaar heen wordt gebruikt.
Alas, absolute positie is lang niet zo belangrijk als onderlinge fout.
Het blijkt allemaal nog ingewikkelder dan voorheen gedacht. Er zijn zelfs verschillende transformaties voor het omrekenen zonder RDNAPTRANS correctiegrid.
Gebruikt de BAG-import plugin de JOSM projecties of doet de plugin zelfstandige reprojectie?
Volgens mij laat de plugin het over aan de WFS service waar het de data van opvraagt.
De BAG-import plugin gebruikt proj4j (De Java variant van proj4) voor de reprojectie. Bij het begin van de plugin was het RD coordinatenstelsel nog niet beschikbaar in Josm zelf. Ik heb ook naar Geotools gekeken, daar zat destijds een afwijking in de RD coordinaten.
Ook voor de BAG plugin geldt wat mij betreft:
Is er in de BAG-import plugin een transformatie string gespecificeerd? (+towgs84) Zo ja, welke string is dat precies? Of geef je simpelweg op: transformeer van EPSG:28992 naar EPSG:4326 en laat je het proj4 verder zelf uitzoeken?
+towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725
Interessant, in OSM (beiden JOSM en BAG-import blijkt) gebruiken we dus de EPSG:4833 transformatie, afkomstig van de Nederlandse Commissie voor Geodesie uit 2008. Dat is dan ook de meest recente transformatie.
JOSM en de BAG-import plugin hebben wel beiden de van microradialen naar boogseconde omgerekende transformatie-parameters voor rotatie net wat anders afgerond: JOSM heeft meer cijfertjes dan de BAG-import plugin.
Ik denk dat het belangrijk is voor ons om er van bewust te zijn dat wij hier een apart geval zijn, aangezien PROJ4 standaard de EPSG:15934 transformatie gebruikt. GDAL, Mapserver, QGIS etc gebruiken dus standaard een andere transformatie dan wij in OSM gebruiken om RD om te zetten in WGS84 en vice versa. Als wij dingen met zulke GIS software doen moeten we dus eigenlijk even onze eigen transformatie-string specificeren.
Waarschijnlijk wijken de PDOK luchtfoto’s als we die niet aanvragen in RD dus ook af van onze transformatie, maar ik vermoed dat de afwijking verwerpelijk is, zeker aangezien die luchtfoto’s toch maar een resolutie van 25cm/pixel bevatten.
Misschien dat ik die afwijking later nog eens bereken, in dat geval zal ik hem hier bij vernoemen.
(deze post is vooral bedoeld als conclusie voor mensen die later deze thread lezen, ter verduidelijking)
Bedankt voor alle informatie, Gertjan en Cavit! 
Schijnbaar is het nóg ingewikkelder. Het lukt me maar niet om een BAG pand binnen 1mm te repliceren, er zit telkens minder dan een centimer afwijking in. Doet de BAG update plugin of ODS ergens bewust coördinaten afronden?
De plug-in gebruikt de zelfde afronding als de openstreetmap database. Die is 7 decimalen voor de lengte- en breedtegraad. Dat is zo’n 5 mm in noord-zuid richting en op de evenaar is zo’n 9 mm in oost-west richting. Verder van de evenaar wordt het minder in oost-west richting.
Dat verklaart een hoop
Een kleine correctie:
Die 9 mm klopt volgens mij niet.
Op de evenaar komt een graad in zowel lengte als breedte overeen met zo’n 111 km (= de omtrek van de aarde gedeeld door 360 graden=40000km / 360).
De zevende decicimaal (0,000 000 1 graad) is dan zo’n 11,1 mm. Dus de afrondfout zowel in noord-zuid- als in oost-west-richting is maximaal de helft hiervan: zo’n 5,5 mm.
https://blog.openstreetmap.org/2017/03/31/osm-plate-tectonics/
Weet iemand hier meer van? Als ze dit werkelijk elk jaar doen, ook in NL, stort ons hele luchtkasteel van heen en terug transformaties en onderlinge integriteit in zee.