Omdat RD een geprojecteerd stelsel is, en bijvoorbeeld afstands- en oppervlakteberekeningen en zo dus veel makkelijker zijn. Bovendien is alle NL data in RD, dus heb je ook geen problemen met her-projecteren en zo.
Omdat alle functies van google maps werken met EPSG:4316 was het in ons geval makkelijker om het ook zo terug te krijgen en niet in RD. Deze RD zouden wij dan eerst moeten converteren wat dus niet nodig is wanneer we EPSG:4316 gebruiken.
Wij geven nu ook in jouw voorbeeldje srsname=EPSG:4326 aan en krijgen netjes de coördinaten terug in dit formaat. De center coördinaten daar in tegen niet. Die blijven gewoon in RD. Kan dit ook in EPSG:4326 gegeven worden of is dit niet mogelijk?
Ik vermoed van niet. Dat is overigens niet het centerpunt van het perceel, maar de plaats waar het Kadaster het perceelnummer neerzet op de Kadastrale Kaart. En dat punt kan heel goed buiten het perceel liggen (als de verschuivingdeltax en -y gevuld zijn is dat meestal het geval), dus verwar dat niet met een centroide, want dat is het niet - het is een kartografisch punt, dat geplaatst is waar het perceelnummer mooi uitkomt en niet over perceelsgrenzen heen valt.
En dat die coordinaten niet getransformeerd worden, komt vermoedelijk omdat het attributen zijn, en geen geometrie. De geometrie zal door de server omgezet worden als je dat vraagt, maar van attributen blijft de server af - dus ik denk niet dat je die (op deze manier) in EPSG:4326 kunt krijgen.