3D BAG: 3d segmenten groeperen

Datasets BAG
#1

Voor een project wil ik graag uitgevulde 3d dakvlakken genereren uit de database.

Elk dakvlak heeft een 2d Polygon in tabel lod22_2d.
De MultiPolygon in het geometrie veld van tabel lod22_3d lijkt een trimesh te zijn.

Ik ben op zoek naar een query waarbij ik dus de MultiPolygon kan splitsen en de triangle polygons kan groeperen op basis van de 2d footprint.

Ik probeer iets als:

select clipped_geom
from (
select s3d.gid, (ST_Dump(ST_Intersection(ST_SetSRID(s2d.geometrie, 7415), s3d.geometrie))).geom clipped_geom
from bag3d.lod22_2d as s2d
inner join bag3d.lod22_3d as s3d on s2d.fid = s3d.fid
inner join bag3d.pand as pand on s2d.fid = pand.fid
where pand.identificatie = ‘NL.IMBAG.Pand.0503100000017610’
) as clipped
where ST_Dimension(clipped.clipped_geom) = 1;

Ter illustratie:
Ik probeer dus per dd_id (dakdeel) de 3d segmenten te groeperen.

Hier een plot van de ongegroepeerde dakdelen:

image
image888×398 103 KB

Plan B is zelf een algoritme schrijven die de daksegmenten groepeert, maar probeer eerst een query te vinden.

#2

Hi @jpdark, is your question still open?

From your query I see that you are using the 2D projection of the LoD2.2 data. The 2D layers in the 3D BAG are really just the 2D projection of the roofs of the 3D models.
I am assuming that you would want to group the triangles by roof plane with the same orientation, inclination. Is that correct?

#3

I am assuming that you would want to group the triangles by roof plane with the same orientation, inclination. Is that correct?

Yes, this is correct.
@BalazsDukai What would you advise me to do?

#4

I can think of two alternatives, and a third option if you still have 1-2 months time.

First, maybe adjusting your query would work, so that you match the triangle centroids to the 2D roof surfaces (eg. with ST_Within), instead of matching the triangle themselves. I’ve never tried this though.

If the first alternative doesn’t work, then I’m afraid its your Plan B. You could group the triangles based on the orientation of their normal vector. Postgis doesn’t have a function for this as far as I know, so you would need to write one yourself. Or do the computation outside the DB, but that required offloading the data.

Lastly, the upcoming 3D BAG update (in 1-2 months) won’t have triangulated 3D surfaces anymore, so this problem will disappear. This is the least-effort option, but it will take some time.

1 like
#5

Hi Balazs, thanks for your helpful reply.

I actually already implemented what you mentioned as Plan B and it’s quite acceptable.

Thanks for the idea to change up the query.
I might mess around with that to see if I can get some value easily.

Nice to hear that you are working a new update with non-triangulated surfaces.