3DBAG TU Delft WFS toont geen z-waarden

In tegenstelling tot de exports van de TUDelft 3D-BAG, lijkt de WFS (typename=lod22) geen z-waarden te bevatten. Kan dit bevestigd worden, of doe ik iets verkeerd?

Ik ben ook wel benieuwd hoe een WFS zou moeten werken 3D. Is dat uberhaupt mogelijk? Welke software heb je nodig?

Ik zie de WFS vooral als formaat om gericht een kleine selectie panden op te halen, om deze later om te zetten in een multipatch feature type. Dit multipatch wil ik dan wel in een 3D-omgeving kunnen gebruiken, en daarvoor moeten er wel z-waarden worden meegeleverd. Anders zie ik de toegevoegde waarde van de WFS ook niet voor de 3DBAG.

Jazeker is dat mogelijk, het word zelfs expliciet benoemd in de OGC 2.0.2 WFS standaard (mits het CRS correct 3D ondersteund, is de strekking van de opmerking, en hoe dan om te gaan met een feature dat zowel 2D als 3D geometrie heeft).

Alles wat met 3D geometrie en WFS kan omgaan?

En om terug te komen op de oorspronkelijke vraag van @boerss : Kun je een request delen hier?

bv deze request: https://data.3dbag.nl/api/BAG3D_v2/wfs?typename=lod22&request=GetFeature

Zo te zien doe je niks fout, alleen publiceert de WFS geen 3D-features. Als ik de Capabilities bekijk, zie ik alleen de “BAG footprints” als features, die bovendien ook nog alleen in EPSG:28992 gepubliceerd worden (wat een 2D CRS is!). Dus via de WFS ga je geen 3D-objecten krijgen, vrees ik.

2 likes

ik lees in de beschrijving nu het volgende:

"The 2D projection of the LoD2.2 model. The elevation of the detected LoD2.2 roof planes are stored as height attributes (h_dak_*). Note that the slanted roof planes of the 3D model cannot be reconstructed from these 2D polygons and height attributes. Only the above terrain parts of the BAG footprint are included. Can join to pand on fid" .

Wellicht zijn z-waarden dus bewust niet opgenomen, maar moet de hoogte dmv genoemde join gereconstrueerd worden? Moet nog even uitzoeken of/hoe dit werkt obv de WFS.

Die mogen ook niet opgenomen worden onder EPSG:28992, want dat is een 2D CRS. Bovendien staat in die beschrijving ook

Het enige wat je dus kan doen met deze features, is ze extruden naar het meegeleverde hoogte attribuut. Maar zoals de beschrijving ook al zegt: dan heb je dus rechthoekige blokken zonder de schuine daken.

1 like

veel dank voor je hulp @sbjager. Helemaal duidelijk zo. Jammer dan dat de WFS niet met een 3D CRS gepubliceerd is. Zo is deze niet zo bruikbaar (en dus in de praktijk ook niet lod22, wat het typename wel impliceert!)

Niet bruikbaar hangt natuurlijk af van wat je wil bereiken :slight_smile:
Dat het wat verwarrend is, ben ik met je eens:

<Name>BAG3D_v2:lod12</Name>
<Title>LoD 1.2</Title>
<Abstract>BAG footprints with calculated height from AHN3.</Abstract>

<Name>BAG3D_v2:lod13</Name>
<Title>LoD 1.3</Title>
<Abstract>BAG footprints subdivided in parts of different heights based on AHN3.</Abstract>

<Name>BAG3D_v2:lod22</Name>
<Title>LoD 2.2</Title>
<Abstract>BAG footprints subdivided in parts based on details of their roof structure based on AHN3.</Abstract>

Waar de verschillende LoD’s van deze WFS naar verwijzen, is dat de oorspronkelijke BAG vlakken opgeknipt zijn langs verschillende lijnen, gebaseerd op het LoD van de oorspronkelijke 3D objecten. Denk ik althans, dat dat is wat er bedoeld word.
Maar als je diagonaal leest, denk je inderdaad dat je het volledige 3D object te pakken hebt… Als ik me goed herinner ben ik ook eens in die valkuil getrapt…

Dat de standaard een techniek als concept beschrijft is mooi. Ik bedoeld meer in prakitische zin. Welke 3d Gis / cad sofware gebruikt dit al?

wellicht geen (ik ken ze niet), maar de vraag is of dat uit maakt, als je WFS ziet als een vector uitwisselformaat van een kleine gegevens set, die je omzet naar een bruikbaar formaat, als bv. multipatch.