in BAGv1 had kreeg ik van het verblijfsobject een latitude en longitude terug. Nu niet meer, het is nu EPSG28992. Hoe krijg ik nu nog van een verblijfsobject de lat&long?
De broncoördinaten van de BAG zijn in RD (EPSG:28992).
Wil je deze getransformeerd hebben naar:
- Coördinaten van het Amerikaanse GNSS van 1987-heden met een onnauwkeurigheid van 2 meter: WGS84-datumensemble (EPSG:4326) dat vaak gebruikt wordt voor geografische coördinaten in het algemeen zonder te specificeren welk coördinatensysteem.
- Coördinaten van het Amerikaanse GNSS (waarom niet van het Europese, Russische of Chinese GNSS?) van dit jaar met een nauwkeurigheid van enkele centimeters: WGS84-G2139 (EPSG:9755)
- Coördinaten in het actuele wetenschappelijke en officieel door de VN aanbevolen Global Geodetic Reference Frame met centimeternauwkeurigheid: ITRF2014 (EPSG:9000).
- Coördinaten in het officiële Europese ETRS89 met centimeternauwkeurigheid die niet (zoals bovenstaande opties) continu met 2,5 cm/jaar veranderen door tektonische beweging: ETRF2000 (EPSG:9067).
Transformatie naar optie 2 levert momenteel dezelfde coördinaten op als optie 3. Optie 1 (EPSG:4326) levert voor Nederlandse data in praktijk meestal dezelfde coördinaten op als optie 4 (EPSG:9067).
1 like
Naar EPSG4326 alstublieft, dankuwel. Hoe valt dat te doen?
Nog beter is als ik ze meteen krijg bij de aanroep van verblijfsobject. Die heeft een ‘Accept-crs’ parameter voor het coordinaatsysteem, maar daarin is de enige optie EPSG28992. Zou mooi zijn als EPSG4326 daarook geaccepteerd wordt.
Grappig dat je wel EPSG-codes kent maar niet weet hoe je moet transformeren.
Waar heb je de data vandaan en met welke software werk je?
Dit is in ieder geval de software die je kunt gebruiken, en die is geïntegreerd in heel veel andere software zoals GeoServer en QGIS:
https://proj.org/
1 like
Vind ik helemaal niet grappig! 
Ik ken die code alleen maar omdat ik deze nu voor het eerst zie in de BAG interface van de Verblijfsobjecten. Daar komt dus ook mijn data vandaan: de response van de verblijfsobjecten-API. Ik werk in Mendix, een lowcode over Java en moet die omzetting serverside doen en niet in javascript.
Is het een ingewikkelde omrekening of gewoon een wiskundig truukje?
1 like
Misschien is er ook wel een manier om de BAG op te vragen in lat,lon zodat je niet zelf hoeft te transformeren. Er zijn hier vast mensen die dat weten.
Andere optie is inderdaad om de BAG zelf te transformeren. Dat is een ingewikkelde berekening, maar in QGIS kan je gemakkelijk data in EPSG:28992 openen en in een andere EPSG-code exporteren. Wanneer je een onnauwkeurigheid van 2 meter geen bezwaar vindt dan kun je EPSG:4326 kiezen.
1 like
Dat latlong direct te ontvangen zijn hoop ik ook. Bagv1 had ik dat voor elkaar, maar in v2 dus (nog) niet.
Volgens de capabilities zou epsg:4326 wel beschikbaar moeten zijn:
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?request=getCapabilities&service=WFS
en voor mij werkt het ook:
1 like
Maar dat is via geodata, niet rechtstreeks naar BAG: curl -X “GET” “https://api.bag.acceptatie.kadaster.nl/lvbag/individuelebevragingen/v2/verblijfsobjecten/0226010000038820” -H “accept: application/hal+json” -H “Accept-Crs: epsg:28992” -H "X-Api-Key: " werkt, maar niet als ik epsg:4326 meegeef aan Accept-Crs. Dan krijg ik als response: {“status”:406,“title”:“Gevraagde coördinatenstelsel epsg:4326 wordt niet ondersteund.”,
Ik denk dat geodata zelf omrekent. In mijn app had ik zowel de PDOK als BAG API in gebruik, maar nu dus alleen PDOK en ik probeer BAG ook weer erbij te hebben.
Omdat ik geen api key heb kan ik dit niet proberen. Maar stel je krijgt .geojson terug, dan kun je dat bestand transformeren met gdal met het volgende commando:
ogr2ogr -f geojson -of geojson -t_srs ‘EPSG:4326’ vbo_4326.geojson vbo_28992.geojson
dat vbo_28992.geojson omrekent naar vbo_4326.geojson met nieuwe coordinaten.
De API zal zelf ook (van tevoren of on-the-fly) omrekenen, aangezien the authentieke brondata van de BAG in RD is (EPSG:28992).
Overigens geeft de WFS van “geodata” als je om EPSG:4326 vraagt, zo te zien geen WGS84, maar ETRS89 en dus waarschijnlijk altijd exact hetzelfde resultaat als wanneer je om EPSG:4258 vraagt. Welke omrekening er precies gebruikt wordt is niet zo eenvoudig te zien omdat de geografische coördinaten zijn afgerond op 6 cijfers achter de komma (ca. 0,1 meter).
Zoals ik al schreef is het gelijkstellen van WGS84 aan ETRS89 niet ongebruikelijk. Voor veel gebruikers is dit zelfs de meest praktische keus omdat ze geen tijdsafhankelijke coördinaten willen. Ik vermoed dus dat de API dit ook deed/doet.
Mijn vraag zou dan direct zijn: Waarom? Als je wereldwijd werkt, kan ik me er iets bij voorstellen, maar als je alleen met NL bezig bent niet. Gewoon lekker in RD blijven werken, scheelt je een hoop kopzorgen en cpu-cycles.
En als je Europees bezig bent, is ETRS89 veel beter, dus dan begrijp ik ook niet waarom je in latitude en longitude wil werken.
Het maakt mij verder niet uit hoor, maar ik vraag het me altijd af als ik dit soort posts zie…
Ik weet dat sommige software (bijvoorbeeld webviewers) alleen met geografische coördinaten (lat,lon) werken, dus dat kan een reden zijn. In dat geval raad ook ik in de meeste gevallen aan om ETRS89 te gebruiken (ook al vraagt je software om WGS84). ETRS89 gebruikt namelijk ook latitude en longitude maar heeft als voordeel dat de coördinaten niet (of nauwelijks) veranderen.
Misschien handig om dit probleem ook eens bij de bron neer te leggen.
@PieterDijkstraBAG, zijn er plannen om de BAG Individuele bevragingen API ook ETRS89 uit te laten leveren?
En uberhaupt alle WFS’sen, WMS’sen en API’s gelijk te trekken met betrekking tot ondersteunde CRS’sen?
Er zit nogal eens een verschil tussen de verschillende services.
2 likes
Dat kan inderdaad een reden zijn, persoonlijk zou ik dan toch heel rap op zoek gaan naar andere software
Naar mijn mening zou software die met geoinformatie om kan gaan ook met verschillende projecties om moeten kunnen gaan.
Maar het is vooral mijn eigen nieuwsgierigheid: ik zie namelijk nogal eens dat men het zichzelf veel te moeilijk maakt, terwijl dat niet nodig is. Vandaar mijn vraag.
Het ondersteunen van onder andere ETRS89 in de BAG individuele bevragingen API staat op de backlog. We kunnen op dit moment echter nog niet aangeven op welke termijn we dit implementeren.