Ik zou graag zien dat Kadaster deze translatie op 3DBAG op een minder diepzinnige manier documenteert. Liefst gewoon op de download site van de tegel. Kan dat?
Wat bedoel je? Ik zie (in je screenshot positie x, y en elevatie) geen translatie, maar gewoon RD-coördinaten in millimeters, dus schaal 1000:1. Wel vreemd dat de scale dan 100 is.
Als het hier over de 3DBAG â https://3dbag.nl/ gaat, dan is dat niet een Kadaster product.
Maar iets wat de TU Delft met data van Kadaster. (misschien dat er Kadaster mensen zijdelings advies/ondersteuning hebben gegeven)
M.a.w. als de documentatie niet goed is zal je denk ik bij de TU Delft moeten zijn.
Maar als het een andere bron is die je bedoelt kan je daar dan de link van gegeven? Aangezien ik niet een âofficieleâ Kadaster 3D BAG dataset ken. De officiele 3D dataset die wij (PDOK) ontsluiten zijn (3D Basisvoorziening - PDOK) op basis van de BRT/TOP producten. En daar is wel een download site met tegels van â PDOK - 3D downloads
Bedankt. Wat ik bedoel is dat duidelijk gemaakt kan worden wat het 0 punt is in rd. Voor 3d gebruik is dat een âneed to knowâ. Het zit erg diep verborgen in de file.
100 vindt ik ook vreemd. Zit in conversie json naar ifc. Is een ander onderzoekje waard?
Volgens mij gaat kadaster over beheer BAG. Ongeacht wie âdit produkt maaktâ is zij (hier!) het aanspreekpunt.
Het product â3d basisvoorzieningâ is totaal onbruikbaar. Veel te grote bestanden na conversie json
Kadaster gaat over de landelijke voorziening BAG en de door Kadaster gemaakte producten die daaruit worden afgeleid. Niet de producten die door âderdenâ worden gemaakt,âŠ
Als ik jou interpretatie begrijp zou dat betekenen dat wanneer jij (@halam) de BAG (o.i.d.) download de coordinaten omzet van XY naar YX plus nieuwe gebruiksdoel typen toevoegd en dat dan aan de buiten wereld aanbied het Kadaster er dan voor verantwoordelijk is?
Vrijwel alle geo-data in Nederland is in het nationale Stelsel van de Rijksdriehoeksmeting (RD). Het nulpunt is een eigenschap van dit coördinatenreferentiesysteem (CRS) en hoeft niet in iedere dataset afzonderlijk uitgelegd te worden. Voorwaarde is wel dat er duidelijk vermeld wordt in welk CRS de data is. In de veel dataformaten hoort in de metadata het gebruikte CRS gespecificeerd te worden, bijvoorbeeld doormiddel van een EPSG-code. Voor RD is dat EPSG:28992. Voor RD met NAP-hoogte is dat EPSG:7415. Die code verwijst naar een beschrijving van het CRS in de EPSG Registry: Amersfoort / RD New Hierin is de definitie van het nulpunt correct gedocumenteerd: 155 km ten westen en 463 km ten zuiden van de OLV-toren in Amersfoort.
In welk dataformaat download jij de tegels? Ik zie dat in de JSON-download EPSG:7415 vermeld wordt. De coördinaten in het bestand zijn echter niet in RD-NAP-coördinaten. Daarvoor moeten eerst de ook de aan het eind van het JSON-bestand vermelde translaties en schaal toegepast worden:
[...]
"referenceSystem":"urn:ogc:def:crs:EPSG::7415",
"fileIdentifier":"3dbag_v21031_7425c21b_7311.json"},
"transform":{
"scale":[0.001,0.001,0.001],
"translate":[132729.66799951173,517041.99700634764,-2.501821756362915]}}
Ik snap dat dit verwarrend zou kunnen zijn. Ik weet niet of dit correct/gebruikelijk is in CityJSON en of het dus nodig is hier in de documentatie op te attenderen. Maar dat zou zeker geen kwaad kunnen op deze pagina: CityJSON - 3D BAG. Stel het voor aan de TU Delft, het emailadres staat hier: Contact - 3D BAG
De waarde/actie âTranslateâ gaat verloren in de conversie naar ifc. Ifc is 'het moederbestandâvoor iedereen die met âbim softwareâ werkt. Geen gis keestie.
Er wordt wel degelijk met een âlokaal nulpuntâ niet in RD gedefinieerd in het en bestand. Het grid heeft dus een georeference functie.
Waar ik om willen vragen hier, wat mijnsinziens nodig is, is een lijstje met deze translatie waarde. Thatâ all 
Voor iedereen die met conversies van dit json formaat kan werken. Geen enkel bim software pakker. Hoop dat het nu wel duidelijk is.
Bij mij gaat hier de translatie naar Nederlands verloren :-). Maar ik ben ook geen âbim software pakkerâ.
Als je een gedegen antwoord wilt krijgen, graag duidelijk formuleren zonder waardeoordelen en opdracht-bevelen. Volgens mij is dit al eens eerder besproken en hierboven genoemd: 3DBAG wordt door TUDelft van de BAG afgeleid. Kadaster kan daar niet voor verantwoordelijk zijn.
Mij is inmiddels duidelijk waarom de transformatie naar een lokaal nulpunt voor jou niet meteen duidelijk was en dus problemen gaf. De vraag is of dat aan de TU Delft ligt of dat de conversiesoftware naar icf daar de schuld van is.
Het lijkt me goed als jij de 3DBAG-makers bij de TU Delft een vriendelijk mailtje stuurt om een waarschuwing in de documentatie op te laten nemen (zie links in mijn vorige reactie). Daarnaast zou je de makers van je icf-conversiesoftware een verzoek kunnen sturen voor het ondersteunen van âtransformâ in CityJSON.
1 like
Bedankt voor de suggestie.
IFC gaat het om, niet icf
CityJSON has specifications where all the properties are documented.
The "transform" property is this formula:
And yes the z=0m is with respect to NAP since EPSG:7415 is used.
1 like
And yes the z=0m is with respect to NAP since EPSG:7415 is used.
Do you mean that x-y coordinates have a local origin and the height coordinates are in NAP? That wouldnât make sense to me since âtranslateâ mentions 3 translations and EPSG:7415 refers to RD as well as NAP.
No.
The âtransformâ is just to compress the values and store them with integers, by themselves they mean nothing.
To get the real x-y-z values one needs to apply the transform as explained in the specs.
And if the resulting z value is for instance â0.31â, this means that this is 31cm above NAP since EPSG:7415 is used.
2 likes
Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.